From paul.hoffman@vpnc.org Mon Jun 3 15:19:31 2013 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 66A3621F861F for ; Mon, 3 Jun 2013 15:19:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O+bv-GawXeaJ for ; Mon, 3 Jun 2013 15:19:21 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id EB7F711E8121 for ; Mon, 3 Jun 2013 15:10:38 -0700 (PDT) Received: from [10.20.30.90] (50-0-66-165.dsl.dynamic.sonic.net [50.0.66.165]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r53MAa8N039867 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 3 Jun 2013 15:10:37 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) From: Paul Hoffman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 3 Jun 2013 15:10:36 -0700 References: To: "json@ietf.org" Message-Id: Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) X-Mailer: Apple Mail (2.1503) Subject: [Json] Limitations on number size? X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 03 Jun 2013 22:19:31 -0000 Greetings. I'm forwarding this fragment with permission from the AppsAWG = mailing list. It might warrant clarification in -bis document. Begin forwarded message: > From: Nico Williams > On Mon, Jun 3, 2013 at 10:21 AM, Manger, James H > wrote: >>> Imagine JSON had bignums (doesn't, but imagine). >>=20 >> JavaScript might not, but JSON actually does have indefinite length = bignums. A JSON number can have any number of decimal digits. >=20 > Yeah, but it is constrained to IEEE 754 64-bit floating point values, = no? I don't see any limitation in RFC 4627, but it would be interesting if = other folks here believe there is a limitation as Nico does. --Paul Hoffman= From nico@cryptonector.com Mon Jun 3 18:25:41 2013 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 82F5321F98AC for ; Mon, 3 Jun 2013 18:25:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.76 X-Spam-Level: X-Spam-Status: No, score=-1.76 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QZx8lCWUmK2A for ; Mon, 3 Jun 2013 18:25:25 -0700 (PDT) Received: from homiemail-a34.g.dreamhost.com (caiajhbdcahe.dreamhost.com [208.97.132.74]) by ietfa.amsl.com (Postfix) with ESMTP id 6FD4921E80A1 for ; Mon, 3 Jun 2013 17:43:12 -0700 (PDT) Received: from homiemail-a34.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a34.g.dreamhost.com (Postfix) with ESMTP id 6A9A21005D for ; Mon, 3 Jun 2013 17:43:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=FQXhlhTxX1mWiIVDnuPV qX8NSVs=; b=QJkC2qPTwQcq5NJeHKfe2++nJIxjDdGgJL1Nnk/BIfyGDGCfUgE6 BW7o10zxmqyngWieNzOkWy66BEs2sDpZB9hjSU0CR60PiK1XbUNLj8K6U1wn4Ob/ NIpayZEyF7T3+/6ccUwSMvxSQ4LsvDOfrcghqqTWKXFItWQW4eHbhJI= Received: from mail-we0-f176.google.com (mail-we0-f176.google.com [74.125.82.176]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a34.g.dreamhost.com (Postfix) with ESMTPSA id 4DB2410062 for ; Mon, 3 Jun 2013 17:42:55 -0700 (PDT) Received: by mail-we0-f176.google.com with SMTP id t61so2284850wes.7 for ; Mon, 03 Jun 2013 17:42:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=XXqanq0keBvWc0crw0YDdBX/WjLVfpPekr+c6CPUyU4=; b=HX7Payb9LPD/5fRoaZvoa4Lb4hF6DNMibkoLfOLPV+QX+gEa2bST+89eq0Er4JUl8U mbrDNq5FyM0cpbdwum3O++D3tJVFmSO2C/HeNaGQd08r7XESsrT5ZEH/imBizDbobiWe GfaTmEHwpFLBxWFsvBQlT11BdFwmNu6mx2AyNuNprkHMM05FJP7/aX20JBg8mtkXFagp lCbzmD66XGYrUUzjR56reWJBwxUKnieievWdwvvPj9RjaYt/P2z+wvWbxuRFNRca1y4Z qFR/j2mXxL2QweFITa93YRuoy1d40eDfd9EWsF3oNlDFFZoNLiv4XYDJJcWOQ28HHyd3 OWMg== MIME-Version: 1.0 X-Received: by 10.180.185.244 with SMTP id ff20mr520116wic.0.1370306573466; Mon, 03 Jun 2013 17:42:53 -0700 (PDT) Received: by 10.216.63.136 with HTTP; Mon, 3 Jun 2013 17:42:53 -0700 (PDT) In-Reply-To: References: Date: Mon, 3 Jun 2013 19:42:53 -0500 Message-ID: From: Nico Williams To: Paul Hoffman Content-Type: text/plain; charset=UTF-8 Cc: "json@ietf.org" Subject: Re: [Json] Limitations on number size? X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 04 Jun 2013 01:25:41 -0000 On Mon, Jun 3, 2013 at 5:10 PM, Paul Hoffman wrote: > Greetings. I'm forwarding this fragment with permission from the AppsAWG mailing list. It might warrant clarification in -bis document. > > Begin forwarded message: > >> From: Nico Williams >> On Mon, Jun 3, 2013 at 10:21 AM, Manger, James H >> wrote: >>>> Imagine JSON had bignums (doesn't, but imagine). >>> >>> JavaScript might not, but JSON actually does have indefinite length bignums. A JSON number can have any number of decimal digits. >> >> Yeah, but it is constrained to IEEE 754 64-bit floating point values, no? > > I don't see any limitation in RFC 4627, but it would be interesting if other folks here believe there is a limitation as Nico does. Nor does the draft ECMAScript 6 say that. But a) ECMAScript 6 does restrict ECMAScript numeric values to IEEE 754 64-bit values (including NaN, positive infinity, and negative infinity). I have been told by the maintainer of at least one JSON parser/encoder that they will not add support for anything other than IEEE 754 64-bit values. I'm not sure if I should name the project, but I'll say this: it's damn near the best C JSON library I've yet seen. The point is that the perception that JSON is a subset of JavaScript (ECMAScript) is out there, and that because the latter is constrained as described, so should the former. I think that JSON should be taken as so constrained by ECMAScript, but more importantly, any constraint, or even no constraint, should be stated explicitly. Nico -- From cabo@tzi.org Mon Jun 3 23:30:15 2013 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 4014321F9B8A for ; Mon, 3 Jun 2013 23:30:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XaK5sMZV6MGW for ; Mon, 3 Jun 2013 23:29:59 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 67C4821E80E8 for ; Mon, 3 Jun 2013 22:25:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r545PevZ012529; Tue, 4 Jun 2013 07:25:40 +0200 (CEST) Received: from [127.0.0.1] (zoo.informatik.uni-bremen.de [134.102.218.16]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id EC7EF3A89; Tue, 4 Jun 2013 07:25:39 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: Date: Tue, 4 Jun 2013 07:25:37 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Paul Hoffman X-Mailer: Apple Mail (2.1503) Cc: "json@ietf.org" Subject: Re: [Json] Limitations on number size? X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 04 Jun 2013 06:30:15 -0000 >>> JavaScript might not, but JSON actually does have indefinite length = bignums. A JSON number can have any number of decimal digits. >>=20 >> Yeah, but it is constrained to IEEE 754 64-bit floating point values, = no? >=20 > I don't see any limitation in RFC 4627, but it would be interesting if = other folks here believe there is a limitation as Nico does. I think this is a nice example of the distinction between JSON the = representation format, a specific JSON application, and JSON the = ecosystem. JSON the format has no trouble in representing high-precision numbers = (and big integers). =20 So if somebody wanted to send ECDSA signature r/s values as JSON = numbers, the format would be fine. Many JSON applications have at least one end that is implemented in = JavaScript. JavaScript implementations of JSON (including the one now = built into the language) typically represent JSON numbers as JavaScript = numbers locally (in theory, they could implement their own = high-precision numbers/bignums). So in these applications, whatever = information may have been in the JSON format is reduced to what can be = represented in JavaScript's IEEE 754 double precision number format = (i.e., 53 bits of precision). Implementations in other languages may even be shaped by the expectation = that they will be used in such applications, making the choice of IEEE = 754 double as a number format for unencoded/decoded JSON numbers = attractive. This is particularly true for languages such as C that do not have a = native way to work with bignums. As a result, large parts of JSON the ecosystem may be biased to IEEE 754 = numbers. People designing JSON applications that need to work with a = large part of the ecosystem (including the common JavaScript = implementation and other implementations influenced by the capabilities = of that) are better off designing to IEEE 754 double precision numbers. =20= People who use JSON the format between implementations that do support = bignums, however, may not care much. So the answer is: No, JSON the representation format doesn't have such a limitation. JavaScript's common implementation does, and, as a result, some parts of = the JSON ecosystem do as well. Your JSON application may be well advised to live within these = limitations. Or not. It depends on the application. Now if I were designing a new standard for a JSON-based protocol that is = going to be used in wider parts of the JSON ecosystem, I'd probably make = use of the knowledge that many JSON implementations are limited to IEEE = 754 doubles. So I would choose to encode my ECDSA signatures in = base64url instead of sending them as bignums. It may be useful for RFC4627bis to document all this. Gr=FC=DFe, Carsten From nico@cryptonector.com Tue Jun 4 02:03:26 2013 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 9B1ED21F9A9C for ; Tue, 4 Jun 2013 02:03:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.791 X-Spam-Level: X-Spam-Status: No, score=-1.791 tagged_above=-999 required=5 tests=[AWL=0.185, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p8OMqVuljlf8 for ; Tue, 4 Jun 2013 02:03:03 -0700 (PDT) Received: from homiemail-a66.g.dreamhost.com (caiajhbdcbbj.dreamhost.com [208.97.132.119]) by ietfa.amsl.com (Postfix) with ESMTP id 8574C21F9B75 for ; Tue, 4 Jun 2013 00:59:31 -0700 (PDT) Received: from homiemail-a66.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a66.g.dreamhost.com (Postfix) with ESMTP id 3EC02350078 for ; Tue, 4 Jun 2013 00:59:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=q/HBfwpgOHRlK7DY7rvz Tclbbz4=; b=VLEGOoNUjTTO1r5V5Oj7mR4DDz8pV8aFXe++hc5XShRnCEayxErl c9KEQ0LHpSNEhGrmYPgx2uqnWyjcAkX1OFQWU+TEPgKYdPL+Rk/+RoT634s6tAkF Sjms9CZ0XGmp9EhvKiuKQ9QBP52Eh1ceQEm7U5VclUYpAmMLbMqUkZc= Received: from mail-wg0-f52.google.com (mail-wg0-f52.google.com [74.125.82.52]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a66.g.dreamhost.com (Postfix) with ESMTPSA id D669135005B for ; Tue, 4 Jun 2013 00:59:30 -0700 (PDT) Received: by mail-wg0-f52.google.com with SMTP id z11so4037983wgg.7 for ; Tue, 04 Jun 2013 00:59:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=fAo9Y7zSO+62T8z8vdlqNNvtbWIjz7owLmMULh8EWc8=; b=QZtDE5OuY6q94wU8wl8ugql5Pwrlpd+4Xxj6V3VTVN2CV+icoL7GobLKFGEh7KvBDp rNCWkmv9xAbwjZRUSqwT5HcQnlhR7xY6UcP8PSwzB0htnIjlYORjn8enyGE7n7KLaQRu tKbdcEiLHmaPSHJRbrGjly1NOFivJF/KuNT1aKNbf600kUmt+IPqMEpzcKkm65h3m0yN ejX7dy0PpBHeyIV/yhZuj0DtYnLm3ILMDIVt/amEGbSnz+w1kdrk0Oyem9kkszBZkvQi XQZeRmradtSOrcRRDra9Ju0nvnTFD8j/drXrbDUU1giZeGdBPmhBKhHJRlZMlBjt7Trb Zghg== MIME-Version: 1.0 X-Received: by 10.180.90.70 with SMTP id bu6mr169739wib.34.1370332769404; Tue, 04 Jun 2013 00:59:29 -0700 (PDT) Received: by 10.216.63.136 with HTTP; Tue, 4 Jun 2013 00:59:29 -0700 (PDT) In-Reply-To: References: Date: Tue, 4 Jun 2013 02:59:29 -0500 Message-ID: From: Nico Williams To: Carsten Bormann Content-Type: multipart/alternative; boundary=f46d043be27af1d04f04de4f7545 Cc: Paul Hoffman , "json@ietf.org" Subject: Re: [Json] Limitations on number size? X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 04 Jun 2013 09:03:26 -0000 --f46d043be27af1d04f04de4f7545 Content-Type: text/plain; charset=UTF-8 On Tuesday, June 4, 2013, Carsten Bormann wrote: > >>> JavaScript might not, but JSON actually does have indefinite length > bignums. A JSON number can have any number of decimal digits. > >> > >> Yeah, but it is constrained to IEEE 754 64-bit floating point values, > no? > > > > I don't see any limitation in RFC 4627, but it would be interesting if > other folks here believe there is a limitation as Nico does. > > I think this is a nice example of the distinction between JSON the > representation format, a specific JSON application, and JSON the ecosystem. > > JSON the format has no trouble in representing high-precision numbers (and > big integers). > So if somebody wanted to send ECDSA signature r/s values as JSON numbers, > the format would be fine. This is a plausible answer, sure. I'm not sure I'd want to say JSON can only represent IEEE754 64-bit numbers either, so if this is the consensus then that'll be fine by me. Do note that JSON's number encoding is indefinite-length... ;) Nico -- --f46d043be27af1d04f04de4f7545 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tuesday, June 4, 2013, Carsten Bormann wrote:
>>> JavaScript might not, but JSON actually does have ind= efinite length bignums. A JSON number can have any number of decimal digits= .
>>
>> Yeah, but it is constrained to IEEE 754 64-bit floating point valu= es, no?
>
> I don't see any limitation in RFC 4627, but it would be interestin= g if other folks here believe there is a limitation as Nico does.

I think this is a nice example of the distinction between JSON the represen= tation format, a specific JSON application, and JSON the ecosystem.

JSON the format has no trouble in representing high-precision numbers (and = big integers).
So if somebody wanted to send ECDSA signature r/s values as JSON numbers, t= he format would be fine.

This is a plausibl= e answer, sure. =C2=A0I'm not sure I'd want to say JSON can only re= present IEEE754 64-bit numbers either, so if this is the consensus then tha= t'll be fine by me.

Do note that JSON's number encoding is indefinite-length... = =C2=A0;)

Nico
--=C2=A0 --f46d043be27af1d04f04de4f7545-- From stefan@drees.name Tue Jun 4 03:43:03 2013 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 8408A21F9B03 for ; Tue, 4 Jun 2013 03:43:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2ecVbDLVk5Z3 for ; Tue, 4 Jun 2013 03:42:48 -0700 (PDT) Received: from mout.web.de (mout.web.de [212.227.15.3]) by ietfa.amsl.com (Postfix) with ESMTP id D197121F9B06 for ; Tue, 4 Jun 2013 02:39:28 -0700 (PDT) Received: from newyork.local.box ([93.129.187.165]) by smtp.web.de (mrweb102) with ESMTPSA (Nemesis) id 0MHGed-1UfcrD0E8B-00E6xw; Tue, 04 Jun 2013 11:39:12 +0200 Message-ID: <51ADB5BF.4040504@drees.name> Date: Tue, 04 Jun 2013 11:39:11 +0200 From: Stefan Drees User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Nico Williams References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V02:K0:iPxNeHeQeceRBcxSifivfoJnvyhRRRyhb1wjc1Rv+95 wejm9rXmGf/P3K1ezm8drv5ripiSngTpHS70OQ9jwJVQaAHllw 0oQ7Ca48R62Lr0eabUdcB6i+XHydACzPo9GdcZR07lg1V6ao/z 2hRm7ut+MPUU4MyO1HaqJU+gqpj6d4imqs9x51cj/kmsWpP+io dGzQRLJ+LArT+IKLMmiZw== Cc: Carsten Bormann , Paul Hoffman , "json@ietf.org" Subject: Re: [Json] Limitations on number size? X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stefan@drees.name List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 10:43:03 -0000 On 04.06.13 09:59, Nico Williams wrote: > On Tuesday, June 4, 2013, Carsten Bormann wrote: > > >>> JavaScript might not, but JSON actually does have indefinite > length bignums. A JSON number can have any number of decimal digits. > >> > >> Yeah, but it is constrained to IEEE 754 64-bit floating point > values, no? > > > > I don't see any limitation in RFC 4627, but it would be > interesting if other folks here believe there is a limitation as > Nico does. > > I think this is a nice example of the distinction between JSON the > representation format, a specific JSON application, and JSON the > ecosystem. > > JSON the format has no trouble in representing high-precision > numbers (and big integers). > So if somebody wanted to send ECDSA signature r/s values as JSON > numbers, the format would be fine. > > > This is a plausible answer, sure. I'm not sure I'd want to say JSON can > only represent IEEE754 64-bit numbers either, so if this is the > consensus then that'll be fine by me. > > Do note that JSON's number encoding is indefinite-length... ;) ... In the wild - and in my little eco system at least - JSON is used more like ONS (Object Notation Serialization), isn't it? I regard the "indefinite-length stream of digits to be interpreted as a number" as a small price for the unversal usability and acceptance of JSON as a format. In conclusion such a change should IMO a) not qualify as a change being covered by the charter of the WG and would b) break several interesting use cases, where implementers would then be forced to put potentially(!) non IEEE754 64-bit number literals always into quotes instead of as now happily producing and consuming "streams" of say: {/*...*/ "foo": [1.1, 0.2, 1234567890123456789012345678.9, 0.0 //... All the best, Stefan. From paul.hoffman@vpnc.org Tue Jun 4 09:20:44 2013 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 86DB921F9BDC for ; Tue, 4 Jun 2013 09:20:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zP5yBmP1Cc64 for ; Tue, 4 Jun 2013 09:20:30 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 6216121F972C for ; Tue, 4 Jun 2013 07:07:04 -0700 (PDT) Received: from [10.20.30.90] (50-0-66-165.dsl.dynamic.sonic.net [50.0.66.165]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r54E70vh067590 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 4 Jun 2013 07:07:02 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Paul Hoffman In-Reply-To: Date: Tue, 4 Jun 2013 07:07:01 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "json@ietf.org" X-Mailer: Apple Mail (2.1503) Subject: Re: [Json] Limitations on number size? X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 04 Jun 2013 16:20:44 -0000 And this is the point where one of the chairs says "please suggest = specific wording changes to RFC 4627". (FWIW, Doug just got the XML for = the bis draft yesterday, and we'll probably have the -00 soon, but that = should not delay people making specific suggestions for wording = changes.) --Paul Hoffman= From paul.hoffman@vpnc.org Tue Jun 4 10:50:59 2013 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 646C821F9CC2 for ; Tue, 4 Jun 2013 10:50:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2TXJRCExZhdC for ; Tue, 4 Jun 2013 10:50:58 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id B849321F9F5D for ; Tue, 4 Jun 2013 09:58:24 -0700 (PDT) Received: from [10.20.30.90] (50-0-66-165.dsl.dynamic.sonic.net [50.0.66.165]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r54GwJWq090665 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 4 Jun 2013 09:58:20 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) From: Paul Hoffman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <140B9F6C-3F18-4A57-9802-6874C76420CC@vpnc.org> Date: Tue, 4 Jun 2013 09:58:21 -0700 To: "json@ietf.org" Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) X-Mailer: Apple Mail (2.1503) Subject: [Json] Proposed change: update the Unicode version X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 04 Jun 2013 17:50:59 -0000 The current spec refers to the then-current Unicode spec: [UNICODE] The Unicode Consortium, "The Unicode Standard Version 4.0", 2003, . I propose to update the reference to: [UNICODE] The Unicode Consortium, "The Unicode Standard Version 6.2", 2012, . --Paul Hoffman From stpeter@stpeter.im Tue Jun 4 11:31:09 2013 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 0113C21F9B14 for ; Tue, 4 Jun 2013 11:31:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.271 X-Spam-Level: X-Spam-Status: No, score=-102.271 tagged_above=-999 required=5 tests=[AWL=0.328, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iaGrY8+XXROI for ; Tue, 4 Jun 2013 11:31:04 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 4BAFB21F9ACC for ; Tue, 4 Jun 2013 10:59:33 -0700 (PDT) Received: from sjc-vpn2-502.cisco.com (unknown [128.107.239.234]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id B727C4124A; Tue, 4 Jun 2013 12:12:41 -0600 (MDT) Message-ID: <51AE2B03.5070100@stpeter.im> Date: Tue, 04 Jun 2013 11:59:31 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Paul Hoffman References: <140B9F6C-3F18-4A57-9802-6874C76420CC@vpnc.org> In-Reply-To: <140B9F6C-3F18-4A57-9802-6874C76420CC@vpnc.org> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "json@ietf.org" Subject: Re: [Json] Proposed change: update the Unicode version X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 04 Jun 2013 18:31:09 -0000 On 6/4/13 10:58 AM, Paul Hoffman wrote: > > > The current spec refers to the then-current Unicode spec: > > [UNICODE] The Unicode Consortium, "The Unicode Standard Version 4.0", > 2003, . > > > I propose to update the reference to: > > [UNICODE] The Unicode Consortium, "The Unicode Standard Version 6.2", > 2012, . There are other i18n issues that we might want to clarify, but updating the Unicode reference seems uncontroversial. Peter -- Peter Saint-Andre https://stpeter.im/ From nico@cryptonector.com Tue Jun 4 11:43:03 2013 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 DC1D121F918C for ; Tue, 4 Jun 2013 11:43:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.815 X-Spam-Level: X-Spam-Status: No, score=-1.815 tagged_above=-999 required=5 tests=[AWL=0.162, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vnUKEgI3IgCR for ; Tue, 4 Jun 2013 11:42:59 -0700 (PDT) Received: from homiemail-a25.g.dreamhost.com (caiajhbdcbef.dreamhost.com [208.97.132.145]) by ietfa.amsl.com (Postfix) with ESMTP id 0E66A21F9298 for ; Tue, 4 Jun 2013 11:36:01 -0700 (PDT) Received: from homiemail-a25.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a25.g.dreamhost.com (Postfix) with ESMTP id AF60E67812E for ; Tue, 4 Jun 2013 11:36:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=adyPF+pAEZZRKHgvLXtr 2oyM53A=; b=fvdcGZSvcQO+lYqOWHMMrSKX0lKfYSbIu97WQp4FanAnoMmbwgg9 tk2mcOzkWpisghXBkkXGoMFSUhLHEkkHamtIVtDBk41GhUEdrYcU2TZKQfJPHIKd mUQjqh35mQo3pqs2+S4uFD4sMN3Bt0u0TF/Pz9nBMXVvjUMU0TNAohc= Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a25.g.dreamhost.com (Postfix) with ESMTPSA id BAF54678248 for ; Tue, 4 Jun 2013 11:09:17 -0700 (PDT) Received: by mail-we0-f172.google.com with SMTP id q56so516859wes.31 for ; Tue, 04 Jun 2013 11:09:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=dTP2c7AQAlOhrVbMgf76MTntiI+lNnmMyUBeOyBVmXM=; b=YuKUmyGl1QAuoRfTXYCxclgZLCmiQrTPE+FK9xvNrRLPakz4F1Bg8xewHlPKbFJ/mq jgClzGNF3UEaq0LSOY8aa2aJoWRN5BdfapQe2v6wF9Zu+QVQuqowckXXuedf3xAXq9bf ITQUJyu9IR36uBkbSRFyTpxrUKu20drpzUZ/euFEc9uHGC23LDT1EIP3vsuyVcxOUZkV VI8amB5bLedH4/9v4bh2tLiVyoWd9le9HgBkaLxPZCz78Gv+YXuP0PN3yrm5bCslhtjK LOwVjbEjGBWii4pYYz5spVzcYqkW3dcSr9CNZy2yv8cgxu79JWL5KqjfH9sh3GAP6Bgl z3Cw== MIME-Version: 1.0 X-Received: by 10.180.185.244 with SMTP id ff20mr2863509wic.0.1370369353646; Tue, 04 Jun 2013 11:09:13 -0700 (PDT) Received: by 10.216.63.136 with HTTP; Tue, 4 Jun 2013 11:09:13 -0700 (PDT) In-Reply-To: <51ADB5BF.4040504@drees.name> References: <51ADB5BF.4040504@drees.name> Date: Tue, 4 Jun 2013 13:09:13 -0500 Message-ID: From: Nico Williams To: stefan@drees.name Content-Type: text/plain; charset=UTF-8 Cc: Carsten Bormann , Paul Hoffman , "json@ietf.org" Subject: Re: [Json] Limitations on number size? X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 04 Jun 2013 18:43:04 -0000 On Tue, Jun 4, 2013 at 4:39 AM, Stefan Drees wrote: > In the wild - and in my little eco system at least - JSON is used more like > ONS (Object Notation Serialization), isn't it? Often, yes. > I regard the "indefinite-length stream of digits to be interpreted as a > number" as a small price for the unversal usability and acceptance of JSON > as a format. Off-topic: Every value type in JSON (including null and booleans) has indefinite-length encoding. I think this is a highly valuable aspect of JSON, except for the need to escape strings. > In conclusion such a change should IMO a) not qualify as a change being > covered by the charter of the WG and would b) break several interesting use > cases, where implementers would then be forced to put potentially(!) non > IEEE754 64-bit number literals always into quotes instead of as now happily > producing and consuming "streams" of say: I agree. Nico -- From nico@cryptonector.com Tue Jun 4 11:44:29 2013 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 78FD521F9A8B for ; Tue, 4 Jun 2013 11:44:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.833 X-Spam-Level: X-Spam-Status: No, score=-1.833 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VtfOqpI2YdGi for ; Tue, 4 Jun 2013 11:44:23 -0700 (PDT) Received: from homiemail-a70.g.dreamhost.com (caiajhbdcagg.dreamhost.com [208.97.132.66]) by ietfa.amsl.com (Postfix) with ESMTP id 6B30B21F99AE for ; Tue, 4 Jun 2013 11:41:23 -0700 (PDT) Received: from homiemail-a70.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a70.g.dreamhost.com (Postfix) with ESMTP id 2690976812D for ; Tue, 4 Jun 2013 11:41:20 -0700 (PDT) Received: from mail-we0-f178.google.com (mail-we0-f178.google.com [74.125.82.178]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a70.g.dreamhost.com (Postfix) with ESMTPSA id 8DFD8768109 for ; Tue, 4 Jun 2013 11:05:20 -0700 (PDT) Received: by mail-we0-f178.google.com with SMTP id u53so516830wes.9 for ; Tue, 04 Jun 2013 11:05:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=Dn0d4+4lGXmhpu85o22jRSKpDe7RgDYwPwgelpN7O20=; b=gjQtH/u69AW0jS9lqwR5saOrXkTjoNgQnlqw0o34MqQyeKJkAy3FLCTF33vz2d+VJd xDCTGLUt+WZR2I8K+eMlXgqSb8hRCIlAeIizD0tabzSQKfBvaFSaUq223sjtmyXaVmDU obXkmpcUt+Z5Yz5IPlTVYWLZMd4fHy5atvOKzULHRFawNCZCSuI447HLpsngiKjNMYkq ZDbFI4Kmfmka3qV+8G7AEfLyHr1crbqOSlVm/Uy/zs+M4lC7p3UIHITs0yGtm7jM3KQZ 9Qlr5DaW38yJL+LwFukigFRe1Q48NWnUQw2fVkg8b+lOyBzPV4glAYwfToVoJeB4BwC+ T83g== MIME-Version: 1.0 X-Received: by 10.194.77.66 with SMTP id q2mr25045701wjw.34.1370369118219; Tue, 04 Jun 2013 11:05:18 -0700 (PDT) Received: by 10.216.63.136 with HTTP; Tue, 4 Jun 2013 11:05:18 -0700 (PDT) In-Reply-To: References: Date: Tue, 4 Jun 2013 13:05:18 -0500 Message-ID: From: Nico Williams To: Paul Hoffman Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "json@ietf.org" Subject: Re: [Json] Limitations on number size? X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 04 Jun 2013 18:44:29 -0000 On Tue, Jun 4, 2013 at 9:07 AM, Paul Hoffman wrote: > And this is the point where one of the chairs says "please suggest specif= ic wording changes to RFC 4627". (FWIW, Doug just got the XML for the bis d= raft yesterday, and we'll probably have the -00 soon, but that should not d= elay people making specific suggestions for wording changes.) I think we need at least a note on interoperability, stating that ECMAScript can only handle IEEE 754 64-bit numbers, other applications might handle only 64-bit two's complement, others might handle bignum integers, and yet others might handle arbitrary size reals. Applications have to agree a priori on some schema (out of scope), and this is part of that. Should there be any advice to decoder implementors as to how to handle numbers they cannot natively represent? Nico -- From jhildebr@cisco.com Tue Jun 4 12:56:52 2013 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 31A7721F9408 for ; Tue, 4 Jun 2013 12:56:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OPFgel1EeV-m for ; Tue, 4 Jun 2013 12:56:47 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 0CBBA21F9590 for ; Tue, 4 Jun 2013 11:56:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1448; q=dns/txt; s=iport; t=1370372212; x=1371581812; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=/2oy+kBx1lE1jLr8AiOJDZ93iwgFvJcTMm7xIWlTD3o=; b=G8zvtbX2NX7f7uISExokPvixwR4F6MS/8cCyweygOTyv9bOZw6/RLPVx Z6+lqIIPVBF9GbX2uwK/ppCJz5TFBjHtoCare2NjnARBhhwDh0zuNY26u 8CfEZvIAqemFXeVZtPHpik/JLgqpWOCkpjz/rnsiwNMAdz3dL1VtfquLB Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag4FAMk3rlGtJXG//2dsb2JhbABagwkwvyl7FnSCIwEBAQQ6PxIBCBgKFEIlAgQBDQUIAYgEDL1pjVeBHDEHgnphA6h/gw+CJw X-IronPort-AV: E=Sophos;i="4.87,801,1363132800"; d="scan'208";a="218743691" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-5.cisco.com with ESMTP; 04 Jun 2013 18:56:51 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r54IupNJ025873 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 4 Jun 2013 18:56:51 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.56]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.02.0318.004; Tue, 4 Jun 2013 13:56:51 -0500 From: "Joe Hildebrand (jhildebr)" To: Peter Saint-Andre , Paul Hoffman Thread-Topic: [Json] Proposed change: update the Unicode version Thread-Index: AQHOYUwcF9XONJEgqUaP+nfdT45kJZkmK8CA//+rbYA= Date: Tue, 4 Jun 2013 18:56:50 +0000 Message-ID: In-Reply-To: <51AE2B03.5070100@stpeter.im> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [10.21.74.153] Content-Type: text/plain; charset="us-ascii" Content-ID: <0406A3772592BB4E9FE2615F130598CB@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "json@ietf.org" Subject: Re: [Json] Proposed change: update the Unicode version X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 04 Jun 2013 19:56:52 -0000 On 6/4/13 11:59 AM, "Peter Saint-Andre" wrote: >On 6/4/13 10:58 AM, Paul Hoffman wrote: >> >>=20 >> The current spec refers to the then-current Unicode spec: >>=20 >> [UNICODE] The Unicode Consortium, "The Unicode Standard Version 4.0", >> 2003, . >>=20 >>=20 >> I propose to update the reference to: >>=20 >> [UNICODE] The Unicode Consortium, "The Unicode Standard Version 6.2", >> 2012, . > >There are other i18n issues that we might want to clarify, but updating >the Unicode reference seems uncontroversial. Suggested change to section 1: WAS: A string is a sequence of zero or more Unicode characters [UNICODE]. SUGGESTED: A string is a sequence of encoded Unicode codepoints defined in [UNICODE6.2] or later versions of the Unicode specification. Goals: - we're defining a protocol, not an infoset - make it clear that codepoints that become valid in the future are valid JSON Section 3 also needs to be tweaked: WAS: JSON text SHALL be encoded in Unicode. The default encoding is UTF-8. SUGGESTED: JSON text SHALL be transmitted as encoded Unicode codepoints. The default encoding is UTF-8. Note: the rest of section 3 may need to change if we allow strings as root JSON objects later. --=20 Joe Hildebrand From tbray@textuality.com Tue Jun 4 14:39:24 2013 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 631C821F9A19 for ; Tue, 4 Jun 2013 14:39:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.452 X-Spam-Level: X-Spam-Status: No, score=0.452 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_SORBS_DUL=0.877, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G9OPaf2ULirq for ; Tue, 4 Jun 2013 14:39:19 -0700 (PDT) Received: from mail-ve0-x234.google.com (mail-ve0-x234.google.com [IPv6:2607:f8b0:400c:c01::234]) by ietfa.amsl.com (Postfix) with ESMTP id C906521F9A36 for ; Tue, 4 Jun 2013 13:31:56 -0700 (PDT) Received: by mail-ve0-f180.google.com with SMTP id pa12so625901veb.11 for ; Tue, 04 Jun 2013 13:31:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=du8JKp0EHo9Dsxi5WHXQJ/BqnNXX5tcJlvD2p7B8Gs4=; b=gDCa8MV2y9MoJkvrC0CdsnhNkWe3n/GwxRw7Uvzizi8FxdLwYLaQHEA+/O3FHOK05G mtWQgjSJfGcso4WmSbO3VL5tn5apvwwA75ErRLY6uZnHLLIjOPdiXQLODWCuFHEMiNX5 TaqhZ1SLIcU5QaE56oGTUL6mx8KAwY/uXoPBRDWvt0XXJMY2FLSNL1mOUaZQ5GDyv4TF Ea4UCy0tepkx8jQ7/VpHiSsteOOOGVzN1l8FD0zfK902zmjlyDdR61eWW6tznMP9S4pb 5xrREtUzpt/xjKW/lLdhq875wpLbEC3HOpOJGuPbXR7ianga+fqDqeIaJC/3njQ8pp8l bWrg== MIME-Version: 1.0 X-Received: by 10.52.93.8 with SMTP id cq8mr2524437vdb.77.1370377915789; Tue, 04 Jun 2013 13:31:55 -0700 (PDT) Received: by 10.220.48.14 with HTTP; Tue, 4 Jun 2013 13:31:55 -0700 (PDT) X-Originating-IP: [96.49.81.176] In-Reply-To: References: <51AE2B03.5070100@stpeter.im> Date: Tue, 4 Jun 2013 13:31:55 -0700 Message-ID: From: Tim Bray To: "Joe Hildebrand (jhildebr)" Content-Type: multipart/alternative; boundary=20cf307f3ad8e11f2504de59f848 X-Gm-Message-State: ALoCoQnzZuAj4zayHnkr/R8xNZhiG/ulUNi9y+dULNH/7KZPhyoTsnK4VNoRdDsRYodJI2t5Camm Cc: Paul Hoffman , Peter Saint-Andre , "json@ietf.org" Subject: Re: [Json] Proposed change: update the Unicode version X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 04 Jun 2013 21:39:24 -0000 --20cf307f3ad8e11f2504de59f848 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Jun 4, 2013 at 11:56 AM, Joe Hildebrand (jhildebr) < jhildebr@cisco.com> wrote: > WAS: > > A string is a sequence of zero or more Unicode characters [UNICODE]. > > SUGGESTED: > > A string is a sequence of encoded Unicode codepoints defined in > [UNICODE6.2] or later versions of the Unicode specification. > Joe, I get what you=E2=80=99re trying to do, and I suspect this is technica= lly correct, but the language is kind of klunky and I don=E2=80=99t think it he= lps comprehension. I think that when you say =E2=80=9CA string is a series of = Unicode characters" and have a reference to chapter 2, especially section 2.7, of Unicode, it=E2=80=99s really perfectly clear what you mean. I think we can probably avoid mentioning =E2=80=9Ccode points=E2=80=9D, which is a good th= ing. So how about =E2=80=9CA string is a sequence of zero or more Unicode charac= ters defined in version 6.2 (or any subsequent version) of [UNICODE].=E2=80=9D > WAS: > > JSON text SHALL be encoded in Unicode. The default encoding is > UTF-8. > > SUGGESTED: > > JSON text SHALL be transmitted as encoded Unicode codepoints. The defaul= t > encoding is > UTF-8. > Whether it=E2=80=99s transmitted or read out of a file is irrelevant. JSON text takes the form of a Unicode string [UNICODE, section 2.7]; the default encoding is UTF-8. --20cf307f3ad8e11f2504de59f848 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Jun 4, 2013 at 11:56 AM, Joe Hildebrand (jhildebr) &l= t;jhildebr@cisco.co= m> wrote:
WAS:

A string is a sequence of zero or more Unicode characters [UNICODE].

SUGGESTED:

A string is a sequence of encoded Unicode codepoints defined in
[UNICODE6.2] or later versions of the Unicode specification.

Joe, I get what you=E2=80=99re trying to do, and I su= spect this is technically correct, but the language is kind of klunky and I= don=E2=80=99t think it helps comprehension.=C2=A0 I think that when you sa= y =E2=80=9CA string is a series of Unicode characters" and have a refe= rence to chapter 2, especially section 2.7, of Unicode, it=E2=80=99s really= perfectly clear what you mean.=C2=A0 I think we can probably avoid mention= ing =E2=80=9Ccode points=E2=80=9D, which is a good thing.

So how about =E2=80=9CA string is a sequence of zero or more= Unicode characters defined in version 6.2 (or any subsequent version) of [= UNICODE].=E2=80=9D
=C2=A0
WAS:

JSON text SHALL be encoded in Unicode. =C2=A0The default encoding is
=C2=A0 =C2=A0UTF-8.

SUGGESTED:

JSON text SHALL be transmitted as encoded Unicode codepoints. =C2=A0The def= ault
encoding is
UTF-8.

Whether it=E2=80=99s transmitted= or read out of a file is irrelevant.

JSON text takes the= form of a Unicode string [UNICODE, section 2.7]; the default encoding is U= TF-8.
=C2=A0

--20cf307f3ad8e11f2504de59f848-- From tbray@textuality.com Tue Jun 4 14:42:26 2013 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 D1D7E21F92C5 for ; Tue, 4 Jun 2013 14:42:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.452 X-Spam-Level: X-Spam-Status: No, score=0.452 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_SORBS_DUL=0.877, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e0TW3IA6vO3u for ; Tue, 4 Jun 2013 14:42:22 -0700 (PDT) Received: from mail-vb0-x22e.google.com (mail-vb0-x22e.google.com [IPv6:2607:f8b0:400c:c02::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 78D3521F8459 for ; Tue, 4 Jun 2013 12:16:10 -0700 (PDT) Received: by mail-vb0-f46.google.com with SMTP id 10so469408vbe.19 for ; Tue, 04 Jun 2013 12:16:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=RleMXqGDD5BA96o01lO0wBR0lDLGdV1etWDN3lLxMiQ=; b=lsKCuj4EQGXh7L36yklN2T9ho52W4ssHJqKU3jeagl6CTd6U7CWggbGdRUcrJFgZOB +xai21lb73QeceLgYnK7NcHJHH+lp4+oZQX4mkvnpkjzjCERNWzayrjc+pt9+07hgFS/ yOUH1wr6HDFUEPa0+Cr8SypMntAxpLTjicV1188yZG3vFkwvo6g7X0hZnMyLZnJTOxxJ JotTiVXcMzd1wN9aUuUukssFju4m2CtjWbKR8RJNo3fdbOax0FqKlMGYCsgMMnKe6kt6 2PwfU1PBohaLstzj86RXIA5+/Tr5CwtRaig2IehD71FWiKrsJw4i7zohS5+WHwWkpSxV t1Xw== MIME-Version: 1.0 X-Received: by 10.52.91.77 with SMTP id cc13mr146405vdb.79.1370373369777; Tue, 04 Jun 2013 12:16:09 -0700 (PDT) Received: by 10.220.48.14 with HTTP; Tue, 4 Jun 2013 12:16:09 -0700 (PDT) X-Originating-IP: [96.49.81.176] In-Reply-To: References: Date: Tue, 4 Jun 2013 12:16:09 -0700 Message-ID: From: Tim Bray To: Nico Williams Content-Type: multipart/alternative; boundary=20cf307f333aea640004de58e9fd X-Gm-Message-State: ALoCoQlsVdcu8Mm9wC/iW20zdx+F0aRZgk1RXhhcjD5michyiEtZkRNOCG8+mBubM5GVTBXfptZR Cc: Paul Hoffman , "json@ietf.org" Subject: Re: [Json] Limitations on number size? X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 04 Jun 2013 21:42:26 -0000 --20cf307f333aea640004de58e9fd Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I think that once we=E2=80=99re finished with 4627-bis, it would be a good = idea to do a JSON-best-practices RFC. I have lots of ideas for things that could go in there, most probably uncontroversial. But for now, let=E2=80=99s just document the syntax & semantics. JSON allo= ws you to transmit numbers of a magnitude that are likely to cause grief in certain classes of recipient. The industry seems to deal with this pretty well. -T On Tue, Jun 4, 2013 at 11:05 AM, Nico Williams wrote= : > On Tue, Jun 4, 2013 at 9:07 AM, Paul Hoffman > wrote: > > And this is the point where one of the chairs says "please suggest > specific wording changes to RFC 4627". (FWIW, Doug just got the XML for t= he > bis draft yesterday, and we'll probably have the -00 soon, but that shoul= d > not delay people making specific suggestions for wording changes.) > > I think we need at least a note on interoperability, stating that > ECMAScript can only handle IEEE 754 64-bit numbers, other applications > might handle only 64-bit two's complement, others might handle bignum > integers, and yet others might handle arbitrary size reals. > > Applications have to agree a priori on some schema (out of scope), and > this is part of that. > > Should there be any advice to decoder implementors as to how to handle > numbers they cannot natively represent? > > Nico > -- > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > --20cf307f333aea640004de58e9fd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I think that once we=E2=80=99re finished with 4627-bis, it= would be a good idea to do a JSON-best-practices RFC.=C2=A0 I have lots of= ideas for things that could go in there, most probably uncontroversial.=C2= =A0

But for now, let=E2=80=99s just document the syntax & seman= tics.=C2=A0 JSON allows you to transmit numbers of a magnitude that are lik= ely to cause grief in certain classes of recipient.=C2=A0 The industry seem= s to deal with this pretty well.=C2=A0 -T


On Tue,= Jun 4, 2013 at 11:05 AM, Nico Williams <nico@cryptonector.com>= wrote:
On Tue, Jun 4, 2013 at 9:07 AM, Paul Hoffman= <paul.hoffman@vpnc.org>= wrote:
> And this is the point where one of the chairs says "please sugges= t specific wording changes to RFC 4627". (FWIW, Doug just got the XML = for the bis draft yesterday, and we'll probably have the -00 soon, but = that should not delay people making specific suggestions for wording change= s.)

I think we need at least a note on interoperability, stating that
ECMAScript can only handle IEEE 754 64-bit numbers, other applications
might handle only 64-bit two's complement, others might handle bignum integers, and yet others might handle arbitrary size reals.

Applications have to agree a priori on some schema (out of scope), and
this is part of that.

Should there be any advice to decoder implementors as to how to handle
numbers they cannot natively represent?

Nico
--
_______________________________________________
json mailing list
json@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/json

--20cf307f333aea640004de58e9fd-- From douglas@crockford.com Tue Jun 4 15:02:32 2013 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 EAD3E21F9691 for ; Tue, 4 Jun 2013 15:02:14 -0700 (PDT) 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=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GVuKUexSA2fg for ; Tue, 4 Jun 2013 15:02:03 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id 83EF521F9339 for ; Tue, 4 Jun 2013 15:01:37 -0700 (PDT) Received: from [192.168.114.223] ([216.113.168.135]) by mrelay.perfora.net (node=mrus2) with ESMTP (Nemesis) id 0Lg1Ct-1U42YU3Dq7-00pfc9; Tue, 04 Jun 2013 18:01:33 -0400 Message-ID: <51AE63B1.80800@crockford.com> Date: Tue, 04 Jun 2013 15:01:21 -0700 From: Douglas Crockford User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Nico Williams References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V02:K0:joed6aywFgya2mMfPtkPkcTqo9sRvnEhHxzhmTSWtOw Iv2jMHN0vmYE3hS41k89kjcTCLGjLGAPNCErEdma2+UYsNsGSC c71DObldDS4WlV/JTf0rf37N6uVhU8eFGH9XPUVbJcE892MTjJ MjK2xwWNWfMOEr1MloVqNfTQGM0JeUhnwt6hGQKPKfsrU7IHjD xDTOmRBPSyeLQUMOl5QgATHuNl9qOwuNPNdoBIF6F4qFUm0CyK pLHjd/NS7pl+qXUGf1bAda/SQHub4L+Uu4+t0rG+FxP/CMOx9y fk+NEE2VC7bdcdZ5sEr1aThaSrFGUQQyX0lTCND6O1XLmsg34I uBUPP5CX2TyMpXZegtqY= Cc: Paul Hoffman , "json@ietf.org" Subject: Re: [Json] Limitations on number size? X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 04 Jun 2013 22:02:38 -0000 On 6/4/2013 11:05 AM, Nico Williams wrote: > On Tue, Jun 4, 2013 at 9:07 AM, Paul Hoffman wrote: >> And this is the point where one of the chairs says "please suggest specific wording changes to RFC 4627". (FWIW, Doug just got the XML for the bis draft yesterday, and we'll probably have the -00 soon, but that should not delay people making specific suggestions for wording changes.) > I think we need at least a note on interoperability, stating that > ECMAScript can only handle IEEE 754 64-bit numbers, other applications > might handle only 64-bit two's complement, others might handle bignum > integers, and yet others might handle arbitrary size reals. > > Applications have to agree a priori on some schema (out of scope), and > this is part of that. > > Should there be any advice to decoder implementors as to how to handle > numbers they cannot natively represent? > > Nico > -- I strongly advise against fixating too much on JavaScript. JSON is successful because it popularized the best of JavaScript. We should not burden other uses of JSON with the worst of JavaScript. Keep in mind that this format has been working successfully in the wild for over a decade. The goal here should be to do the least that is necessary to formally upgrade its status from Informational, not to attempt to fix something that is already working well enough. It is only because it has been working well enough that we are considering the upgrade. From jhildebr@cisco.com Tue Jun 4 15:45:35 2013 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 D46E821F994A for ; Tue, 4 Jun 2013 15:45:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vZkjvthnlJjb for ; Tue, 4 Jun 2013 15:45:30 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 4897421F998D for ; Tue, 4 Jun 2013 15:45:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=582; q=dns/txt; s=iport; t=1370385930; x=1371595530; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=P+gM2EVRNVdXe8xTG4v2p0IqEFYWlYSzX9pO12rdtvo=; b=BqCsookey/8Yf2S2RphHYLOTUGQZa54kUVbe5xbHsODrPqxXIxrLqivb jV+s6JCkPtcifZ8KX0qRbRIkapxBNXMyVsAXlzoSzQC+8dRPw9rZ7gDR1 L0r/NYQW7wmD+18NGP9lQ1udlO6mnWN7vSQG1pjVMetj9jnO0XOZETvo+ M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8FAFVtrlGtJXG+/2dsb2JhbABagwmDJbw1fRZ0giUBBHkSAQgOFFYlAgQOBQiIBb1xjnMxB4J6YQOIaKAXgw+CJw X-IronPort-AV: E=Sophos;i="4.87,802,1363132800"; d="scan'208";a="218815217" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-8.cisco.com with ESMTP; 04 Jun 2013 22:45:28 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r54MjR85016265 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 4 Jun 2013 22:45:27 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.56]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.02.0318.004; Tue, 4 Jun 2013 17:45:27 -0500 From: "Joe Hildebrand (jhildebr)" To: Tim Bray Thread-Topic: [Json] Proposed change: update the Unicode version Thread-Index: AQHOYUwcF9XONJEgqUaP+nfdT45kJZkmK8CA//+rbYCAAH8ngP//wLiA Date: Tue, 4 Jun 2013 22:45:26 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [10.21.74.212] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Paul Hoffman , Peter Saint-Andre , "json@ietf.org" Subject: Re: [Json] Proposed change: update the Unicode version X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 04 Jun 2013 22:45:36 -0000 On 6/4/13 2:31 PM, "Tim Bray" wrote: >So how about =B3A string is a sequence of zero or more Unicode characters >defined in version 6.2 (or any subsequent version) of [UNICODE].=B2 Much better. >WAS: > >JSON text SHALL be encoded in Unicode. The default encoding is > UTF-8. > >Whether it=B9s transmitted or read out of a file is irrelevant. My point was that "Unicode" is not an encoding. >JSON text takes the form of a Unicode string [UNICODE, section 2.7]; the >default encoding is UTF-8. That's fine. --=20 Joe Hildebrand From stpeter@stpeter.im Tue Jun 4 15:47:56 2013 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 193AC21F99C9 for ; Tue, 4 Jun 2013 15:47:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lnlrPitPlv12 for ; Tue, 4 Jun 2013 15:47:50 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id B6C5021F99C3 for ; Tue, 4 Jun 2013 15:47:50 -0700 (PDT) Received: from ergon.local (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 8FE4B41240; Tue, 4 Jun 2013 17:00:59 -0600 (MDT) Message-ID: <51AE6E95.3050007@stpeter.im> Date: Tue, 04 Jun 2013 16:47:49 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "Joe Hildebrand (jhildebr)" References: In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: Tim Bray , Paul Hoffman , "json@ietf.org" Subject: Re: [Json] Proposed change: update the Unicode version X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 04 Jun 2013 22:47:56 -0000 On 6/4/13 4:45 PM, Joe Hildebrand (jhildebr) wrote: > On 6/4/13 2:31 PM, "Tim Bray" wrote: > >> So how about ³A string is a sequence of zero or more Unicode characters >> defined in version 6.2 (or any subsequent version) of [UNICODE].² > > Much better. > >> WAS: >> >> JSON text SHALL be encoded in Unicode. The default encoding is >> UTF-8. >> >> Whether it¹s transmitted or read out of a file is irrelevant. > > My point was that "Unicode" is not an encoding. Indeed. RFC 6365 is your friend. :-) >> JSON text takes the form of a Unicode string [UNICODE, section 2.7]; the >> default encoding is UTF-8. > > That's fine. Are people using UTF-16 or UTF-32? Is there a good reason not to say "MUST encode using UTF-8"? Peter -- Peter Saint-Andre https://stpeter.im/ From tbray@textuality.com Tue Jun 4 15:51:42 2013 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 52B1C21F99BA for ; Tue, 4 Jun 2013 15:51:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.237 X-Spam-Level: X-Spam-Status: No, score=-1.237 tagged_above=-999 required=5 tests=[AWL=1.739, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pFDGWnshAcWr for ; Tue, 4 Jun 2013 15:51:32 -0700 (PDT) Received: from mail-vc0-f178.google.com (mail-vc0-f178.google.com [209.85.220.178]) by ietfa.amsl.com (Postfix) with ESMTP id CE58D21F99B2 for ; Tue, 4 Jun 2013 15:51:30 -0700 (PDT) Received: by mail-vc0-f178.google.com with SMTP id id13so665549vcb.9 for ; Tue, 04 Jun 2013 15:51:30 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=m9mV+iORSITQjdqEN7Ayxw1bPrNl+uOpOaAPyMscj6E=; b=ld/4X2uFFEuBAo9azy95lH+CC6CdmTYsA0n4s9hL28OFK4+lEFpXE9gQ5orSZKkqfa ORG2Pp935pvHPfKuVpsjjg0+xmnyJ/cSjL21j3sikrvJ3fxjOwDN+y/cLG2Zydf9WrXX mDym8t1xCYqfqNdigehjcqMZIaWAKJUI6bk9Y1g865CAqSKEPGGx/G4mDS12lU6ozC1k c+DISfJGo7MczbPTSS7QrJFLDQhi+Pw2lH3p/tvuu6ISegrqn6gJnRiWsgluXq6RXiqZ pn0BZzRBsFM6MXcsh0gMoKARBtG6EfIsovx4gRO9jHn8KdYLqSLtx/2gwVkjA0tUQr9f zeAQ== MIME-Version: 1.0 X-Received: by 10.52.30.14 with SMTP id o14mr15693508vdh.106.1370386290215; Tue, 04 Jun 2013 15:51:30 -0700 (PDT) Received: by 10.220.48.14 with HTTP; Tue, 4 Jun 2013 15:51:30 -0700 (PDT) X-Originating-IP: [96.49.81.176] In-Reply-To: <51AE6E95.3050007@stpeter.im> References: <51AE6E95.3050007@stpeter.im> Date: Tue, 4 Jun 2013 15:51:30 -0700 Message-ID: From: Tim Bray To: Peter Saint-Andre Content-Type: multipart/alternative; boundary=20cf307ca1e608a38804de5bec14 X-Gm-Message-State: ALoCoQldbgVWWRdaesVunb8OWgL6jpEIXR8dnV7yPanS9QidJtTflJGqzOtTGwaG/GV44clwC1Nb Cc: Paul Hoffman , "Joe Hildebrand \(jhildebr\)" , "json@ietf.org" Subject: Re: [Json] Proposed change: update the Unicode version X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 04 Jun 2013 22:51:42 -0000 --20cf307ca1e608a38804de5bec14 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Jun 4, 2013 at 3:47 PM, Peter Saint-Andre wrote= : > Are people using UTF-16 or UTF-32? Is there a good reason not to say > "MUST encode using UTF-8"? > I would *love* to, but we=E2=80=99re not allowed to change anything. = This is another candidate for that best-practices doc. -T > > Peter > > -- > Peter Saint-Andre > https://stpeter.im/ > > > --20cf307ca1e608a38804de5bec14 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Jun 4, 2013 at 3:47 PM, Peter Saint-Andre <stpet= er@stpeter.im> wrote:
Are people using UTF-16 or UTF-32? Is there = a good reason not to say
"MUST encode using UTF-8"?

I = would *love* to, but we=E2=80=99re <sob> not allowed to change anythi= ng.=C2=A0 This is another candidate for that best-practices doc. -T
=C2=A0

Peter

--
Peter Saint-Andre
https://stpeter.im/


--20cf307ca1e608a38804de5bec14-- From stpeter@stpeter.im Tue Jun 4 16:08:47 2013 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 2BE2821F9A0C for ; Tue, 4 Jun 2013 16:08:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vnd5sT6yI+-J for ; Tue, 4 Jun 2013 16:08:31 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 5381821F9A05 for ; Tue, 4 Jun 2013 16:08:30 -0700 (PDT) Received: from ergon.local (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id E81FD41240; Tue, 4 Jun 2013 17:21:39 -0600 (MDT) Message-ID: <51AE736D.7030209@stpeter.im> Date: Tue, 04 Jun 2013 17:08:29 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Tim Bray References: <51AE6E95.3050007@stpeter.im> In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Cc: Paul Hoffman , "Joe Hildebrand \(jhildebr\)" , "json@ietf.org" Subject: Re: [Json] Proposed change: update the Unicode version X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 04 Jun 2013 23:08:47 -0000 On 6/4/13 4:51 PM, Tim Bray wrote: > On Tue, Jun 4, 2013 at 3:47 PM, Peter Saint-Andre > wrote: > > Are people using UTF-16 or UTF-32? Is there a good reason not to say > "MUST encode using UTF-8"? > > > I would *love* to, but we’re not allowed to change anything. This > is another candidate for that best-practices doc. -T You are right. Peter -- Peter Saint-Andre https://stpeter.im/ From sayrer@gmail.com Tue Jun 4 18:40:08 2013 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 96E3A21F8F85 for ; Tue, 4 Jun 2013 18:40:08 -0700 (PDT) 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=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xocvVggvR8YQ for ; Tue, 4 Jun 2013 18:40:07 -0700 (PDT) Received: from mail-we0-x22f.google.com (mail-we0-x22f.google.com [IPv6:2a00:1450:400c:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 931C721F8FB3 for ; Tue, 4 Jun 2013 18:40:06 -0700 (PDT) Received: by mail-we0-f175.google.com with SMTP id t59so805703wes.20 for ; Tue, 04 Jun 2013 18:40:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=hhnRqt6MCSTo4II31rn110Tc1TNf3yG5INYVmqVjMKw=; b=Hw9h1Oad3oUHBjVLdDc2BEgDWuRj9cRhNzkLnSq9ylL/fMlSmcfLwo/BX76MflDDE7 /ou6S+ewlU1TphiV9l3ZNv39pg2uza463mhCMpq9VpdQD8MYg7l/meiHikgQVw85WO9c L4Dc6pjD/tT+1TyQ/OROVEC3CeM8Dm2MAlkw7JlOqVbqv586K0HmEDASlHqqaJgt/caP VhUuwqDsh9scLRAcI5fKxGedlTsjuiaXON9Z1g0Vp8oRWRlBYsLgkrWwlerOwgwbTx54 yYhUl8QyZDmyVeER6mHEe/S4o6rorznuED/+vhzsJHRQHjT+pxqn6vTDVLEd49Tuf1kT mRTQ== MIME-Version: 1.0 X-Received: by 10.180.185.179 with SMTP id fd19mr4022821wic.1.1370396405401; Tue, 04 Jun 2013 18:40:05 -0700 (PDT) Received: by 10.194.83.35 with HTTP; Tue, 4 Jun 2013 18:40:05 -0700 (PDT) In-Reply-To: <51AE63B1.80800@crockford.com> References: <51AE63B1.80800@crockford.com> Date: Tue, 4 Jun 2013 18:40:05 -0700 Message-ID: From: R S To: Douglas Crockford Content-Type: multipart/alternative; boundary=001a11c25e4cf2129404de5e46c2 Cc: Nico Williams , Paul Hoffman , "json@ietf.org" Subject: Re: [Json] Limitations on number size? X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 05 Jun 2013 01:40:08 -0000 --001a11c25e4cf2129404de5e46c2 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Jun 4, 2013 at 3:01 PM, Douglas Crockford wrote: > > Keep in mind that this format has been working successfully in the wild > for over a decade. The goal here should be to do the least that is > necessary to formally upgrade its status from Informational, not to attempt > to fix something that is already working well enough. It is only because it > has been working well enough that we are considering the upgrade. Strongly agree. We should only be changing things that are incorrect or obsolete. You can't write an interoperable JSON implementation by reading RFC 4627 at the moment, but number precision is not one of the deal-breakers. - Rob --001a11c25e4cf2129404de5e46c2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, Jun 4, 2013 at 3:01 PM, Douglas Crockford <do= uglas@crockford.com> wrote:

Keep in mind that this format has been working successfully in the wild for= over a decade. The goal here should be to do the least that is necessary t= o formally upgrade its status from Informational, not to attempt to fix som= ething that is already working well enough. It is only because it has been = working well enough that we are considering the upgrade.


Strongly agree. We should only be changi= ng things that are incorrect or obsolete. You can't write an interopera= ble JSON implementation by reading RFC 4627 at the moment, but number preci= sion is not one of the deal-breakers.=A0

- Rob=A0
--001a11c25e4cf2129404de5e46c2-- From mamille2@cisco.com Tue Jun 4 18:46:22 2013 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 7829A21F9A7C for ; Tue, 4 Jun 2013 18:46:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.3 X-Spam-Level: X-Spam-Status: No, score=-9.3 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jpvV4MINrjCx for ; Tue, 4 Jun 2013 18:46:16 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 109A921F9A6C for ; Tue, 4 Jun 2013 18:46:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7060; q=dns/txt; s=iport; t=1370396776; x=1371606376; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=SGoE8cgWATGipSdDWkWxTqjcLblilK1fgh/dHwCjREM=; b=kT8yQk8TOupXOcamfFMt9CZi6y2Hzmxbcpo4lU9VoeMUKD0uU3PSDcuh gH8FQYBv3BegyF7r6WGUp7Kk2Kz+8aYmASCzQB+5oDZKiukiSDi5Vcaaj mGqVvLqk3X7Dml3YPSbtra0IgJhzBZUJBXMw8dfvc+gJRrDJ7zZSqTlUc k=; X-Files: smime.p7s : 4136 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApAFAICXrlGtJV2d/2dsb2JhbABagwmDJbw1gQAWdIIjAQEBAwF5BQsCAQgiJAIfESUCBA4FCAaHbQMJBrRuDYh1jEmCKjEHgnphA5AAgSyELI4EhSODD4In X-IronPort-AV: E=Sophos;i="4.87,803,1363132800"; d="p7s'?scan'208";a="218851566" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-8.cisco.com with ESMTP; 05 Jun 2013 01:46:15 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r551kFEZ025262 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 5 Jun 2013 01:46:15 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.24]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.02.0318.004; Tue, 4 Jun 2013 20:46:15 -0500 From: "Matt Miller (mamille2)" To: R S Thread-Topic: [Json] Limitations on number size? Thread-Index: AQHOYKhtiMKtDlrMGkiV0TSaDl838JklWmSAgAAq/YCAAGawgIAAQpQAgABB84CAAD0dgIAAAbgA Date: Wed, 5 Jun 2013 01:46:14 +0000 Message-ID: References: <51AE63B1.80800@crockford.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.21.123.195] Content-Type: multipart/signed; boundary="Apple-Mail=_2C4904B5-4160-47CD-9289-2AAB9129F3C7"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Cc: Nico Williams , Paul Hoffman , Douglas Crockford , "json@ietf.org" Subject: Re: [Json] Limitations on number size? X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 05 Jun 2013 01:46:22 -0000 --Apple-Mail=_2C4904B5-4160-47CD-9289-2AAB9129F3C7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On Jun 4, 2013, at 7:40 PM, R S wrote: > On Tue, Jun 4, 2013 at 3:01 PM, Douglas Crockford = wrote: >=20 >>=20 >> Keep in mind that this format has been working successfully in the = wild >> for over a decade. The goal here should be to do the least that is >> necessary to formally upgrade its status from Informational, not to = attempt >> to fix something that is already working well enough. It is only = because it >> has been working well enough that we are considering the upgrade. >=20 >=20 >=20 > Strongly agree. We should only be changing things that are incorrect = or > obsolete. You can't write an interoperable JSON implementation by = reading > RFC 4627 at the moment, but number precision is not one of the > deal-breakers. >=20 Would you be willing to contribute specific wording proposals to address = those deal-breakers? - m&m Matt Miller < mamille2@cisco.com > Cisco Systems, Inc. --Apple-Mail=_2C4904B5-4160-47CD-9289-2AAB9129F3C7 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMezCCBjQw ggQcoAMCAQICAR4wDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDE1NVoX DTE3MTAyNDIxMDE1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMcJg8zOLdgasSmkLhOrlr6KMoOMpohBllVHrdRvEg/q6r8jR+EK 75xCGhR8ToREoqe7zM9/UnC6TS2y9UKTpT1v7RSMzR0t6ndl0TWBuUr/UXBhPk+Kmy7bI4yW4urC +y7P3/1/X7U8ocb8VpH/Clt+4iq7nirMcNh6qJR+xjOhV+VHzQMALuGYn5KZmc1NbJQYclsGkDxD z2UbFqE2+6vIZoL+jb9x4Pa5gNf1TwSDkOkikZB1xtB4ZqtXThaABSONdfmv/Z1pua3FYxnCFmdr /+N2JLKutIxMYqQOJebr/f/h5t95m4JgrM3Y/w7YX9d7YAL9jvN4SydHsU6n65cCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRTcu2SnODaywFc fH6WNU7y1LhRgjAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBAAqDCH14qywG XLhjjF6uHLkjd02hcdh9hrw+VUsv+q1eeQWB21jWj3kJ96AUlPCoEGZ/ynJNScWy6QMVQjbbMXlt UfO4n4bGGdKo3awPWp61tjAFgraLJgDk+DsSvUD6EowjMTNx25GQgyYJ5RPIzKKR9tQW8gGK+2+R HxkUCTbYFnL6kl8Ch507rUdPPipJ9CgJFws3kDS3gOS5WFMxcjO5DwKfKSETEPrHh7p5shuuNktv sv6hxHTLhiMKX893gxdT3XLS9OKmCv87vkINQcNEcIIoFWbP9HORz9v3vQwR4e3ksLc2JZOAFK+s sS5XMEoznzpihEP0PLc4dCBYjbvSD7kxgDwZ+Aj8Q9PkbvE9sIPP7ON0fz095HdThKjiVJe6vofq +n6b1NBc8XdrQvBmunwxD5nvtTW4vtN6VY7mUCmxsCieuoBJ9OlqmsVWQvifIYf40dJPZkk9YgGT zWLpXDSfLSplbY2LL9C9U0ptvjcDjefLTvqSFc7tw1sEhF0n/qpA2r0GpvkLRDmcSwVyPvmjFBGq Up/pNy8ZuPGQmHwFi2/14+xeSUDG2bwnsYJQG2EdJCB6luQ57GEnTA/yKZSTKI8dDQa8Sd3zfXb1 9mOgSF0bBdXbuKhEpuP9wirslFe6fQ1t5j5R0xi72MZ8ikMu1RQZKCyDbMwazlHiMIIGPzCCBSeg AwIBAgIDBoRIMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcN MTMwNDMwMjE1NDQyWhcNMTQwNTAyMDUzOTA0WjBbMRkwFwYDVQQNExBiN2F6NndOY0t0R3JtMEpF MRswGQYDVQQDDBJtYW1pbGxlMkBjaXNjby5jb20xITAfBgkqhkiG9w0BCQEWEm1hbWlsbGUyQGNp c2NvLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJbKBMsG+9UFTx9uq/bhhXgu vJvO8z7cwKaqqwZhVf5z/kHFyCNijtmTOE+YXjA8mWR4aoBwB5SvGypI/cJUofJ+AlBTC4g+RMx/ K0Ab4/jQqTQz9CDzMOB+Wm+rt8ZJ7A8ZzOJmNDAsf/VvB8l2A1SQz1UsAixgH16NTr8SlblAXEKk 4hwpCudUiNjjQokqJ0H686UBKVorcZSgXaza8XMqGtJF/8mNhR9GQYi7Xht1ky+9LFOrto2daZto KJRwMeVusVdHUeKEQSu7jztw8HchH3KEb7Q+r5X+hhDZoddfKE8d5eyPuhiZdrzv7OlNZ0fSLdx7 3AE3nx9/R5YlXucCAwEAAaOCAtgwggLUMAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQW MBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQUxGd+/qrdVudHrIKkw5xOMY7eaLUwHwYD VR0jBBgwFoAUU3Ltkpzg2ssBXHx+ljVO8tS4UYIwHQYDVR0RBBYwFIESbWFtaWxsZTJAY2lzY28u Y29tMIIBTAYDVR0gBIIBQzCCAT8wggE7BgsrBgEEAYG1NwECAzCCASowLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0 Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBp c3N1ZWQgYWNjb3JkaW5nIHRvIHRoZSBDbGFzcyAxIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9m IHRoZSBTdGFydENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBw dXJwb3NlIGluIGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMDYG A1UdHwQvMC0wK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUxLWNybC5jcmwwgY4G CCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIv Y2xhc3MxL2NsaWVudC9jYTBCBggrBgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2Vy dHMvc3ViLmNsYXNzMS5jbGllbnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRz c2wuY29tLzANBgkqhkiG9w0BAQUFAAOCAQEAlDhXbGEI7lbqUcu5r2JHZaMsbRZda/99ZqODzWGX 0llou9jGccsAWDPPwRRe2+ROpXfH4cuJZElTcLDeZSp/qpXKhjYieFSX8+Ml9sKEj5UOSqQLyoLk PtrIJV12Jk3nuG2Jc0UeEnGwK/aqtzy7+bfEVI0ziyVM2gChHh0RH74KyiwYWknbOTRIkZcz/ulE DVFQp63uj6wfmDNvAUHBAdhKVqA1S/rfP1KcDZpf1NfvwXJibiqTRA6K1EOxTJOP41n/XdvHqHXL RWL2xrOUI9/URANr/ok3OrsuZEMFnAAGefS1bWS/hFtUGVkHGiKEBbyDW7da2ULXbuC7umrQnzGC A28wggNrAgEBMIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkG A1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwaESDAJBgUrDgMCGgUA oIIBrzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMzA2MDUwMTQ2 MTVaMCMGCSqGSIb3DQEJBDEWBBRA15g4dHSjFXHljWwI8YFNLmNEHzCBpQYJKwYBBAGCNxAEMYGX MIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3Mg MSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwaESDCBpwYLKoZIhvcNAQkQAgsxgZeg gZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1 cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAx IFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDBoRIMA0GCSqGSIb3DQEBAQUABIIBAIQW GQV/yG+ilTJlkzkAiZ0CqGlklyNThjfF/7AIj3AA0jgrvicFw5PJfK1F3FU6HO6MbfAq9vv+Q7oH N4pLqzR7+jiQAvfKqdxmXMR5OwAfwBGO/sW1/gm4Qh8Qgvf8h2Dpg0rYQu3T+tQDGUwPW623COgG IpjhQTqMyjR7nXqjBctHRxTFT3ZKTvEobMpa1GLYJW00CkFQdrfahJiW5xHuR1E7h5fUYe73uXD6 2nClccOeAYgbiqQ4s+RRIZgVjTYBEI5E07D5mEVxzmf5JzHFhS/+JJJ1H6GIQQgZK3eRH3CaEjjf mrE1tLHA7CB81dp5T2N1cE0OE9IUQkFDVo0AAAAAAAA= --Apple-Mail=_2C4904B5-4160-47CD-9289-2AAB9129F3C7-- From mamille2@cisco.com Tue Jun 4 18:51:08 2013 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 6FE0D21F9638 for ; Tue, 4 Jun 2013 18:51:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.953 X-Spam-Level: X-Spam-Status: No, score=-9.953 tagged_above=-999 required=5 tests=[AWL=-0.646, BAYES_00=-2.599, MISSING_HEADERS=1.292, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eobnsK147fG0 for ; Tue, 4 Jun 2013 18:50:33 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 0CFEE21F9A87 for ; Tue, 4 Jun 2013 18:50:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6726; q=dns/txt; s=iport; t=1370397032; x=1371606632; h=from:cc:subject:date:message-id:references:in-reply-to: mime-version; bh=53yIC71p5vrWag8crwyTm/q2Oai0aBm60JBl0QlJdzc=; b=hbvkfv+5e+w9HFmPEadEN3cYQx56HnFtsopfu+qB7e+f8MtanMz5S4JR ZEp2864Dk5Gxv8yl7vgjgMLDsmHJ0K1FDqcSZTvHbrTJblPkPyz18cw56 gxoNODGIaznHCsRCQlYQNYZn1k9A/CgKjLOyR1KqfBM6t7UoAOf1+/h8r w=; X-Files: smime.p7s : 4136 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArAFAB+YrlGtJXG+/2dsb2JhbABagwmDJbw1GWcWdIIbCQEBBHkQAgEIIiQCMCUCEgUIBoVoghe9bo5zMQeCVSVhA5AAgSyXU4MPgic X-IronPort-AV: E=Sophos;i="4.87,803,1363132800"; d="p7s'?scan'208";a="215883542" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-9.cisco.com with ESMTP; 05 Jun 2013 01:50:15 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r551oEtW012538 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 5 Jun 2013 01:50:14 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.24]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.02.0318.004; Tue, 4 Jun 2013 20:50:14 -0500 From: "Matt Miller (mamille2)" Thread-Topic: [Json] Proposed change: update the Unicode version Thread-Index: AQHOYUwcEVXhzbeP6EGj0XkggNKAG5kmK8CAgAAQAwCAABqRgIAAJU4AgAAAqoCAAAEIAIAABL+AgAAtMIA= Date: Wed, 5 Jun 2013 01:50:14 +0000 Message-ID: References: <51AE6E95.3050007@stpeter.im> <51AE736D.7030209@stpeter.im> In-Reply-To: <51AE736D.7030209@stpeter.im> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.21.123.195] Content-Type: multipart/signed; boundary="Apple-Mail=_E3482835-B1F4-4E98-AD53-3896C0CD0D47"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Cc: Peter Saint-Andre , Tim Bray , Paul Hoffman , "Joe Hildebrand \(jhildebr\)" , "json@ietf.org" Subject: Re: [Json] Proposed change: update the Unicode version X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 05 Jun 2013 01:51:09 -0000 --Apple-Mail=_E3482835-B1F4-4E98-AD53-3896C0CD0D47 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=windows-1252 To gather this together, the proposed changes look to be: 1) In 1. Introduction -- #### OLD TEXT: A string is a sequence of zero or more Unicode characters [UNICODE]. #### NEW TEXT: A string is a sequence of zero or more Unicode characters defined in version 6.2 (or any subsequent version) of [UNICODE] #### 2) In 3. Encoding -- #### OLD TEXT: JSON text SHALL be encoded in Unicode. The default encoding is UTF-8. #### NEW TEXT: JSON text takes the form of a Unicode string [UNICODE, section 2.7]; the default encoding is UTF-8. #### Correct? - m&m Matt Miller < mamille2@cisco.com > Cisco Systems, Inc. --Apple-Mail=_E3482835-B1F4-4E98-AD53-3896C0CD0D47 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMezCCBjQw ggQcoAMCAQICAR4wDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDE1NVoX DTE3MTAyNDIxMDE1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMcJg8zOLdgasSmkLhOrlr6KMoOMpohBllVHrdRvEg/q6r8jR+EK 75xCGhR8ToREoqe7zM9/UnC6TS2y9UKTpT1v7RSMzR0t6ndl0TWBuUr/UXBhPk+Kmy7bI4yW4urC +y7P3/1/X7U8ocb8VpH/Clt+4iq7nirMcNh6qJR+xjOhV+VHzQMALuGYn5KZmc1NbJQYclsGkDxD z2UbFqE2+6vIZoL+jb9x4Pa5gNf1TwSDkOkikZB1xtB4ZqtXThaABSONdfmv/Z1pua3FYxnCFmdr /+N2JLKutIxMYqQOJebr/f/h5t95m4JgrM3Y/w7YX9d7YAL9jvN4SydHsU6n65cCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRTcu2SnODaywFc fH6WNU7y1LhRgjAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBAAqDCH14qywG XLhjjF6uHLkjd02hcdh9hrw+VUsv+q1eeQWB21jWj3kJ96AUlPCoEGZ/ynJNScWy6QMVQjbbMXlt UfO4n4bGGdKo3awPWp61tjAFgraLJgDk+DsSvUD6EowjMTNx25GQgyYJ5RPIzKKR9tQW8gGK+2+R HxkUCTbYFnL6kl8Ch507rUdPPipJ9CgJFws3kDS3gOS5WFMxcjO5DwKfKSETEPrHh7p5shuuNktv sv6hxHTLhiMKX893gxdT3XLS9OKmCv87vkINQcNEcIIoFWbP9HORz9v3vQwR4e3ksLc2JZOAFK+s sS5XMEoznzpihEP0PLc4dCBYjbvSD7kxgDwZ+Aj8Q9PkbvE9sIPP7ON0fz095HdThKjiVJe6vofq +n6b1NBc8XdrQvBmunwxD5nvtTW4vtN6VY7mUCmxsCieuoBJ9OlqmsVWQvifIYf40dJPZkk9YgGT zWLpXDSfLSplbY2LL9C9U0ptvjcDjefLTvqSFc7tw1sEhF0n/qpA2r0GpvkLRDmcSwVyPvmjFBGq Up/pNy8ZuPGQmHwFi2/14+xeSUDG2bwnsYJQG2EdJCB6luQ57GEnTA/yKZSTKI8dDQa8Sd3zfXb1 9mOgSF0bBdXbuKhEpuP9wirslFe6fQ1t5j5R0xi72MZ8ikMu1RQZKCyDbMwazlHiMIIGPzCCBSeg AwIBAgIDBoRIMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcN MTMwNDMwMjE1NDQyWhcNMTQwNTAyMDUzOTA0WjBbMRkwFwYDVQQNExBiN2F6NndOY0t0R3JtMEpF MRswGQYDVQQDDBJtYW1pbGxlMkBjaXNjby5jb20xITAfBgkqhkiG9w0BCQEWEm1hbWlsbGUyQGNp c2NvLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJbKBMsG+9UFTx9uq/bhhXgu vJvO8z7cwKaqqwZhVf5z/kHFyCNijtmTOE+YXjA8mWR4aoBwB5SvGypI/cJUofJ+AlBTC4g+RMx/ K0Ab4/jQqTQz9CDzMOB+Wm+rt8ZJ7A8ZzOJmNDAsf/VvB8l2A1SQz1UsAixgH16NTr8SlblAXEKk 4hwpCudUiNjjQokqJ0H686UBKVorcZSgXaza8XMqGtJF/8mNhR9GQYi7Xht1ky+9LFOrto2daZto KJRwMeVusVdHUeKEQSu7jztw8HchH3KEb7Q+r5X+hhDZoddfKE8d5eyPuhiZdrzv7OlNZ0fSLdx7 3AE3nx9/R5YlXucCAwEAAaOCAtgwggLUMAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQW MBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQUxGd+/qrdVudHrIKkw5xOMY7eaLUwHwYD VR0jBBgwFoAUU3Ltkpzg2ssBXHx+ljVO8tS4UYIwHQYDVR0RBBYwFIESbWFtaWxsZTJAY2lzY28u Y29tMIIBTAYDVR0gBIIBQzCCAT8wggE7BgsrBgEEAYG1NwECAzCCASowLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0 Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBp c3N1ZWQgYWNjb3JkaW5nIHRvIHRoZSBDbGFzcyAxIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9m IHRoZSBTdGFydENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBw dXJwb3NlIGluIGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMDYG A1UdHwQvMC0wK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUxLWNybC5jcmwwgY4G CCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIv Y2xhc3MxL2NsaWVudC9jYTBCBggrBgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2Vy dHMvc3ViLmNsYXNzMS5jbGllbnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRz c2wuY29tLzANBgkqhkiG9w0BAQUFAAOCAQEAlDhXbGEI7lbqUcu5r2JHZaMsbRZda/99ZqODzWGX 0llou9jGccsAWDPPwRRe2+ROpXfH4cuJZElTcLDeZSp/qpXKhjYieFSX8+Ml9sKEj5UOSqQLyoLk PtrIJV12Jk3nuG2Jc0UeEnGwK/aqtzy7+bfEVI0ziyVM2gChHh0RH74KyiwYWknbOTRIkZcz/ulE DVFQp63uj6wfmDNvAUHBAdhKVqA1S/rfP1KcDZpf1NfvwXJibiqTRA6K1EOxTJOP41n/XdvHqHXL RWL2xrOUI9/URANr/ok3OrsuZEMFnAAGefS1bWS/hFtUGVkHGiKEBbyDW7da2ULXbuC7umrQnzGC A28wggNrAgEBMIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkG A1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwaESDAJBgUrDgMCGgUA oIIBrzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMzA2MDUwMTUw MTRaMCMGCSqGSIb3DQEJBDEWBBSb/tIdtnQbvq9gAEwhbib/IV8gQjCBpQYJKwYBBAGCNxAEMYGX MIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3Mg MSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwaESDCBpwYLKoZIhvcNAQkQAgsxgZeg gZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1 cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAx IFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDBoRIMA0GCSqGSIb3DQEBAQUABIIBAGcP AhCoiTHo5GvTjbg/fogQVPClsmZokcH/mzKvZ25BQ4+wyTd8hWZtKT3w+afHLxsN5pNbclgaggg6 cFShCGhLFo7abzP2vsh8rc9ypJxfhHAylv245JxO91Up+C8h6fEpMByw6gNqEM0CsvV3J19N/t/z wx6UDAoUTP1Ch3NOZpZcs1X9HfJar/S5KgJ+2EnfFsGdnCGNoysPUW1cdEAwUVQaPZOM7UD884mw ClPboPWLzfKEp/Ramp99B4CWkvObOkDxVH9dY9AxBQrOtYg4WiNFTTpk+AUGeWkor4YZ+OHddH+D DnOwx7AUcQYnSW4D7itcuBjIwHWHkWu/28oAAAAAAAA= --Apple-Mail=_E3482835-B1F4-4E98-AD53-3896C0CD0D47-- From sayrer@gmail.com Tue Jun 4 19:07:02 2013 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 76B2521F9AE5 for ; Tue, 4 Jun 2013 19:07:02 -0700 (PDT) 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=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i6rvf2O9d72O for ; Tue, 4 Jun 2013 19:07:00 -0700 (PDT) Received: from mail-wg0-x235.google.com (mail-wg0-x235.google.com [IPv6:2a00:1450:400c:c00::235]) by ietfa.amsl.com (Postfix) with ESMTP id 51CCA21F9ADA for ; Tue, 4 Jun 2013 19:06:59 -0700 (PDT) Received: by mail-wg0-f53.google.com with SMTP id c11so821835wgh.8 for ; Tue, 04 Jun 2013 19:06:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=QJeGQnCBdBTwa0QpOvnE96O5MchB7Tol7hAsDXnZ4ok=; b=E6//52QDOaXV8VEMoO+9+7YyEv+AHx4JKK3O2Ypzt8x8kVRV2wXYoGc/yztrJJUvMF MGomDnC9YwcXCmEJ6et0vbU+rVsAwZS2yb7I5tKHJ8bSxVWRI5Qe5aHrLVhh7XxpZzKC D/hvGYGvZbhnncqrDF5znvk/IyK6UqiNJCJF6+f8kctCTR4RPC0a3KeG1PlwGy7H1HCQ j3CBor1JOcpdaoCguLx9v1F6X97zfSnk9ibdJRS9i1CCKtBLTijV2k8iwk9lFAojeFuF h3efReko8Jo0wBuRWgdeCOjrRWp8HHRf8WAYy90r0huVWehkFl5Hj84NHH7vGD8bcGk0 SkcQ== MIME-Version: 1.0 X-Received: by 10.181.13.42 with SMTP id ev10mr4164789wid.1.1370397987509; Tue, 04 Jun 2013 19:06:27 -0700 (PDT) Received: by 10.194.83.35 with HTTP; Tue, 4 Jun 2013 19:06:27 -0700 (PDT) In-Reply-To: References: <51AE63B1.80800@crockford.com> Date: Tue, 4 Jun 2013 19:06:27 -0700 Message-ID: From: R S To: "Matt Miller (mamille2)" Content-Type: multipart/alternative; boundary=f46d04388df13f1e1404de5ea542 Cc: Nico Williams , Paul Hoffman , Douglas Crockford , "json@ietf.org" Subject: Re: [Json] Limitations on number size? X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 05 Jun 2013 02:07:02 -0000 --f46d04388df13f1e1404de5ea542 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Jun 4, 2013 at 6:46 PM, Matt Miller (mamille2) wrote: > > On Jun 4, 2013, at 7:40 PM, R S > wrote: > > > On Tue, Jun 4, 2013 at 3:01 PM, Douglas Crockford >wrote: > > > >> > >> Keep in mind that this format has been working successfully in the wild > >> for over a decade. The goal here should be to do the least that is > >> necessary to formally upgrade its status from Informational, not to > attempt > >> to fix something that is already working well enough. It is only > because it > >> has been working well enough that we are considering the upgrade. > > > > > > > > Strongly agree. We should only be changing things that are incorrect or > > obsolete. You can't write an interoperable JSON implementation by reading > > RFC 4627 at the moment, but number precision is not one of the > > deal-breakers. > > > > Would you be willing to contribute specific wording proposals to address > those deal-breakers? > Sure. I wrote a reasonably good JSON implementation after RFC 4627 but before ES5, and then had to update it to work on the Internet after ES5. We also have code at my current employer that will break if certain numbers are not transmitted as strings. It's workable, although inconvenient. That said, I am also pretty sure that Douglas knows which changes from ES5 need to go in. The main concerns for me are changes to the grammar that allow more than just objects and arrays as the root value, and the allowance in RFC 4627 for syntactic extensions (that is not realistic given ES5 rules). On the issue at hand, it might be good to rewrite the beginning of the "Number" section along these lines: - The representation of numbers is similar to that used in most programming languages. + JSON numbers are arbitrary precision, and represented in a manner similar to that used in most programming languages. The current RFC is a little under-specified. - Rob --f46d04388df13f1e1404de5ea542 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, Jun 4, 2013 at 6:46 PM, Matt Miller (mamille2) <= mamille2@cisco.com> wrote:

On Jun 4, 2013, at 7:40 PM, R S <say= rer@gmail.com>
=A0wrote:

> On Tue, Jun 4, 2013 at 3:01 PM, Douglas Crockford <douglas@crockford.com>wrote:
>
>>
>> Keep in mind that this format has been working successfully in the= wild
>> for over a decade. The goal here should be to do the least that is=
>> necessary to formally upgrade its status from Informational, not t= o attempt
>> to fix something that is already working well enough. It is only b= ecause it
>> has been working well enough that we are considering the upgrade.<= br> >
>
>
> Strongly agree. We should only be changing things that are incorrect o= r
> obsolete. You can't write an interoperable JSON implementation by = reading
> RFC 4627 at the moment, but number precision is not one of the
> deal-breakers.
>

Would you be willing to contribute specific wording proposals t= o address those deal-breakers?
=A0

Sure. I wrote a reasonably good JSON implementation after RFC 4627 bu= t before ES5, and then had to update it to work on the Internet after ES5. = We also have code at my current employer that will break if certain numbers= are not transmitted as strings. It's workable, although inconvenient.<= /div>

That said, I am also pretty sure that Douglas knows whi= ch changes from ES5 need to go in. The main concerns for me are changes to = the grammar that allow more than just objects and arrays as the root value,= and the allowance in RFC 4627 for syntactic extensions (that is not realis= tic given ES5 rules).

On the issue at hand, it might be good to rewrite the b= eginning of the "Number" section along these lines:
- The representation of numbers is similar to that used in most= programming languages.
+ JSON numbers are arbitrary precision, and represented in a manner si= milar to that used in most programming languages.

= The current RFC is a little under-specified.

- Rob=
--f46d04388df13f1e1404de5ea542-- From tbray@textuality.com Tue Jun 4 19:48:06 2013 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 3646521F9B10 for ; Tue, 4 Jun 2013 19:48:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.643 X-Spam-Level: X-Spam-Status: No, score=-0.643 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, GB_I_LETTER=-2, HTML_MESSAGE=0.001, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fHRg5bNFCJHL for ; Tue, 4 Jun 2013 19:48:02 -0700 (PDT) Received: from mail-ve0-x22b.google.com (mail-ve0-x22b.google.com [IPv6:2607:f8b0:400c:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id BBD5521F9B15 for ; Tue, 4 Jun 2013 19:48:01 -0700 (PDT) Received: by mail-ve0-f171.google.com with SMTP id b10so840412vea.2 for ; Tue, 04 Jun 2013 19:48:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=338AgPIHR2unA3vOlOVn1OIFRT/ddkSnOBbOG75ghTM=; b=PT5jGjUczRuziiEWu9SZyKYA0w77ihv30HpwJPUvHodJ/mHzCkPcAc/3Fz+y9WnhZp vvNKqLCn8eTMmLr9XJOe7imtQVr4zA/aBiYWifvnfaNRMHotvI1j03XFMbB0c11SPrPY gMs3NcyxQkf0Ns5Ltad/GEhsKH8sNIelCB7SbadJ/m3MeftyPs0OtU8h9xTqTn65XwHz DZ5UGuaDOUWtiYTuM1qYuTExlcbrWjuQQ9i3/bVTDhd/MWcRAFeLpNyFuJGYK71XZzXN l4gYYlwibqa1jYYsQuwY+08un8J4mhH544OtKd+6M2CK41QH2N0BsiAv/3kvW46c8J5c q4Vw== MIME-Version: 1.0 X-Received: by 10.58.6.141 with SMTP id b13mr19933050vea.45.1370400480964; Tue, 04 Jun 2013 19:48:00 -0700 (PDT) Received: by 10.220.48.14 with HTTP; Tue, 4 Jun 2013 19:48:00 -0700 (PDT) X-Originating-IP: [24.84.235.32] In-Reply-To: References: <51AE63B1.80800@crockford.com> Date: Tue, 4 Jun 2013 19:48:00 -0700 Message-ID: From: Tim Bray To: R S Content-Type: multipart/alternative; boundary=047d7b672c48de4ab304de5f3906 X-Gm-Message-State: ALoCoQkbczG7Bf1gXoV67wuY8EgNDZjUSzhaBCpjDCJef8v+ylScjKe8x3/Dh2e9TnUtlmgikDMD Cc: Nico Williams , "json@ietf.org" , Paul Hoffman , Douglas Crockford , "Matt Miller \(mamille2\)" Subject: Re: [Json] Limitations on number size? X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 05 Jun 2013 02:48:06 -0000 --047d7b672c48de4ab304de5f3906 Content-Type: text/plain; charset=UTF-8 Yeah, the number specification is a little flabby and omits the fact that the base is 10 The representation of numbers is similar to that used in most programming languages. A number contains an integer component that may be prefixed with an optional minus sign, which may be followed by a fraction part and/or an exponent part. Octal and hex forms are not allowed. Leading zeros are not allowed. A fraction part is a decimal point followed by one or more digits. An exponent part begins with the letter E in upper or lowercase, which may be followed by a plus or minus sign. The E and optional sign are followed by one or more digits. A number is represented in base 10 with no leading zeroes or punctuation such as commas or spaces. It may have a preceding minus sign. It may have a "."-prefixed fractional part. It may have an exponent, prefixed by "e" or "E" and optionally "+" or "-". On Tue, Jun 4, 2013 at 7:06 PM, R S wrote: > On Tue, Jun 4, 2013 at 6:46 PM, Matt Miller (mamille2) > wrote: > >> >> On Jun 4, 2013, at 7:40 PM, R S >> wrote: >> >> > On Tue, Jun 4, 2013 at 3:01 PM, Douglas Crockford < >> douglas@crockford.com>wrote: >> > >> >> >> >> Keep in mind that this format has been working successfully in the wild >> >> for over a decade. The goal here should be to do the least that is >> >> necessary to formally upgrade its status from Informational, not to >> attempt >> >> to fix something that is already working well enough. It is only >> because it >> >> has been working well enough that we are considering the upgrade. >> > >> > >> > >> > Strongly agree. We should only be changing things that are incorrect or >> > obsolete. You can't write an interoperable JSON implementation by >> reading >> > RFC 4627 at the moment, but number precision is not one of the >> > deal-breakers. >> > >> >> Would you be willing to contribute specific wording proposals to address >> those deal-breakers? >> > > > Sure. I wrote a reasonably good JSON implementation after RFC 4627 but > before ES5, and then had to update it to work on the Internet after ES5. We > also have code at my current employer that will break if certain numbers > are not transmitted as strings. It's workable, although inconvenient. > > That said, I am also pretty sure that Douglas knows which changes from ES5 > need to go in. The main concerns for me are changes to the grammar that > allow more than just objects and arrays as the root value, and the > allowance in RFC 4627 for syntactic extensions (that is not realistic given > ES5 rules). > > On the issue at hand, it might be good to rewrite the beginning of the > "Number" section along these lines: > > - The representation of numbers is similar to that used in most > programming languages. > + JSON numbers are arbitrary precision, and represented in a manner > similar to that used in most programming languages. > > The current RFC is a little under-specified. > > - Rob > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > > --047d7b672c48de4ab304de5f3906 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Yeah, the number specif= ication is a little flabby and omits the fact that the base is 10
= <old>=C2=A0
=C2=A0=C2=A0 The representation of numbers is similar= to that used in most
=C2=A0=C2=A0 programming languages.=C2=A0 A number contains an integer comp= onent that
=C2=A0=C2=A0 may be prefixed with an optional minus sign, whi= ch may be followed by
=C2=A0=C2=A0 a fraction part and/or an exponent pa= rt.

=C2=A0=C2=A0 Octal and hex forms are not allowed.=C2=A0 Leading = zeros are not allowed.

=C2=A0=C2=A0 A fraction part is a decimal point followed by one or more= digits.

=C2=A0=C2=A0 An exponent part begins with the letter E in u= pper or lowercase,
=C2=A0=C2=A0 which may be followed by a plus or minus= sign.=C2=A0 The E and optional
=C2=A0=C2=A0 sign are followed by one or more digits.
</old>=

<proposal>
A number is repre= sented in base 10 with no leading zeroes or punctuation such as=C2=A0 comma= s or spaces.=C2=A0 It may have a preceding minus sign.=C2=A0 It may have a = "."-prefixed fractional part. It may have an exponent, prefixed b= y "e" or "E" and optionally "+" or "-&qu= ot;.
</proposal>

=


On Tue, Jun 4, 2013 at 7:06 PM, R S <sayrer@gmail.com> w= rote:
On T= ue, Jun 4, 2013 at 6:46 PM, Matt Miller (mamille2) <mamille2@cisco.com> wrote:

On Jun 4, 2013, at 7:40 PM, R S <sayrer@gmail.com>
=C2=A0wrote:

> On Tue, Jun 4, 2013 at 3:01 PM, Douglas Crockford <douglas@crockford.com>wro= te:
>
>>
>> Keep in mind that this format has been working successfully in the= wild
>> for over a decade. The goal here should be to do the least that is=
>> necessary to formally upgrade its status from Informational, not t= o attempt
>> to fix something that is already working well enough. It is only b= ecause it
>> has been working well enough that we are considering the upgrade.<= br> >
>
>
> Strongly agree. We should only be changing things that are incorrect o= r
> obsolete. You can't write an interoperable JSON implementation by = reading
> RFC 4627 at the moment, but number precision is not one of the
> deal-breakers.
>

Would you be willing to contribute specific wording proposals t= o address those deal-breakers?
=C2=A0

Sure. I wrote a reasonably good JSON implementation af= ter RFC 4627 but before ES5, and then had to update it to work on the Inter= net after ES5. We also have code at my current employer that will break if = certain numbers are not transmitted as strings. It's workable, although= inconvenient.

That said, I am also pretty sure that Douglas knows whi= ch changes from ES5 need to go in. The main concerns for me are changes to = the grammar that allow more than just objects and arrays as the root value,= and the allowance in RFC 4627 for syntactic extensions (that is not realis= tic given ES5 rules).

On the issue at hand, it might be good to rewrite the b= eginning of the "Number" section along these lines:
- The representation of numbers is similar to that used in most= programming languages.
+ JSON numbers are arbitrary precision, and represented in a manner si= milar to that used in most programming languages.

= The current RFC is a little under-specified.

- Rob

_______________________________________________
json mailing list
json@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/json


--047d7b672c48de4ab304de5f3906-- From nico@cryptonector.com Tue Jun 4 21:05:49 2013 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 E2B2521F9AF7 for ; Tue, 4 Jun 2013 21:05:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.852 X-Spam-Level: X-Spam-Status: No, score=-1.852 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qoLJfLrTVKuY for ; Tue, 4 Jun 2013 21:05:45 -0700 (PDT) Received: from homiemail-a63.g.dreamhost.com (caiajhbdcaib.dreamhost.com [208.97.132.81]) by ietfa.amsl.com (Postfix) with ESMTP id 2DE8221F9AFD for ; Tue, 4 Jun 2013 21:05:43 -0700 (PDT) Received: from homiemail-a63.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a63.g.dreamhost.com (Postfix) with ESMTP id 8643B2F406A for ; Tue, 4 Jun 2013 21:05:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=LiiFPoAXZTuF/gZUGOEd arm4et8=; b=TmBQPGY/NR0Ypd+JSMFpnSHpgWlwZPP+SwVyFG3bcZQINvcGzOLs bkCrJaGBlhSXPd7RcewStj4lfyBwGRH6Ao+pcgH6y97JGX4eonKORjftg+j1Yhyr PAVw/TBRAK2RMbSQH3SHXcSmMorL6oscQ298cCfp6E+jRqLeUHstE3k= Received: from mail-wi0-f177.google.com (mail-wi0-f177.google.com [209.85.212.177]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a63.g.dreamhost.com (Postfix) with ESMTPSA id 312972F4059 for ; Tue, 4 Jun 2013 21:05:42 -0700 (PDT) Received: by mail-wi0-f177.google.com with SMTP id hr14so859817wib.10 for ; Tue, 04 Jun 2013 21:05:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=5yDEpww80qnfBGwu9LgzjWjYgUQ4R90bJ0LEs1hrVJM=; b=UYRo3Rk0rzHpCtPJWj0+SH3wAnHjaUDNwRtN8SN98SKMaofp+OxygtHbOtRPAyyWHe UD5AUIIO8FhSzQq7Euy24I+WEO6+47wFHCtrcjoYGzuzxOvcOXnmxWaL66X8Af0yxxSu 6jHBQSYFZYPi5xjapSqet3BWAbdUT8g+SMlOUrIjrn4Izku2s0ZQGb3o7ohCmJy5f3Ar KcZz3dmiqBFvoSnSYo+hhBUd2K60t78FbPx9E9TWn2TEJGuRulI8J7oVFNdkLoG+bHtD D2zBeMcXowVRjqZIi3FE8mboKZ4qVdPQtkP41+4sftXpnm48G1lIKfSCZfN14Kupbha+ NBkQ== MIME-Version: 1.0 X-Received: by 10.180.183.139 with SMTP id em11mr4457208wic.16.1370405140818; Tue, 04 Jun 2013 21:05:40 -0700 (PDT) Received: by 10.216.63.136 with HTTP; Tue, 4 Jun 2013 21:05:40 -0700 (PDT) In-Reply-To: References: <51AE63B1.80800@crockford.com> Date: Tue, 4 Jun 2013 23:05:40 -0500 Message-ID: From: Nico Williams To: R S Content-Type: text/plain; charset=UTF-8 Cc: "json@ietf.org" , Paul Hoffman , Douglas Crockford , "Matt Miller \(mamille2\)" Subject: Re: [Json] Limitations on number size? X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 05 Jun 2013 04:05:50 -0000 On Tue, Jun 4, 2013 at 9:06 PM, R S wrote: > On the issue at hand, it might be good to rewrite the beginning of the > "Number" section along these lines: > > - The representation of numbers is similar to that used in most programming > languages. > + JSON numbers are arbitrary precision, and represented in a manner similar > to that used in most programming languages. It might be nice to be able to specify some ranges that MUST be supported by decoders, but in practice I think we can't (and probably shouldn't try to) even do that. Nico -- From sayrer@gmail.com Tue Jun 4 22:23:14 2013 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 EF69221F9A1B for ; Tue, 4 Jun 2013 22:23:14 -0700 (PDT) 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=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vW26+nnOIDNE for ; Tue, 4 Jun 2013 22:23:14 -0700 (PDT) Received: from mail-we0-x22f.google.com (mail-we0-x22f.google.com [IPv6:2a00:1450:400c:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 1AE2B21F9A1A for ; Tue, 4 Jun 2013 22:23:13 -0700 (PDT) Received: by mail-we0-f175.google.com with SMTP id t59so910147wes.20 for ; Tue, 04 Jun 2013 22:23:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=0hekzcIZFy2SmEa0hVKK8EpRoPH8i7557p1EhoqDyzg=; b=ipdXeqoKm1pDg9rd2jzrrM66c4LjdCsXyYVxGdu3A6L9gmf3g1bvAKA0wnmfTp2+2F RzAHNL7YmrmoKPQBBuj4RBr/Iz7U4yuhofjJM168sNNX40tAgevZDt5JJstwlPSUcEAE iy8hef5LSx7dLqwJ+TQRy2y5I0d5Hj1ac0sDtH3ezRudKrxARqvyGDJKf3vJliaQqWTu Kwqed2zCBYU8s4wySGs2V2GSHxEqsB+L7fWPT8NAZSmKkW5K0SmLpT8invbys2Z1qZ43 18IJvW/QYtj1Z5exa1RWTdxMybTHebG94z+zvBSDWUYftVg3RHOKqyN59CZV1WiVS/dZ 5ihA== MIME-Version: 1.0 X-Received: by 10.181.13.42 with SMTP id ev10mr4740461wid.1.1370409793151; Tue, 04 Jun 2013 22:23:13 -0700 (PDT) Received: by 10.194.83.35 with HTTP; Tue, 4 Jun 2013 22:23:13 -0700 (PDT) In-Reply-To: References: <51AE63B1.80800@crockford.com> Date: Tue, 4 Jun 2013 22:23:13 -0700 Message-ID: From: R S To: Nico Williams Content-Type: multipart/alternative; boundary=f46d04388df1eaeb1504de61641f Cc: "json@ietf.org" , Paul Hoffman , Douglas Crockford , "Matt Miller \(mamille2\)" Subject: Re: [Json] Limitations on number size? X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 05 Jun 2013 05:23:15 -0000 --f46d04388df1eaeb1504de61641f Content-Type: text/plain; charset=ISO-8859-1 On Tue, Jun 4, 2013 at 9:05 PM, Nico Williams wrote: > On Tue, Jun 4, 2013 at 9:06 PM, R S wrote: > > On the issue at hand, it might be good to rewrite the beginning of the > > "Number" section along these lines: > > > > - The representation of numbers is similar to that used in most > programming > > languages. > > + JSON numbers are arbitrary precision, and represented in a manner > similar > > to that used in most programming languages. > > It might be nice to be able to specify some ranges that MUST be > supported by decoders, but in practice I think we can't (and probably > shouldn't try to) even do that. > Agreed that we shouldn't try. That's one of the most toxic standards group activities: Moving Blame Around. The real problem is that number ranges differ between systems--something that has nothing to do with JSON. The ship has sailed. Besides, most JSON numbers fit in 32 bits, and most JSON values are strings. - Rob --f46d04388df1eaeb1504de61641f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, Jun 4, 2013 at 9:05 PM, Nico Williams <nico@c= ryptonector.com> wrote:
On Tue, Jun 4, 2013 at 9:0= 6 PM, R S <sayrer@gmail.com> = wrote:
> On the issue at hand, it might be good to rewrite the beginning of the=
> "Number" section along these lines:
>
> - The representation of numbers is similar to that used in most progra= mming
> languages.
> + JSON numbers are arbitrary precision, and represented in a manner si= milar
> to that used in most programming languages.

It might be nice to be able to specify some ranges that MUST be
supported by decoders, but in practice I think we can't (and probably shouldn't try to) even do that.

Agreed that we shouldn't try. That's one of the most to= xic standards group activities: Moving Blame Around.

The real problem is that number ranges differ between systems--somethi= ng that has nothing to do with JSON.

The ship has = sailed. Besides, most JSON numbers fit in 32 bits, and most JSON values are= strings.

- Rob=A0
--f46d04388df1eaeb1504de61641f-- From internet-drafts@ietf.org Wed Jun 5 08:39:03 2013 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 8794B21F9AD1; Wed, 5 Jun 2013 08:39:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.477 X-Spam-Level: X-Spam-Status: No, score=-102.477 tagged_above=-999 required=5 tests=[AWL=0.123, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cteJd-8p1vck; Wed, 5 Jun 2013 08:38:51 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5039921F9700; Wed, 5 Jun 2013 08:38:51 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.50 Message-ID: <20130605153851.23495.91617.idtracker@ietfa.amsl.com> Date: Wed, 05 Jun 2013 08:38:51 -0700 Cc: json@ietf.org Subject: [Json] I-D Action: draft-ietf-json-rfc4627bis-00.txt X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 05 Jun 2013 15:39:04 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the JavaScript Object Notation Working Group = of the IETF. Title : The application/json Media Type for JavaScript Object No= tation (JSON) Author(s) : Douglas Crockford Filename : draft-ietf-json-rfc4627bis-00.txt Pages : 11 Date : 2013-06-05 Abstract: JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format. It was derived from the ECMAScript Programming Language Standard. JSON defines a small set of formatting rules for the portable representation of structured data. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-json-rfc4627bis There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-json-rfc4627bis-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From paul.hoffman@vpnc.org Wed Jun 5 08:41:12 2013 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 9E82721F9ADC for ; Wed, 5 Jun 2013 08:41:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WZMqsYATXcOW for ; Wed, 5 Jun 2013 08:41:12 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 2F03C21F9AB0 for ; Wed, 5 Jun 2013 08:41:12 -0700 (PDT) Received: from [10.20.30.90] (50-0-66-165.dsl.dynamic.sonic.net [50.0.66.165]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r55Ff9F2085298 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 5 Jun 2013 08:41:09 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) From: Paul Hoffman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: Date: Wed, 5 Jun 2013 08:41:09 -0700 To: "json@ietf.org" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) Subject: [Json] Proposed change to the title of the spec X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 05 Jun 2013 15:41:12 -0000 Current title: The application/json Media Type for JavaScript Object Notation (JSON) Proposed title: JavaScript Object Notation (JSON) --Paul Hoffman From cabo@tzi.org Wed Jun 5 08:52:02 2013 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 251B621F9AAE for ; Wed, 5 Jun 2013 08:52:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GJUQ6JtsNnw8 for ; Wed, 5 Jun 2013 08:51:52 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 1383B21F9AB1 for ; Wed, 5 Jun 2013 08:51:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r55FpfkA004987; Wed, 5 Jun 2013 17:51:41 +0200 (CEST) Received: from [127.0.0.1] (zoo.informatik.uni-bremen.de [134.102.218.16]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 032443788; Wed, 5 Jun 2013 17:51:40 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: Date: Wed, 5 Jun 2013 17:51:39 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <3B8F8F96-F7B6-4734-9553-087A993482A4@tzi.org> References: To: Paul Hoffman X-Mailer: Apple Mail (2.1503) Cc: "json@ietf.org" Subject: Re: [Json] Limitations on number size? X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 05 Jun 2013 15:52:02 -0000 On Jun 4, 2013, at 16:07, Paul Hoffman wrote: > And this is the point where one of the chairs says "please suggest = specific wording changes to RFC 4627". I like Tim's idea of a separate "best practices" document and look forward to the process of creating it (Popcorn!). However, some things need to be said in the specification. Here's my take: Relationship between JSON and JavaScript As the name implies, JSON was defined using the literal notation the JavaScript language uses for its data objects; some restrictions were made to make it more robust to potential changes in the JavaScript language. With that derivation made, JSON is now a specification separate from JavaScript. Properties of JavaScript (and changes to the JavaScript specification [ECMAscript]) do not automatically transfer to JSON. For example, considerations about the source character set for JavaScript programs do not influence what is admissible in a JSON document. Another example is the number format: JSON can represent numbers in arbitrary precision by just supplying the necessary number of decimal digits. JavaScript uses a number model derived from IEEE 754 binary double precision numbers; the precision and range it can represent natively therefore is a subset of the precision and range possible in JSON. This clear separation of the two specifications does not mean that users of JSON can always ignore JavaScript properties: A sizable part of the JSON ecosystem is either using JavaScript implementations or implementations that have been optimized for interaction with JavaScript implementations. Depending on the area of application, a JSON-based protocol may do well to consider JavaScript's specific properties. Discussion of best practices for JSON-based protocols is outside the scope of this specification. Here, we just want to point out that, for example, exclusively using numbers natively representable in JavaScript is not a requirement of the JSON format. Gr=FC=DFe, Carsten From tbray@textuality.com Wed Jun 5 09:06:20 2013 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 98F7121F9B33 for ; Wed, 5 Jun 2013 09:06:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.48 X-Spam-Level: X-Spam-Status: No, score=0.48 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_PBL=0.905, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8AFs6s-jiarn for ; Wed, 5 Jun 2013 09:06:11 -0700 (PDT) Received: from mail-la0-x234.google.com (mail-la0-x234.google.com [IPv6:2a00:1450:4010:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id 97BE921F9B7E for ; Wed, 5 Jun 2013 09:05:56 -0700 (PDT) Received: by mail-la0-f52.google.com with SMTP id fo13so1585654lab.25 for ; Wed, 05 Jun 2013 09:05:52 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=1BJ0TDWkIiCWeMbsO5ola+luMHXMQw12p3na72pEDbo=; b=cpHNgdwwVVq8FwPMrkGxVX4tVVY0iz4m2RRHRJufj2mzCrPVNc7OdCCXXFpqlxbAhP emeojRyPbvNu7I+eu8eH04NhEJ/J20FHAlOUiIwI/a/qD5vcG/S11Yq+iOKMynE19Nih aCJq/TqSJ7iNGpoVZEAm5U9+GU9znjL9QWWw5KRCNrdFQ6WYysnB4Hk67KZc++4yf5cr ud1b5IhOnBfb8lG1zTTksoOJ4kD2+TF++QQogeKh77DUznbPYcFiZHlj8P9JzzBymGo0 sWhL74iJkLtruaZLL9ZUgTEN/iyISrooQMrPenhyFv3ze2/zI7leYexiM4Cwb6QjiMZH 2v+g== MIME-Version: 1.0 X-Received: by 10.112.35.165 with SMTP id i5mr15534134lbj.17.1370448352394; Wed, 05 Jun 2013 09:05:52 -0700 (PDT) Received: by 10.114.83.232 with HTTP; Wed, 5 Jun 2013 09:05:52 -0700 (PDT) X-Originating-IP: [24.114.41.137] Received: by 10.114.83.232 with HTTP; Wed, 5 Jun 2013 09:05:52 -0700 (PDT) In-Reply-To: <3B8F8F96-F7B6-4734-9553-087A993482A4@tzi.org> References: <3B8F8F96-F7B6-4734-9553-087A993482A4@tzi.org> Date: Wed, 5 Jun 2013 09:05:52 -0700 Message-ID: From: Tim Bray To: Carsten Bormann Content-Type: multipart/alternative; boundary=001a11c36c8c3a574004de6a5ffe X-Gm-Message-State: ALoCoQmaN4RNTum8MqqlQUPTiO4xqND/52w++5E7/P1RIXkakvvC0EQE3tLlHgMGZS/DUdVQsFmI Cc: Paul Hoffman , json@ietf.org Subject: Re: [Json] Limitations on number size? X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 05 Jun 2013 16:06:21 -0000 --001a11c36c8c3a574004de6a5ffe Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable -1 Superfluous. The spec is perfectly clear on number representations. Once again, in scope for a best-practices doc. -T On Jun 5, 2013 8:52 AM, "Carsten Bormann" wrote: > On Jun 4, 2013, at 16:07, Paul Hoffman wrote: > > > And this is the point where one of the chairs says "please suggest > specific wording changes to RFC 4627". > > I like Tim's idea of a separate "best practices" document and look > forward to the process of creating it (Popcorn!). However, some > things need to be said in the specification. Here's my take: > > > Relationship between JSON and JavaScript > > As the name implies, JSON was defined using the literal notation the > JavaScript language uses for its data objects; some restrictions were > made to make it more robust to potential changes in the JavaScript > language. With that derivation made, JSON is now a specification > separate from JavaScript. > > Properties of JavaScript (and changes to the JavaScript specification > [ECMAscript]) do not automatically transfer to JSON. For example, > considerations about the source character set for JavaScript programs > do not influence what is admissible in a JSON document. Another > example is the number format: JSON can represent numbers in arbitrary > precision by just supplying the necessary number of decimal digits. > JavaScript uses a number model derived from IEEE 754 binary double > precision numbers; the precision and range it can represent natively > therefore is a subset of the precision and range possible in JSON. > > This clear separation of the two specifications does not mean that > users of JSON can always ignore JavaScript properties: A sizable part > of the JSON ecosystem is either using JavaScript implementations or > implementations that have been optimized for interaction with > JavaScript implementations. Depending on the area of application, a > JSON-based protocol may do well to consider JavaScript's specific > properties. Discussion of best practices for JSON-based protocols is > outside the scope of this specification. Here, we just want to point > out that, for example, exclusively using numbers natively > representable in JavaScript is not a requirement of the JSON format. > > Gr=C3=BC=C3=9Fe, Carsten > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > --001a11c36c8c3a574004de6a5ffe Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

-1

Superfluous. The spec is perfectly clear on number represent= ations.

Once again, in scope for a best-practices doc.
-T

On Jun 5, 2013 8:52 AM, "Carsten Bormann&qu= ot; <cabo@tzi.org> wrote:
On Jun 4, 2013, at 16:07, Paul Hoffman <paul.hoffman@vpnc.org> wrote:

> And this is the point where one of the chairs says "please sugges= t specific wording changes to RFC 4627".

I like Tim's idea of a separate "best practices" document and= look
forward to the process of creating it (Popcorn!). =C2=A0However, some
things need to be said in the specification. =C2=A0Here's my take:

<NEW>
Relationship between JSON and JavaScript

As the name implies, JSON was defined using the literal notation the
JavaScript language uses for its data objects; some restrictions were
made to make it more robust to potential changes in the JavaScript
language. =C2=A0With that derivation made, JSON is now a specification
separate from JavaScript.

Properties of JavaScript (and changes to the JavaScript specification
[ECMAscript]) do not automatically transfer to JSON. =C2=A0For example,
considerations about the source character set for JavaScript programs
do not influence what is admissible in a JSON document. =C2=A0Another
example is the number format: JSON can represent numbers in arbitrary
precision by just supplying the necessary number of decimal digits.
JavaScript uses a number model derived from IEEE 754 binary double
precision numbers; the precision and range it can represent natively
therefore is a subset of the precision and range possible in JSON.

This clear separation of the two specifications does not mean that
users of JSON can always ignore JavaScript properties: A sizable part
of the JSON ecosystem is either using JavaScript implementations or
implementations that have been optimized for interaction with
JavaScript implementations. =C2=A0Depending on the area of application, a JSON-based protocol may do well to consider JavaScript's specific
properties. =C2=A0Discussion of best practices for JSON-based protocols is<= br> outside the scope of this specification. =C2=A0Here, we just want to point<= br> out that, for example, exclusively using numbers natively
representable in JavaScript is not a requirement of the JSON format.

Gr=C3=BC=C3=9Fe, Carsten

_______________________________________________
json mailing list
json@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/json
--001a11c36c8c3a574004de6a5ffe-- From cabo@tzi.org Wed Jun 5 09:08:58 2013 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 D573521F9ADD for ; Wed, 5 Jun 2013 09:08:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BTxPzRYQ4QVq for ; Wed, 5 Jun 2013 09:08:52 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 2E23121F9AF5 for ; Wed, 5 Jun 2013 09:08:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r55G8jMu003032; Wed, 5 Jun 2013 18:08:45 +0200 (CEST) Received: from [127.0.0.1] (zoo.informatik.uni-bremen.de [134.102.218.16]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 7A1BD37A2; Wed, 5 Jun 2013 18:08:45 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: Date: Wed, 5 Jun 2013 18:08:43 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <0E0BC725-03F6-429C-9309-CB315C3AC1AF@tzi.org> References: <3B8F8F96-F7B6-4734-9553-087A993482A4@tzi.org> To: Tim Bray X-Mailer: Apple Mail (2.1503) Cc: Paul Hoffman , json@ietf.org Subject: Re: [Json] Limitations on number size? X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 05 Jun 2013 16:08:59 -0000 On Jun 5, 2013, at 18:05, Tim Bray wrote: > Superfluous. The spec is perfectly clear on number representations. This text is about number representations only on the surface (and that = part can be dialed down). It may be completely superfluous to you and me, but I have run into = enough people who simply don't know what is being said there and make = the wrong conclusions. Gr=FC=DFe, Carsten From jhildebr@cisco.com Wed Jun 5 09:16:18 2013 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 BC02B21F9B0F for ; Wed, 5 Jun 2013 09:16:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5HLb7SfAvQnn for ; Wed, 5 Jun 2013 09:16:03 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 339A921F98AC for ; Wed, 5 Jun 2013 09:16:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=813; q=dns/txt; s=iport; t=1370448963; x=1371658563; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=ryu7hMvHsMShYGCKB+g07Y8vMl03w1kIMExS3mfdB2Q=; b=fcVSLxLdEVEJoLtHIoXX8Yjq3X58eHTqT6s6zQR0BHY/p8m+5tIsF1Em KK0f2lUbKgrcfz43825ZyxbUf+2q5vfCcTaIGi91AvEMJ1ylEh8KjwXXf mmXHLqxXjGERgZNYVCUhQSJJvRMk8bnLEeg8Who3vKHJKr0ldYAoCkFSf A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ak0FAP1fr1GtJV2a/2dsb2JhbABZgwmDJbw3fRZ0giUBBDo/EgEIIhRCJQIEDgUIiAW9O456MQeCemEDqH+DD4In X-IronPort-AV: E=Sophos;i="4.87,807,1363132800"; d="scan'208";a="219166379" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-3.cisco.com with ESMTP; 05 Jun 2013 16:15:49 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r55GFmEp007232 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 5 Jun 2013 16:15:48 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.56]) by xhc-rcd-x04.cisco.com ([fe80::200:5efe:173.37.183.34%12]) with mapi id 14.02.0318.004; Wed, 5 Jun 2013 11:15:48 -0500 From: "Joe Hildebrand (jhildebr)" To: "Matt Miller (mamille2)" Thread-Topic: [Json] Proposed change: update the Unicode version Thread-Index: AQHOYUwcF9XONJEgqUaP+nfdT45kJZkmK8CA//+rbYCAAH8ngP//wLiAgABlQICAAAEIAIAABL+AgAAtMQCAAI08AA== Date: Wed, 5 Jun 2013 16:15:47 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [10.21.79.52] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Tim Bray , Paul Hoffman , Peter Saint-Andre , "json@ietf.org" Subject: Re: [Json] Proposed change: update the Unicode version X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 05 Jun 2013 16:16:19 -0000 +1 On 6/4/13 7:50 PM, "Matt Miller (mamille2)" wrote: >To gather this together, the proposed changes look to be: > >1) In 1. Introduction -- > >#### OLD TEXT: > >A string is a sequence of zero or more Unicode characters [UNICODE]. > >#### NEW TEXT: > >A string is a sequence of zero or more Unicode characters >defined in version 6.2 (or any subsequent version) of [UNICODE] > >#### > > >2) In 3. Encoding -- > >#### OLD TEXT: > >JSON text SHALL be encoded in Unicode. The default encoding is > UTF-8. > >#### NEW TEXT: > >JSON text takes the form of a Unicode string [UNICODE, section 2.7]; the >default encoding is UTF-8. > >#### > >Correct? > > >- m&m > >Matt Miller < mamille2@cisco.com > >Cisco Systems, Inc. > > --=20 Joe Hildebrand From cowan@ccil.org Wed Jun 5 09:22:52 2013 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 63CCD21F9B5E for ; Wed, 5 Jun 2013 09:22:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BU+Gz1NDFpYO for ; Wed, 5 Jun 2013 09:22:48 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id 06F0321F9BA6 for ; Wed, 5 Jun 2013 09:22:47 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1UkGU2-000548-B3 for json@ietf.org; Wed, 05 Jun 2013 12:22:46 -0400 Date: Wed, 5 Jun 2013 12:22:46 -0400 From: John Cowan To: json@ietf.org Message-ID: <20130605162246.GG3680@mercury.ccil.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Subject: [Json] Unpaired surrogates in JSON strings X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 05 Jun 2013 16:22:52 -0000 RFC 4627 Section 1 says: A string is a sequence of zero or more Unicode characters. However, the grammar of strings permits things like "foo\uDC00bar", which contains an escape sequence that does not correspond to any Unicode character. This provides backward compatibility with JavaScript, where a string is not a sequence of characters but a sequence of UTF-16 code units. If Section 1 is normative, then there is a contradiction with Section 4, which says: A JSON parser MUST accept all texts that conform to the JSON grammar. In my view, JSONbis processors should be REQUIRED to produce only strings that conform to Section 1. -- And it was said that ever after, if any John Cowan man looked in that Stone, unless he had a cowan@ccil.org great strength of will to turn it to other http://ccil.org/~cowan purpose, he saw only two aged hands withering in flame. --"The Pyre of Denethor" From tbray@textuality.com Wed Jun 5 09:26:52 2013 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 BA6AF21F9AEE for ; Wed, 5 Jun 2013 09:26:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.81 X-Spam-Level: X-Spam-Status: No, score=-1.81 tagged_above=-999 required=5 tests=[AWL=1.167, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BUeTRkWx+oyD for ; Wed, 5 Jun 2013 09:26:46 -0700 (PDT) Received: from mail-lb0-f175.google.com (mail-lb0-f175.google.com [209.85.217.175]) by ietfa.amsl.com (Postfix) with ESMTP id 85A0221F9B14 for ; Wed, 5 Jun 2013 09:26:46 -0700 (PDT) Received: by mail-lb0-f175.google.com with SMTP id v10so2119441lbd.34 for ; Wed, 05 Jun 2013 09:26:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=DZ/hmDPBMmBUlKPJNQuUWsalPn83zz//P4M079nu8Ds=; b=Fn1SJmrNz29uM0FGHhwATq0vtiUeZBiTe8ZHGlEemSK1G6OUEjG6vaXEw7+UD6UdNw zXipwL6jYaOIr4KexsZ3bTLSdcGVPRld6MRwAzbqBXN05HCPLtSnfdh/j1P8fhQSlRz7 tsznTsky56o7EtBZhXS+ZLzG97/ITuL0Gb706JtcRZZR7jlJiVElkEQQPbV23wcLv6n3 qjTgN/pYa7dmsLa/G1SHor8a4iSVMaau4vfLtm8e8IT747WcFi+u8S557iKbcItUWl9P ed60/YReu/u/PVnDeNw5z7HxcigkWu5EuEYDYtIJE7gDdp8kJroP/yipZY2EyeZDCMF7 1yzw== MIME-Version: 1.0 X-Received: by 10.112.131.226 with SMTP id op2mr7016140lbb.62.1370449605206; Wed, 05 Jun 2013 09:26:45 -0700 (PDT) Received: by 10.114.83.232 with HTTP; Wed, 5 Jun 2013 09:26:45 -0700 (PDT) X-Originating-IP: [24.84.235.32] In-Reply-To: References: <51AE6E95.3050007@stpeter.im> <51AE736D.7030209@stpeter.im> Date: Wed, 5 Jun 2013 09:26:45 -0700 Message-ID: From: Tim Bray To: "Matt Miller (mamille2)" Content-Type: multipart/alternative; boundary=047d7b3a8110e6ba3204de6aa9b3 X-Gm-Message-State: ALoCoQnhNRGFVy0QQTqUwRtSEGKxlqr6tKZgLKPQJqK1pxQZaR6BKjdfQsM9LgDX7txWPxiKNzVw Cc: Peter Saint-Andre , Paul Hoffman , "Joe Hildebrand \(jhildebr\)" , "json@ietf.org" Subject: Re: [Json] Proposed change: update the Unicode version X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 05 Jun 2013 16:26:52 -0000 --047d7b3a8110e6ba3204de6aa9b3 Content-Type: text/plain; charset=UTF-8 Looks good to me. -T On Tue, Jun 4, 2013 at 6:50 PM, Matt Miller (mamille2) wrote: > To gather this together, the proposed changes look to be: > > 1) In 1. Introduction -- > > #### OLD TEXT: > > A string is a sequence of zero or more Unicode characters [UNICODE]. > > #### NEW TEXT: > > A string is a sequence of zero or more Unicode characters > defined in version 6.2 (or any subsequent version) of [UNICODE] > > #### > > > 2) In 3. Encoding -- > > #### OLD TEXT: > > JSON text SHALL be encoded in Unicode. The default encoding is > UTF-8. > > #### NEW TEXT: > > JSON text takes the form of a Unicode string [UNICODE, section 2.7]; the > default encoding is UTF-8. > > #### > > Correct? > > > - m&m > > Matt Miller < mamille2@cisco.com > > Cisco Systems, Inc. > > --047d7b3a8110e6ba3204de6aa9b3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Looks good to me. -T
<= br>
On Tue, Jun 4, 2013 at 6:50 PM, Matt Mill= er (mamille2) <mamille2@cisco.com> wrote:
To gather this together, the proposed change= s look to be:

1) In 1. Introduction --

#### OLD TEXT:

A string is a sequence of zero or more Unicode characters [UNICODE].

#### NEW TEXT:

A string is a sequence of zero or more Unicode characters
defined in version 6.2 (or any subsequent version) of [UNICODE]

####


2) In 3. Encoding --

#### OLD TEXT:

JSON text SHALL be encoded in Unicode. =C2=A0The default encoding is
=C2=A0 UTF-8.

#### NEW TEXT:

JSON text takes the form of a Unicode string [UNICODE, section 2.7]; the default encoding is UTF-8.

####

Correct?


- m&m

Matt Miller < mamille2@cisco.com >
Cisco Systems, Inc.


--047d7b3a8110e6ba3204de6aa9b3-- From nico@cryptonector.com Wed Jun 5 09:44:06 2013 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 36A0321F9BF0 for ; Wed, 5 Jun 2013 09:44:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.877 X-Spam-Level: X-Spam-Status: No, score=-1.877 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 87PQynLUYp9s for ; Wed, 5 Jun 2013 09:44:01 -0700 (PDT) Received: from homiemail-a25.g.dreamhost.com (mailbigip.dreamhost.com [208.97.132.5]) by ietfa.amsl.com (Postfix) with ESMTP id 4CACC21F9BD2 for ; Wed, 5 Jun 2013 09:44:01 -0700 (PDT) Received: from homiemail-a25.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a25.g.dreamhost.com (Postfix) with ESMTP id EFA136781C8 for ; Wed, 5 Jun 2013 09:43:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=FoT+EBfTqPnZeV9ZbgJ1 J9YeWPM=; b=EPHmA2REcPVSlf7BOR3JJgeFL+B5hsaiqOnIaR/+ABpSGojDAncH aPDHGOFNjyHIdRJDPjse8bDgwexe2ZqR43VulLwTeeh3WLmnaB8Drokwompecxhw GEOpMUWV5X3BtDSu2jfYImWItUQue0qk8rsldEf8HLFHKT/qVuelhzU= Received: from mail-wi0-f181.google.com (mail-wi0-f181.google.com [209.85.212.181]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a25.g.dreamhost.com (Postfix) with ESMTPSA id 8F3BB6780BE for ; Wed, 5 Jun 2013 08:50:43 -0700 (PDT) Received: by mail-wi0-f181.google.com with SMTP id hi5so1429311wib.8 for ; Wed, 05 Jun 2013 08:50:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=4ZpVs4I9mH7OB2K8Hdhlax4FDOldDCbuGfLVJuVvqSQ=; b=OLtLJ0gJuoFSTm5onnM7ajkQkRJMbzHDeEAOp/s7hJYCEoXFmWuTWXoOQhx6oyWrV3 a7izTzVsNcLEtN0jctpEzwi+2hw0KdyFydQcWrpx2SoTq0XoAjZU98MWLO1XtuS3bQ4U p4VwWAzk2A6VYpZsWFR6OojwS9Y3WUQwKhRFOyt5WvS81WmNO3/0CYbkr37NTi+Bgath EK2nDlcL/x0uDrOQ6C35xs1Cq8y+1ZnTI/c3dmDUjPyTgGMgi6+qMTkRfo+b4GFFHQXM oGhHmMmrg5/nG7Bgg0dIxhv87t3VYmrTghQ6fi0Bcrg1a/+2gVXkUt/Mbm1HfegQQx7W Nmgw== MIME-Version: 1.0 X-Received: by 10.180.90.70 with SMTP id bu6mr7223845wib.34.1370447442248; Wed, 05 Jun 2013 08:50:42 -0700 (PDT) Received: by 10.216.63.136 with HTTP; Wed, 5 Jun 2013 08:50:42 -0700 (PDT) In-Reply-To: References: Date: Wed, 5 Jun 2013 10:50:42 -0500 Message-ID: From: Nico Williams To: Paul Hoffman Content-Type: text/plain; charset=UTF-8 Cc: "json@ietf.org" Subject: Re: [Json] Proposed change to the title of the spec X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 05 Jun 2013 16:44:06 -0000 On Wed, Jun 5, 2013 at 10:41 AM, Paul Hoffman wrote: > > > Current title: > The application/json Media Type for JavaScript Object Notation (JSON) > Proposed title: > JavaScript Object Notation (JSON) +1 From cabo@tzi.org Wed Jun 5 09:51:43 2013 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 3F71A21F9C01 for ; Wed, 5 Jun 2013 09:51:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OJojimuMhfHn for ; Wed, 5 Jun 2013 09:51:37 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 272C821F9BFF for ; Wed, 5 Jun 2013 09:51:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r55GpWuo017831; Wed, 5 Jun 2013 18:51:32 +0200 (CEST) Received: from [127.0.0.1] (zoo.informatik.uni-bremen.de [134.102.218.16]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 6959B37D5; Wed, 5 Jun 2013 18:51:32 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Content-Type: text/plain; charset=windows-1252 From: Carsten Bormann In-Reply-To: Date: Wed, 5 Jun 2013 18:51:24 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <5DC8FE77-10A8-4835-8415-ACC3FC323663@tzi.org> References: <51AE6E95.3050007@stpeter.im> <51AE736D.7030209@stpeter.im> To: "Matt Miller (mamille2)" X-Mailer: Apple Mail (2.1503) Cc: json@ietf.org Subject: Re: [Json] Proposed change: update the Unicode version X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 05 Jun 2013 16:51:43 -0000 On Jun 5, 2013, at 03:50, "Matt Miller (mamille2)" = wrote: > JSON text takes the form of a Unicode string [UNICODE, section 2.7]; = the > default encoding is UTF-8. It would help me if you could briefly explain what the reference to 2.7 = specifically adds here. (To me that is a bit confusing, as 2.7 is about internal programming = language representation, not about representation for interchange. But = maybe I just don't understand.) Gr=FC=DFe, Carsten From tbray@textuality.com Wed Jun 5 09:53:20 2013 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 50CB921F9C12 for ; Wed, 5 Jun 2013 09:53:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.226 X-Spam-Level: X-Spam-Status: No, score=-0.226 tagged_above=-999 required=5 tests=[AWL=-1.583, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CEc8lUT+uV6s for ; Wed, 5 Jun 2013 09:53:14 -0700 (PDT) Received: from mail-la0-x22c.google.com (mail-la0-x22c.google.com [IPv6:2a00:1450:4010:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 0A42121F9C0B for ; Wed, 5 Jun 2013 09:53:10 -0700 (PDT) Received: by mail-la0-f44.google.com with SMTP id er20so1673600lab.17 for ; Wed, 05 Jun 2013 09:53:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=rE6lbnSXUsmY7wZxx3BlBAuc1ap7grgYlpf27RhKT6k=; b=WXxW99JcVmYDYCzUza9kt/Ei2uvvVXNTGhEu6k01Kjp9yuFvjLXJifBdZ5Ic02mVnU 1VxWBSSsE0PRniM1FtUTrJ/48nQ3Bo4N8ymHVr8H5NcXZQM4AucSvJX+p14SxOJyWGZI aJEpBSdO6LthiCoGfsk5DnUi1fzytBppAfKH+llIFC5qXLexjRwHojMEV4O30zq/eQVJ xaM/vOV3tAEaZMqni8C85DdTHL7SFN7MYWW+oojMxiltWk9+ZiwFqA1qv8wGTZ46f79c hzsLmYYjQ7P/oxFZdeynESi8eLZSiVWRMVOnjh10ETOVb4e91b4k++5F53J5rHsfLV5q U+wQ== MIME-Version: 1.0 X-Received: by 10.112.72.132 with SMTP id d4mr15706783lbv.79.1370451189562; Wed, 05 Jun 2013 09:53:09 -0700 (PDT) Received: by 10.114.83.232 with HTTP; Wed, 5 Jun 2013 09:53:09 -0700 (PDT) X-Originating-IP: [24.84.235.32] In-Reply-To: References: Date: Wed, 5 Jun 2013 09:53:09 -0700 Message-ID: From: Tim Bray To: Nico Williams Content-Type: multipart/alternative; boundary=001a11c23f64561c2204de6b089f X-Gm-Message-State: ALoCoQnCIkE3+sc3mZX9GR9hX5+G4EQpEE1hx2ehVlGw7uvK0e2N2lQ9pdpxduEcnRdvrBfFhwVr Cc: Paul Hoffman , "json@ietf.org" Subject: Re: [Json] Proposed change to the title of the spec X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 05 Jun 2013 16:53:20 -0000 --001a11c23f64561c2204de6b089f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I=E2=80=99m +0 on this but think it would be just wonderful to take JavaScr= ipt out of the name. New title: =E2=80=9CThe JSON Format for Encoding Data=E2=80= =9D. Who said JSON had to stand for anything? -T On Wed, Jun 5, 2013 at 8:50 AM, Nico Williams wrote= : > On Wed, Jun 5, 2013 at 10:41 AM, Paul Hoffman > wrote: > > > > > > Current title: > > The application/json Media Type for JavaScript Object Notation (JSON= ) > > Proposed title: > > JavaScript Object Notation (JSON) > > +1 > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > --001a11c23f64561c2204de6b089f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I=E2=80=99m +0 on this but think it would be just wonderfu= l to take JavaScript out of the name.=C2=A0 New title: =E2=80=9CThe JSON Fo= rmat for Encoding Data=E2=80=9D. Who said JSON had to stand for anything?= =C2=A0 -T


On Wed, Jun 5, 2013 at 8:50 AM, Nico Wil= liams <nico@cryptonector.com> wrote:
On Wed, Jun 5, 2013 at 10:41 AM, Paul Hoffman <paul.hoffman@vpnc.org> wrote:
> <no hat>
>
> Current title:
> =C2=A0 =C2=A0The application/json Media Type for JavaScript Object Not= ation (JSON)
> Proposed title:
> =C2=A0 =C2=A0JavaScript Object Notation (JSON)

+1
_______________________________________________
json mailing list
json@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/json

--001a11c23f64561c2204de6b089f-- From cowan@ccil.org Wed Jun 5 09:55:40 2013 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 C52EA21F9BD3 for ; Wed, 5 Jun 2013 09:55:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WkFiCE2P1vW1 for ; Wed, 5 Jun 2013 09:55:36 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id 4E58421F9AFE for ; Wed, 5 Jun 2013 09:55:36 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1UkGzm-0008JJ-5o; Wed, 05 Jun 2013 12:55:34 -0400 Date: Wed, 5 Jun 2013 12:55:34 -0400 From: John Cowan To: Carsten Bormann Message-ID: <20130605165534.GI3680@mercury.ccil.org> References: <51AE6E95.3050007@stpeter.im> <51AE736D.7030209@stpeter.im> <5DC8FE77-10A8-4835-8415-ACC3FC323663@tzi.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5DC8FE77-10A8-4835-8415-ACC3FC323663@tzi.org> User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Cc: json@ietf.org, "Matt Miller \(mamille2\)" Subject: Re: [Json] Proposed change: update the Unicode version X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 05 Jun 2013 16:55:40 -0000 Carsten Bormann scripsit: > It would help me if you could briefly explain what the reference to > 2.7 specifically adds here. (To me that is a bit confusing, as 2.7 > is about internal programming language representation, not about > representation for interchange. But maybe I just don't understand.) +1 I also do not understand why JSON strings can't contain characters that are unassigned as yet. Checking this restriction is onerous if you don't have 6.2 or later Unicode tables, or even if you do. -- John Cowan cowan@ccil.org http://ccil.org/~cowan If I have not seen as far as others, it is because giants were standing on my shoulders. --Hal Abelson From tbray@textuality.com Wed Jun 5 09:56:57 2013 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 D160B21F9C0D for ; Wed, 5 Jun 2013 09:56:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.865 X-Spam-Level: X-Spam-Status: No, score=-1.865 tagged_above=-999 required=5 tests=[AWL=1.111, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mKYgV6fo7bQU for ; Wed, 5 Jun 2013 09:56:52 -0700 (PDT) Received: from mail-lb0-f180.google.com (mail-lb0-f180.google.com [209.85.217.180]) by ietfa.amsl.com (Postfix) with ESMTP id 261BE21F9BD3 for ; Wed, 5 Jun 2013 09:56:51 -0700 (PDT) Received: by mail-lb0-f180.google.com with SMTP id r10so2149544lbi.11 for ; Wed, 05 Jun 2013 09:56:51 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=sGHmxtUoiDDRvwwqbuQ9b3PPUNplHybwjXXfc7pzzYo=; b=DKZ2KU6AoCpTGQRPCvRPtbiDv3VoHk9gZGu715dmmGW2EmG4qexU5N3ELdY9jEIY8R 6VIyUMilzm45f+JJcWY6jtlledi4GUhU5to4ufdUReOe/9d+0bwXF5GgtoQPC5AClrNX 9ZQxbXoyOMF+iRE71J5Vv0uAfHFccx/bIZ/XfWVlFF64LyKbhkqUzqgwiOG+eZtyDQsD xC+QZ5bxumY05A9iHxDffe6fUqXSGsjkpBdcREi2+K9GS8kT065IsDEV24yaZhg1GCu4 OORLzQx0uZFzRnTLVrIaRQAOok4wY2fQZejrHYqhB35FZN0Bl2tnH6byYaXVywdoJ2AI E4fA== MIME-Version: 1.0 X-Received: by 10.152.29.41 with SMTP id g9mr2220423lah.44.1370451410982; Wed, 05 Jun 2013 09:56:50 -0700 (PDT) Received: by 10.114.83.232 with HTTP; Wed, 5 Jun 2013 09:56:50 -0700 (PDT) X-Originating-IP: [24.84.235.32] In-Reply-To: <5DC8FE77-10A8-4835-8415-ACC3FC323663@tzi.org> References: <51AE6E95.3050007@stpeter.im> <51AE736D.7030209@stpeter.im> <5DC8FE77-10A8-4835-8415-ACC3FC323663@tzi.org> Date: Wed, 5 Jun 2013 09:56:50 -0700 Message-ID: From: Tim Bray To: Carsten Bormann Content-Type: multipart/alternative; boundary=089e0158c09a88ac4a04de6b155d X-Gm-Message-State: ALoCoQklSYhP5iy3kuNAONqrd2g60SE7J1b12Dc8dnEsP75E0y3ySxdXJOzgk1jskUAKh7D0oP3h Cc: "json@ietf.org" , "Matt Miller \(mamille2\)" Subject: Re: [Json] Proposed change: update the Unicode version X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 05 Jun 2013 16:56:57 -0000 --089e0158c09a88ac4a04de6b155d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Jun 5, 2013 at 9:51 AM, Carsten Bormann wrote: > > It would help me if you could briefly explain what the reference to 2.7 > specifically adds here. > (To me that is a bit confusing, as 2.7 is about internal programming > language representation, not about representation for interchange. But > maybe I just don't understand.) > Hm? The first paragraph says =E2=80=9CA Unicode string data type is simply = an ordered sequence of code units. Thus a Unicode 8-bit string is an ordered sequence of 8-bit code units, a Unicode 16-bit string is an ordered sequence of 16-bit code units, and a Unicode 32-bit string is an ordered sequence of 32-bit code units.=E2=80=9D > > Gr=C3=BC=C3=9Fe, Carsten > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > --089e0158c09a88ac4a04de6b155d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Jun 5, 2013 at 9:51 AM, Carsten Bormann <cabo@tzi.org= > wrote:

It would help me if you could briefly explain what the reference to 2= .7 specifically adds here.
(To me that is a bit confusing, as 2.7 is about internal programming langua= ge representation, not about representation for interchange. =C2=A0But mayb= e I just don't understand.)

Hm? The= first paragraph says =E2=80=9CA Unicode string data type is simply an orde= red sequence of code units. Thus a Unicode 8-bit string is an ordered seque= nce of 8-bit code units, a Unicode 16-bit string is an ordered sequence of = 16-bit code units, and a Unicode 32-bit string is an=C2=A0 ordered sequence= of 32-bit code units.=E2=80=9D

=C2=A0

_______________________________________________
json mailing list
json@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/json

--089e0158c09a88ac4a04de6b155d-- From jsontest@yahoo.com Wed Jun 5 09:59:05 2013 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 4B0D421F9C2E for ; Wed, 5 Jun 2013 09:59:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.202 X-Spam-Level: X-Spam-Status: No, score=-1.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f7K-2lTw0Ayr for ; Wed, 5 Jun 2013 09:59:00 -0700 (PDT) Received: from nm18-vm0.bullet.mail.bf1.yahoo.com (nm18-vm0.bullet.mail.bf1.yahoo.com [98.139.213.138]) by ietfa.amsl.com (Postfix) with ESMTP id 65BFD21F9C2F for ; Wed, 5 Jun 2013 09:58:59 -0700 (PDT) Received: from [98.139.215.141] by nm18.bullet.mail.bf1.yahoo.com with NNFMP; 05 Jun 2013 16:58:52 -0000 Received: from [98.139.211.203] by tm12.bullet.mail.bf1.yahoo.com with NNFMP; 05 Jun 2013 16:58:52 -0000 Received: from [127.0.0.1] by smtp212.mail.bf1.yahoo.com with NNFMP; 05 Jun 2013 16:58:52 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1370451532; bh=RaT9/mhCyyWMKP1cEhysUKHeLOY9+FcOzYAiMhq/W64=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:References:In-Reply-To:Mime-Version:Content-Type:Content-Transfer-Encoding:Message-Id:Cc:X-Mailer:From:Subject:Date:To; b=rd1Kvi3DQhdg1Uc9kqEEsdESF+kFYNqgpv1jXuoJgL2nO5RFaVqEbaSm+LkpxvJiXTkZE+EvtErsW37D+nVaKBNd6TquShPWcJbZjAhtvBTIoNnx6dAcU8b8laq6KhgjMzYVVNHIhrMjHkVqCEHr7MiZ45yaGM6dD8LZUGDAIfA= X-Yahoo-Newman-Id: 660724.53871.bm@smtp212.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: QWKX1zYVM1lEulZQQIzxk_TegnF9X_sQi_9yH8HKJjlK9_. jxDZ55qT8Ye5.dooYfVEo.V2eoqAOqIRBz55fTxPlvnsg6KBQTlJelwnsOn5 ru6majRXXHQJF7Tw14vNBBxcE2eKh3nIUGn5zD.lj213E9OxEoO2P8HDKLPY oMQJhMinJ_UgnP3fnin_65_eRR5iLLOhaPtCIIWH_QUUkV0JSkq8oZLZ1xaQ scRmbR8jUXpLJY0JJtDsopNcXmtOvcuForBnw0FxcDMjXyWwhad97AdxpRwf J2dTKr9u4x2U_ARMOa4ailmZreus1RrxPVF_TRVt1QPRiC8NWUMbVmZl4wA7 cr8P4vWDETzoeDxmL.Rked9qXbls9QpbrIraLLoaPNAIFgREWdvBt78fuPVD 172Du.gm2vDx9HuixLiTLiJ5v7BssmALX3PFeKHlOMMmhcmxd6_yhPfGcFUY 9SaUmCVK_MXS_JAX1n2MyKAY- X-Yahoo-SMTP: indQcmSswBC8IKsm6t4aCAPskK3T X-Rocket-Received: from [192.168.0.102] (jsontest@76.29.100.42 with ) by smtp212.mail.bf1.yahoo.com with SMTP; 05 Jun 2013 09:58:52 -0700 PDT References: In-Reply-To: Mime-Version: 1.0 (1.0) Content-Type: multipart/alternative; boundary=Apple-Mail-2B7F5686-7902-4D57-9EC4-A77C0B15DB94 Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: iPod Mail (9B206) From: Vinny A Date: Wed, 5 Jun 2013 11:58:49 -0500 To: Tim Bray Cc: Nico Williams , Paul Hoffman , "json@ietf.org" Subject: Re: [Json] Proposed change to the title of the spec X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 05 Jun 2013 16:59:05 -0000 --Apple-Mail-2B7F5686-7902-4D57-9EC4-A77C0B15DB94 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 When I think of "encoding", I think of UTF-8 or similar. How about "transfer= ring" or "containing" data? On Jun 5, 2013, at 11:53 AM, Tim Bray wrote: > I=E2=80=99m +0 on this but think it would be just wonderful to take JavaSc= ript out of the name. New title: =E2=80=9CThe JSON Format for Encoding Data= =E2=80=9D. Who said JSON had to stand for anything? -T >=20 >=20 > On Wed, Jun 5, 2013 at 8:50 AM, Nico Williams wrot= e: > On Wed, Jun 5, 2013 at 10:41 AM, Paul Hoffman wrot= e: > > > > > > Current title: > > The application/json Media Type for JavaScript Object Notation (JSON)= > > Proposed title: > > JavaScript Object Notation (JSON) >=20 > +1 > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json >=20 > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json --Apple-Mail-2B7F5686-7902-4D57-9EC4-A77C0B15DB94 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
When I think of "enco= ding", I think of UTF-8 or similar. How about "transferring" or "containing"= data?




On Jun 5, 2013, at 11= :53 AM, Tim Bray <tbray@textualit= y.com> wrote:

=
I=E2=80=99m +0 on this but think it would be just wonderful= to take JavaScript out of the name.  New title: =E2=80=9CThe JSON Form= at for Encoding Data=E2=80=9D. Who said JSON had to stand for anything? = ; -T


On Wed, Jun 5, 2013 at 8:50 AM, Nico Will= iams <nico@cryptonector.com> wrote:
On Wed, Jun 5, 2013 at 10:41 AM, Paul Hoffman <paul.hoffman@vpnc.org> wrote:
> <no hat>
>
> Current title:
>    The application/json Media Type for JavaScript Object Nota= tion (JSON)
> Proposed title:
>    JavaScript Object Notation (JSON)

+1
_______________________________________________
json mailing list
json@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/json

____________________= ___________________________
json mailing list
json@ietf.org
https://www.ietf.org/mailman= /listinfo/json
= --Apple-Mail-2B7F5686-7902-4D57-9EC4-A77C0B15DB94-- From cowan@ccil.org Wed Jun 5 10:00:42 2013 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 DC78821F9A19 for ; Wed, 5 Jun 2013 10:00:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1o1dkpEJTW9B for ; Wed, 5 Jun 2013 10:00:36 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id 2BFBD21F99A8 for ; Wed, 5 Jun 2013 10:00:31 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1UkH4X-0000JD-Aq; Wed, 05 Jun 2013 13:00:29 -0400 Date: Wed, 5 Jun 2013 13:00:29 -0400 From: John Cowan To: Tim Bray Message-ID: <20130605170028.GJ3680@mercury.ccil.org> References: <51AE6E95.3050007@stpeter.im> <51AE736D.7030209@stpeter.im> <5DC8FE77-10A8-4835-8415-ACC3FC323663@tzi.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Cc: Carsten Bormann , "Matt Miller \(mamille2\)" , "json@ietf.org" Subject: Re: [Json] Proposed change: update the Unicode version X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 05 Jun 2013 17:00:43 -0000 Tim Bray scripsit: > Hm? The first paragraph says “A Unicode string data type is simply an > ordered sequence of code units. Thus a Unicode 8-bit string is an ordered > sequence of 8-bit code units, a Unicode 16-bit string is an ordered > sequence of 16-bit code units, and a Unicode 32-bit string is an ordered > sequence of 32-bit code units.†Yes, but is that what you actually want? If so, you probably want the "sequence of 16-bit code units" language. This matches JavaScript and at least some implementations of JSON. However, I want a JSON string to be an ordered sequence of codepoints/ characters, not of code units. -- Only do what only you can do. John Cowan --Edsger W. Dijkstra's advice to a student in search of a thesis From stefan@drees.name Wed Jun 5 10:04:47 2013 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 B81A421F9C4C for ; Wed, 5 Jun 2013 10:04:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T6tCD6tKvgsL for ; Wed, 5 Jun 2013 10:04:42 -0700 (PDT) Received: from mout.web.de (mout.web.de [212.227.17.12]) by ietfa.amsl.com (Postfix) with ESMTP id 9E1F521F9C36 for ; Wed, 5 Jun 2013 10:04:41 -0700 (PDT) Received: from newyork.local.box ([93.129.94.83]) by smtp.web.de (mrweb102) with ESMTPSA (Nemesis) id 0MKrPw-1UkH8Q3i9w-0006QL; Wed, 05 Jun 2013 19:04:32 +0200 Message-ID: <51AF6F9D.6090600@drees.name> Date: Wed, 05 Jun 2013 19:04:29 +0200 From: Stefan Drees User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Tim Bray References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Provags-ID: V02:K0:J0fYxjjEEvA3eLq331fSWAPHlJpBu0pMkuw1bb5Dd58 tJ1DrbdJwp11QoTm936l8dANeTdpb8aEBJokM0Iyqtn5iewd31 DEDWZB7LSuYQZJBq1ufoFaQqWVLoy7g/SgBfOjUJmfN1Ep8/iY 9u+16MAYl+oBLa32LFxTw7hstoGcg0PjceA3JHdYDKlB2reRmH Ur9yPa1Lus+qMUEew+bGQ== Cc: Nico Williams , Paul Hoffman , "json@ietf.org" Subject: Re: [Json] Proposed change to the title of the spec X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stefan@drees.name List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2013 17:04:48 -0000 On 05.06.13 18:53, Tim Bray wrote: > On Wed, Jun 5, 2013 at 8:50 AM, Nico Williams ... wrote: >> On Wed, Jun 5, 2013 at 10:41 AM, Paul Hoffman ... wrote: >>> >>> >>> Current title: >>> The application/json Media Type for JavaScript Object Notation(JSON) >>> Proposed title: >>> JavaScript Object Notation (JSON) >> >> +1 > > I’m +0 on this but think it would be just wonderful to take JavaScript > out of the name. New title: “The JSON Format for Encoding Data”. Who > said JSON had to stand for anything? -T Yes, please set the title to "The JSON Format for Encoding Data" if changing it, so that the focus shift of the last ten years of usage in the wild is better represented. I hope the term "Encoding" used within is common language enough to not trigger extended bikeshedding ;-) Stefan. From peter.h.m.brooks@gmail.com Wed Jun 5 09:55:45 2013 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 BABA121F9C1D for ; Wed, 5 Jun 2013 09:55:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yTElO8o4foF1 for ; Wed, 5 Jun 2013 09:55:45 -0700 (PDT) Received: from mail-qa0-x231.google.com (mail-qa0-x231.google.com [IPv6:2607:f8b0:400d:c00::231]) by ietfa.amsl.com (Postfix) with ESMTP id 27BA621F9AFE for ; Wed, 5 Jun 2013 09:55:45 -0700 (PDT) Received: by mail-qa0-f49.google.com with SMTP id hu16so639204qab.8 for ; Wed, 05 Jun 2013 09:55:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=RtbHbAdUvbXeWYXdZDKIF32MWDA7qASujpjjI+Hd6yQ=; b=tfgJofoH2dZiipP2unm+tw1QsUGPPjR0Q5zxYJn5mIK0m9CMLw1zDSWqkJpcrVGcfM ZavEiJf1nzcO7FauNCG334jLNNvU/IedNcf1bcL5/LEywjKTL0ZE3Mu3PaOaCiQZOJiu RL/0ssJSZfWmYfEHXZY8S6pE3BH10GYcInzL2Fdweosk+FroJnw07Z2RfNC/R/hntClP sHGTid1ttZ7yBtQiqAB0IottsWwNRS5sCPj0TUJU9ZNEqsjMYXKXnclWEsvVYnnXdJke pVPw1nEFJfptiyHxwmL7kdGDBxyN0rZdKYKwpLhw9ftq+tpVPqoDOeifsVUTSKLuQQnk caVw== X-Received: by 10.49.75.73 with SMTP id a9mr34754029qew.30.1370451344617; Wed, 05 Jun 2013 09:55:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.118.68 with HTTP; Wed, 5 Jun 2013 09:55:04 -0700 (PDT) In-Reply-To: References: From: Peter Brooks Date: Wed, 5 Jun 2013 18:55:04 +0200 Message-ID: To: Tim Bray Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Nico Williams , Paul Hoffman , "json@ietf.org" Subject: Re: [Json] Proposed change to the title of the spec X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 05 Jun 2013 17:09:21 -0000 On 5 June 2013 18:53, Tim Bray wrote: > I=E2=80=99m +0 on this but think it would be just wonderful to take JavaS= cript out > of the name. New title: =E2=80=9CThe JSON Format for Encoding Data=E2=80= =9D. Who said JSON > had to stand for anything? -T > +1 From paul.hoffman@vpnc.org Wed Jun 5 10:24:49 2013 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 B82B721F9B5D for ; Wed, 5 Jun 2013 10:24:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WwOksn49OrWn for ; Wed, 5 Jun 2013 10:24:48 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 42B9E21F9B8B for ; Wed, 5 Jun 2013 10:24:42 -0700 (PDT) Received: from [10.20.30.90] (50-0-66-165.dsl.dynamic.sonic.net [50.0.66.165]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r55HOcWB088625 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 5 Jun 2013 10:24:39 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Paul Hoffman In-Reply-To: Date: Wed, 5 Jun 2013 10:24:38 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <2E4FA3BE-6429-4DEA-A203-4E5438CBFAA2@vpnc.org> References: To: "json@ietf.org" X-Mailer: Apple Mail (2.1508) Subject: Re: [Json] Proposed change to the title of the spec X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 05 Jun 2013 17:24:49 -0000 On Jun 5, 2013, at 9:53 AM, Tim Bray wrote: > I=92m +0 on this but think it would be just wonderful to take = JavaScript out of the name. New title: =93The JSON Format for Encoding = Data=94. Who said JSON had to stand for anything? -T This works for me, better than my original proposal. --Paul Hoffman= From cabo@tzi.org Wed Jun 5 10:43:20 2013 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 5EEAD21F9BA6 for ; Wed, 5 Jun 2013 10:43:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9GIuo9INchoy for ; Wed, 5 Jun 2013 10:43:10 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id DECB921F92F5 for ; Wed, 5 Jun 2013 10:43:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r55Hh1Mo015392; Wed, 5 Jun 2013 19:43:01 +0200 (CEST) Received: from [127.0.0.1] (zoo.informatik.uni-bremen.de [134.102.218.16]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id E43783813; Wed, 5 Jun 2013 19:43:00 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Content-Type: text/plain; charset=windows-1252 From: Carsten Bormann In-Reply-To: Date: Wed, 5 Jun 2013 19:42:59 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <8CBDD3A1-CEFA-44E6-BA1B-85E8050ECB2C@tzi.org> References: To: Tim Bray X-Mailer: Apple Mail (2.1503) Cc: json@ietf.org Subject: Re: [Json] Proposed change to the title of the spec X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 05 Jun 2013 17:43:20 -0000 On Jun 5, 2013, at 18:53, Tim Bray wrote: > I=92m +0 on this but think it would be just wonderful to take = JavaScript out of the name. =20 +1 > New title: =93The JSON Format for Encoding Data=94. Who said JSON had = to stand for anything? -T Let's not forget to write the RFC editor note explaining why they = shouldn't put back an expansion of the abbreviation... Gr=FC=DFe, Carsten PS.; s/"Encoding"/"Representing"/, but that is too far in bikeshed = territory. From douglas@crockford.com Wed Jun 5 10:47:31 2013 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 1E84421F9A1A for ; Wed, 5 Jun 2013 10:47:31 -0700 (PDT) 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=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 79W8ndDD2tCB for ; Wed, 5 Jun 2013 10:47:25 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id 219F521F96FB for ; Wed, 5 Jun 2013 10:47:24 -0700 (PDT) Received: from [192.168.114.223] ([216.113.168.135]) by mrelay.perfora.net (node=mrus4) with ESMTP (Nemesis) id 0Mg3NV-1V4pLo1rld-00O6RN; Wed, 05 Jun 2013 13:46:59 -0400 Message-ID: <51AF7988.6040009@crockford.com> Date: Wed, 05 Jun 2013 10:46:48 -0700 From: Douglas Crockford User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: John Cowan References: <20130605162246.GG3680@mercury.ccil.org> In-Reply-To: <20130605162246.GG3680@mercury.ccil.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V02:K0:hNvpMRr1S7DN3fCyP6XIop7M/DZehk4zY2uZYLa6wjq mb/wbl3XkQyrDGDpoev3iPjTrvPcvRex9c0cm57uYaIAj/+/aB +X/dl8R1F205y5vJhsG2sTOZQkgfaxW8ypt3hp/oRLLkyxSr/j ST+xlG7bZzxZ4bnCduZ0czuSdJJSvznDihja44P5pOO26WXFwa jOrfEOqgghIcQrUds5n4kTlGjsA8EWMsVglSudEurR5zChemA/ h1PMvKbmJanRsK3uGYDKv4ZWfFy85LIqR6aGwAEMUtF82FrvZg 97wfbEME1U2bV7cZGlOkBMVp9DtMEGCGHIVBuPMBT+IDhcsoyk 0MLbOfFKO/yGJ+8hIthD/SXx3LfNIP9YTredrEu0+ Cc: json@ietf.org Subject: Re: [Json] Unpaired surrogates in JSON strings X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 05 Jun 2013 17:47:31 -0000 On 6/5/2013 9:22 AM, John Cowan wrote: > RFC 4627 Section 1 says: > > A string is a sequence of zero or more Unicode characters. > > However, the grammar of strings permits things like "foo\uDC00bar", > which contains an escape sequence that does not correspond to any > Unicode character. This provides backward compatibility with JavaScript, > where a string is not a sequence of characters but a sequence of UTF-16 > code units. > > If Section 1 is normative, then there is a contradiction with Section 4, > which says: > > A JSON parser MUST accept all texts that conform to the JSON > grammar. > > In my view, JSONbis processors should be REQUIRED to produce only strings > that conform to Section 1. > Such a requirement will be breaking. Breaking changes are out of scope. I like the suggestion that section 1 should be talking about code points instead of characters. From nico@cryptonector.com Wed Jun 5 10:53:53 2013 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 24D8221F9B32 for ; Wed, 5 Jun 2013 10:53:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.847 X-Spam-Level: X-Spam-Status: No, score=-1.847 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nyl5skQBEaAX for ; Wed, 5 Jun 2013 10:53:43 -0700 (PDT) Received: from hapkido.dreamhost.com (hapkido.dreamhost.com [66.33.216.122]) by ietfa.amsl.com (Postfix) with ESMTP id B6BA921F9B82 for ; Wed, 5 Jun 2013 10:53:43 -0700 (PDT) Received: from homiemail-a89.g.dreamhost.com (caiajhbdccah.dreamhost.com [208.97.132.207]) by hapkido.dreamhost.com (Postfix) with ESMTP id 8798738518 for ; Wed, 5 Jun 2013 10:53:43 -0700 (PDT) Received: from mail-we0-f178.google.com (mail-we0-f178.google.com [74.125.82.178]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a89.g.dreamhost.com (Postfix) with ESMTPSA id 5913F3180A3 for ; Wed, 5 Jun 2013 09:20:07 -0700 (PDT) Received: by mail-we0-f178.google.com with SMTP id u53so1481840wes.37 for ; Wed, 05 Jun 2013 09:20:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=bvYXLEHF4JbufwGYRGai8msnaJrCCQ2FLO+cN0NISNA=; b=p2mi0uQyduhznLmZCn4GPmrfpyWJudsdKKe/6r7JFGRu6kqAPDC6iuKhZcNsWVAkRt lK29M+cHwxfXaMQu7xJmOrY4ZTMeOPycTVl4xmHIZQnooYqfar5XnfL/1Uz5Gv8AI5nA USiElhfj7CFDjlwT46JGZlxlgu/vi2b1iyk3tUTFfwIl/LoiDGseo6DwoWp3lQpvYRj6 /+WqdVZn/Y2b5cu/4fVJoROk91l4aELtBkK/wBZeLgDgZ5goU7u8lTeumkO54mNhRy/T ar5Cvuaej14zBcZv6siuRKJfLzm8mt5jxDt7OHmJrCz/BjKoeXeMuyZS4WS9yY8n+aXl MHow== MIME-Version: 1.0 X-Received: by 10.180.185.244 with SMTP id ff20mr7564599wic.0.1370449204121; Wed, 05 Jun 2013 09:20:04 -0700 (PDT) Received: by 10.216.63.136 with HTTP; Wed, 5 Jun 2013 09:20:04 -0700 (PDT) In-Reply-To: <0E0BC725-03F6-429C-9309-CB315C3AC1AF@tzi.org> References: <3B8F8F96-F7B6-4734-9553-087A993482A4@tzi.org> <0E0BC725-03F6-429C-9309-CB315C3AC1AF@tzi.org> Date: Wed, 5 Jun 2013 11:20:04 -0500 Message-ID: From: Nico Williams To: Carsten Bormann Content-Type: text/plain; charset=UTF-8 Cc: Tim Bray , Paul Hoffman , json@ietf.org Subject: Re: [Json] Limitations on number size? X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 05 Jun 2013 17:53:53 -0000 On Wed, Jun 5, 2013 at 11:08 AM, Carsten Bormann wrote: > On Jun 5, 2013, at 18:05, Tim Bray wrote: > >> Superfluous. The spec is perfectly clear on number representations. > > This text is about number representations only on the surface (and that part can be dialed down). > > It may be completely superfluous to you and me, but I have run into enough people who simply don't know what is being said there and make the wrong conclusions. The only thing RFC4627 says about this is that "[a]n implementation may set limits on the range of numbers." That is very clear, on the one hand, but it's been missed (as I described earlier, where an implementor told a contributor that JSON supports only IEEE 754 64-bit numbers). It's easy to miss because anyone who knows JavaScript knows JSON, right? So a section with a provocative title calling out differences between JS and JSON would probably help at least those who would read the RFC. From cabo@tzi.org Wed Jun 5 10:54:14 2013 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 58F7E21F9BCB for ; Wed, 5 Jun 2013 10:54:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id osE+kA-QskAY for ; Wed, 5 Jun 2013 10:54:00 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 1F49821F9BB6 for ; Wed, 5 Jun 2013 10:53:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r55HroBK003684; Wed, 5 Jun 2013 19:53:50 +0200 (CEST) Received: from [127.0.0.1] (zoo.informatik.uni-bremen.de [134.102.218.16]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id E7818381E; Wed, 5 Jun 2013 19:53:49 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: Date: Wed, 5 Jun 2013 19:53:42 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <3B8F8F96-F7B6-4734-9553-087A993482A4@tzi.org> <0E0BC725-03F6-429C-9309-CB315C3AC1AF@tzi.org> To: Nico Williams X-Mailer: Apple Mail (2.1503) Cc: Tim Bray , Paul Hoffman , json@ietf.org Subject: Re: [Json] Limitations on number size? X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 05 Jun 2013 17:54:15 -0000 On Jun 5, 2013, at 18:20, Nico Williams wrote: > provocative title calling out > differences between JS and JSON Yes. The more important statement of direction to be made very very = explicit is that the (pretty much arrested) protocol evolution of JSON = and the (now accelerating) language evolution of JavaScript/ECMAscript = are decoupled, so people stop thinking that every new ES version changes = JSON. Gr=FC=DFe, Carsten From douglas@crockford.com Wed Jun 5 10:54:26 2013 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 DC35121F9B82 for ; Wed, 5 Jun 2013 10:54:25 -0700 (PDT) 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=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ATK-y6h02S47 for ; Wed, 5 Jun 2013 10:54:19 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id C28D721F9BCB for ; Wed, 5 Jun 2013 10:54:19 -0700 (PDT) Received: from [192.168.114.223] ([216.113.168.135]) by mrelay.perfora.net (node=mrus3) with ESMTP (Nemesis) id 0Le5rg-1U3TOC2Z5A-00qiSO; Wed, 05 Jun 2013 13:54:17 -0400 Message-ID: <51AF7B3B.4030108@crockford.com> Date: Wed, 05 Jun 2013 10:54:03 -0700 From: Douglas Crockford User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Tim Bray References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Provags-ID: V02:K0:67AFcBHRqX7TDluNHtdrRq0uAH0tizq1liN3cJhAVXV byqRxY13qvx/963PaE/c15MyGTTtlhPBwKVxAUZeAJYZPYalUa yuyq1QCRxkgpzoJ6CTkLLNUhO/LX87ezNhtLoiemCY9ADxkO3q eC1HssOj4JyqUMj1AfzMbzZHiQ1urgX7Wc/GtrmJWcG9mdt3k8 t/PLSP+dtJGRv0QgMGuN1n+wOMgmOXvgj/1LGK4IifbJGSYun4 tdZlzBWIkS1t5J5168JOkQfjIEnrJa9MbgbRnJSQhbJEEzQP5q grAK2tY+PkwaXj/Onkh8NlIFr4Y0uBOUUMD3FETSILyJKrZYPA 7gQFL+RaWNer57YnIU1Snjak66Ld2RZPs3DEjHYHR Cc: Nico Williams , Paul Hoffman , "json@ietf.org" Subject: Re: [Json] Proposed change to the title of the spec X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 05 Jun 2013 17:54:26 -0000 On 6/5/2013 9:53 AM, Tim Bray wrote: > I’m +0 on this but think it would be just wonderful to take JavaScript > out of the name. New title: “The JSON Format for Encoding Data”. Who > said JSON had to stand for anything? -T > I like this. There is no need to put JavaScript in the title. I think the title should be The JSON Data Interchange Format. From mamille2@cisco.com Wed Jun 5 10:55:42 2013 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 4E1AD21F96C2 for ; Wed, 5 Jun 2013 10:55:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.276 X-Spam-Level: X-Spam-Status: No, score=-10.276 tagged_above=-999 required=5 tests=[AWL=0.323, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aFccfygtRWCn for ; Wed, 5 Jun 2013 10:55:29 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 570D721F8B21 for ; Wed, 5 Jun 2013 10:55:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7300; q=dns/txt; s=iport; t=1370454925; x=1371664525; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=2vEAsoHFp3ayWBj4HlF7rhfRWRkF02a4eTbwUSAF9XQ=; b=JA99owNJV72zCvJNw80AA1XHS2iB+wGwBEIFBWWOsehr1OjqqggFMhyl hthUbO6Tgr5YdMMrVVQE2Mro2V9YisgSDxTGA1qFUXKRXt6xheIXkF95Z Es5QNuFJ3bie0oV+wOyoq1zVWqxDz7aKCZGt9MA15o2scBE+kQoJSpO9h g=; X-Files: smime.p7s : 4136 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhkFAGd6r1GtJXG9/2dsb2JhbABZgwm/XX4WdIIjAQEBAwF5BQsCAQgiJAIwJQIEDgUIBod5Br1YjnoxB4J6YQOQAIEsl1ODD4In X-IronPort-AV: E=Sophos;i="4.87,808,1363132800"; d="p7s'?scan'208";a="219203764" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-8.cisco.com with ESMTP; 05 Jun 2013 17:55:24 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r55HtOqB010424 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 5 Jun 2013 17:55:24 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.24]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.02.0318.004; Wed, 5 Jun 2013 12:55:24 -0500 From: "Matt Miller (mamille2)" To: John Cowan Thread-Topic: [Json] Proposed change: update the Unicode version Thread-Index: AQHOYUwcEVXhzbeP6EGj0XkggNKAG5kmK8CAgAAQAwCAABqRgIAAJU4AgAAAqoCAAAEIAIAABL+AgAAtMICAAPvJAIAAAYUAgAABBYCAAA9XgA== Date: Wed, 5 Jun 2013 17:55:23 +0000 Message-ID: References: <51AE6E95.3050007@stpeter.im> <51AE736D.7030209@stpeter.im> <5DC8FE77-10A8-4835-8415-ACC3FC323663@tzi.org> <20130605170028.GJ3680@mercury.ccil.org> In-Reply-To: <20130605170028.GJ3680@mercury.ccil.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.129.24.59] Content-Type: multipart/signed; boundary="Apple-Mail=_D255A269-FBDD-4F9A-B82E-71D9803DAFA0"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Cc: Carsten Bormann , Tim Bray , "json@ietf.org" Subject: Re: [Json] Proposed change: update the Unicode version X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 05 Jun 2013 17:55:42 -0000 --Apple-Mail=_D255A269-FBDD-4F9A-B82E-71D9803DAFA0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Jun 5, 2013, at 11:00 AM, John Cowan wrote: > Tim Bray scripsit: >=20 >> Hm? The first paragraph says =93A Unicode string data type is simply = an >> ordered sequence of code units. Thus a Unicode 8-bit string is an = ordered >> sequence of 8-bit code units, a Unicode 16-bit string is an ordered >> sequence of 16-bit code units, and a Unicode 32-bit string is an = ordered >> sequence of 32-bit code units.=94 >=20 > Yes, but is that what you actually want? If so, you probably want the > "sequence of 16-bit code units" language. This matches JavaScript and > at least some implementations of JSON. >=20 > However, I want a JSON string to be an ordered sequence of codepoints/ > characters, not of code units. /me doffs hat When it's actually inside the JavaScript interpreter, a "sequence of = 16-bit code units" is most likely correct. Over the wire or on the = filesystem, that isn't necessarily true; often, it is a "sequence of = 8-bit code units". I think here we need to concentrate on what's over the wire/on the = filesystem, not what's in the interpreter/processor/etc. - m&m Matt Miller < mamille2@cisco.com > Cisco Systems, Inc. --Apple-Mail=_D255A269-FBDD-4F9A-B82E-71D9803DAFA0 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMezCCBjQw ggQcoAMCAQICAR4wDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDE1NVoX DTE3MTAyNDIxMDE1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMcJg8zOLdgasSmkLhOrlr6KMoOMpohBllVHrdRvEg/q6r8jR+EK 75xCGhR8ToREoqe7zM9/UnC6TS2y9UKTpT1v7RSMzR0t6ndl0TWBuUr/UXBhPk+Kmy7bI4yW4urC +y7P3/1/X7U8ocb8VpH/Clt+4iq7nirMcNh6qJR+xjOhV+VHzQMALuGYn5KZmc1NbJQYclsGkDxD z2UbFqE2+6vIZoL+jb9x4Pa5gNf1TwSDkOkikZB1xtB4ZqtXThaABSONdfmv/Z1pua3FYxnCFmdr /+N2JLKutIxMYqQOJebr/f/h5t95m4JgrM3Y/w7YX9d7YAL9jvN4SydHsU6n65cCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRTcu2SnODaywFc fH6WNU7y1LhRgjAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBAAqDCH14qywG XLhjjF6uHLkjd02hcdh9hrw+VUsv+q1eeQWB21jWj3kJ96AUlPCoEGZ/ynJNScWy6QMVQjbbMXlt UfO4n4bGGdKo3awPWp61tjAFgraLJgDk+DsSvUD6EowjMTNx25GQgyYJ5RPIzKKR9tQW8gGK+2+R HxkUCTbYFnL6kl8Ch507rUdPPipJ9CgJFws3kDS3gOS5WFMxcjO5DwKfKSETEPrHh7p5shuuNktv sv6hxHTLhiMKX893gxdT3XLS9OKmCv87vkINQcNEcIIoFWbP9HORz9v3vQwR4e3ksLc2JZOAFK+s sS5XMEoznzpihEP0PLc4dCBYjbvSD7kxgDwZ+Aj8Q9PkbvE9sIPP7ON0fz095HdThKjiVJe6vofq +n6b1NBc8XdrQvBmunwxD5nvtTW4vtN6VY7mUCmxsCieuoBJ9OlqmsVWQvifIYf40dJPZkk9YgGT zWLpXDSfLSplbY2LL9C9U0ptvjcDjefLTvqSFc7tw1sEhF0n/qpA2r0GpvkLRDmcSwVyPvmjFBGq Up/pNy8ZuPGQmHwFi2/14+xeSUDG2bwnsYJQG2EdJCB6luQ57GEnTA/yKZSTKI8dDQa8Sd3zfXb1 9mOgSF0bBdXbuKhEpuP9wirslFe6fQ1t5j5R0xi72MZ8ikMu1RQZKCyDbMwazlHiMIIGPzCCBSeg AwIBAgIDBoRIMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcN MTMwNDMwMjE1NDQyWhcNMTQwNTAyMDUzOTA0WjBbMRkwFwYDVQQNExBiN2F6NndOY0t0R3JtMEpF MRswGQYDVQQDDBJtYW1pbGxlMkBjaXNjby5jb20xITAfBgkqhkiG9w0BCQEWEm1hbWlsbGUyQGNp c2NvLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJbKBMsG+9UFTx9uq/bhhXgu vJvO8z7cwKaqqwZhVf5z/kHFyCNijtmTOE+YXjA8mWR4aoBwB5SvGypI/cJUofJ+AlBTC4g+RMx/ K0Ab4/jQqTQz9CDzMOB+Wm+rt8ZJ7A8ZzOJmNDAsf/VvB8l2A1SQz1UsAixgH16NTr8SlblAXEKk 4hwpCudUiNjjQokqJ0H686UBKVorcZSgXaza8XMqGtJF/8mNhR9GQYi7Xht1ky+9LFOrto2daZto KJRwMeVusVdHUeKEQSu7jztw8HchH3KEb7Q+r5X+hhDZoddfKE8d5eyPuhiZdrzv7OlNZ0fSLdx7 3AE3nx9/R5YlXucCAwEAAaOCAtgwggLUMAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQW MBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQUxGd+/qrdVudHrIKkw5xOMY7eaLUwHwYD VR0jBBgwFoAUU3Ltkpzg2ssBXHx+ljVO8tS4UYIwHQYDVR0RBBYwFIESbWFtaWxsZTJAY2lzY28u Y29tMIIBTAYDVR0gBIIBQzCCAT8wggE7BgsrBgEEAYG1NwECAzCCASowLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0 Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBp c3N1ZWQgYWNjb3JkaW5nIHRvIHRoZSBDbGFzcyAxIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9m IHRoZSBTdGFydENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBw dXJwb3NlIGluIGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMDYG A1UdHwQvMC0wK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUxLWNybC5jcmwwgY4G CCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIv Y2xhc3MxL2NsaWVudC9jYTBCBggrBgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2Vy dHMvc3ViLmNsYXNzMS5jbGllbnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRz c2wuY29tLzANBgkqhkiG9w0BAQUFAAOCAQEAlDhXbGEI7lbqUcu5r2JHZaMsbRZda/99ZqODzWGX 0llou9jGccsAWDPPwRRe2+ROpXfH4cuJZElTcLDeZSp/qpXKhjYieFSX8+Ml9sKEj5UOSqQLyoLk PtrIJV12Jk3nuG2Jc0UeEnGwK/aqtzy7+bfEVI0ziyVM2gChHh0RH74KyiwYWknbOTRIkZcz/ulE DVFQp63uj6wfmDNvAUHBAdhKVqA1S/rfP1KcDZpf1NfvwXJibiqTRA6K1EOxTJOP41n/XdvHqHXL RWL2xrOUI9/URANr/ok3OrsuZEMFnAAGefS1bWS/hFtUGVkHGiKEBbyDW7da2ULXbuC7umrQnzGC A28wggNrAgEBMIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkG A1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwaESDAJBgUrDgMCGgUA oIIBrzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMzA2MDUxNzU1 MjNaMCMGCSqGSIb3DQEJBDEWBBS/foKbw/VufY64g/dllq0QCrrlFDCBpQYJKwYBBAGCNxAEMYGX MIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3Mg MSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwaESDCBpwYLKoZIhvcNAQkQAgsxgZeg gZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1 cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAx IFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDBoRIMA0GCSqGSIb3DQEBAQUABIIBAHmF Blt4iAmr2lZ4i/1WHLs44BZLDf/He5kU9jjCSxg+KsWJDVI9/U9GUFGY58vGm2lf2pUG6Rd8ftPp NQF9yDkVLt2ED7qjolcbZLeYQgrx1XrnmqAssLV+DKtneDnU+3JYOn+BUQLxFPXCMyWsxdXi4Vjf ys86eHHPm9y/V/VpuTsRswLzflBm++OOsPsbyj/AM0CEX1q7Powl3T7wSRXrC6LvTgbLX6rPDJTT ppHYNVKA8XZUSGPwSJBG56PClhGeqw+29vX5CvhtTKPIn4ikJQHED/Fe4Ylu01PImN+uUmrQTeTa tGBocl+QYBhIqYCCQT741cqOYCgSakmzWfgAAAAAAAA= --Apple-Mail=_D255A269-FBDD-4F9A-B82E-71D9803DAFA0-- From douglas@crockford.com Wed Jun 5 10:59:02 2013 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 52C7C21F9050 for ; Wed, 5 Jun 2013 10:59:02 -0700 (PDT) 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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5uPLp8-AzMVg for ; Wed, 5 Jun 2013 10:58:56 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id DDCE921F965B for ; Wed, 5 Jun 2013 10:58:55 -0700 (PDT) Received: from [192.168.114.223] ([216.113.168.135]) by mrelay.perfora.net (node=mrus0) with ESMTP (Nemesis) id 0MOxrj-1UmkHp0Bzb-006Rz4; Wed, 05 Jun 2013 13:58:55 -0400 Message-ID: <51AF7C55.3070606@crockford.com> Date: Wed, 05 Jun 2013 10:58:45 -0700 From: Douglas Crockford User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "json@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V02:K0:5+KJqPR03djCqy24Ow1i0016nFYz1GVrlOPo0IVqd9L qYWTfPUaT1tpaX+Kc28AdK69cqrirzIV4TrrWWRD4fPaoVOV9j keU3scDB+hIRYCsyKStvH1ZiGcTLCCetJzXcszwpTK+oOMG7mq ag6jvdO+7hlOt3zzGYU7W6zlRScBIQXAY9htc7+8Y708X+pU9w OeEauSKNuF4HLI5fFVCOF0+qtntSkm61XwK5Mq00GyEbrjJodV ADDuH00PVKvF+zJqJhc4CA4Ytm8Bm4mhVVl16coobGdoV/VPm+ 9Nrpex2hkB+GdsWPBT3S/ehvlcZfR6nhWPJenFjM4secglhlnh qVRjzlWzUI3JbrmHKXN8qxpOkiW47Rgf08GoQXr8A Subject: [Json] Security Considerations X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 05 Jun 2013 17:59:02 -0000 The section on security considerations is completely inadequate. It is describing a use of JavaScript eval that is now considered to be a very bad practice, and it provides no advice for other languages. It should instead be advising care when constructing JSON texts, insisting on proper encoding practices and avoidance of concatenation. From mamille2@cisco.com Wed Jun 5 10:59:40 2013 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 4D84521F9A24 for ; Wed, 5 Jun 2013 10:59:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.384 X-Spam-Level: X-Spam-Status: No, score=-10.384 tagged_above=-999 required=5 tests=[AWL=0.215, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5FWDZ7Q5iVzx for ; Wed, 5 Jun 2013 10:59:34 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 414B521F99C1 for ; Wed, 5 Jun 2013 10:59:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6695; q=dns/txt; s=iport; t=1370455174; x=1371664774; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=zoIx4hZDsCzRUDNF0pIQ/YExVd8jUz9IlI+qJm0q+yg=; b=f/FfaBNBhQcKn2cvxMdBd8QpRVrP154A6+ieeRALAfw/4tAskEahVEuE Ae1xtf+zcz975CBbFBnBi2Xf2rXltBQpciB5k/s/3dQPgG1FCsB/ZgPQp j1m4sItYG4U1RkdGJENkMEw6iaiVMT54KoCnzbLuc49AC7wowQFxRZKOl o=; X-Files: smime.p7s : 4136 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ak0FAIJ7r1GtJV2a/2dsb2JhbABZgwmDJbw6fhZ0giMBAQEDAXkFCwIBCBgKJAIwJQIEDgUIBod5Br1ZjnoxB4J6YQOQAIEsl1ODD4In X-IronPort-AV: E=Sophos;i="4.87,808,1363132800"; d="p7s'?scan'208";a="219205725" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-8.cisco.com with ESMTP; 05 Jun 2013 17:59:20 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r55HxKNp011265 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 5 Jun 2013 17:59:20 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.24]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.02.0318.004; Wed, 5 Jun 2013 12:59:20 -0500 From: "Matt Miller (mamille2)" To: Douglas Crockford Thread-Topic: [Json] Proposed change to the title of the spec Thread-Index: AQHOYgMf16GOcvXSAEaZnjzUTzvlPJknmKkAgAARcoCAABEEgIAAAXmA Date: Wed, 5 Jun 2013 17:59:20 +0000 Message-ID: References: <51AF7B3B.4030108@crockford.com> In-Reply-To: <51AF7B3B.4030108@crockford.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.129.24.59] Content-Type: multipart/signed; boundary="Apple-Mail=_FED293B7-044E-487A-A510-A59726AA41AB"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Cc: Nico Williams , Tim Bray , Paul Hoffman , "json@ietf.org" Subject: Re: [Json] Proposed change to the title of the spec X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 05 Jun 2013 17:59:40 -0000 --Apple-Mail=_FED293B7-044E-487A-A510-A59726AA41AB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Jun 5, 2013, at 11:54 AM, Douglas Crockford = wrote: > On 6/5/2013 9:53 AM, Tim Bray wrote: >> I=92m +0 on this but think it would be just wonderful to take = JavaScript out of the name. New title: =93The JSON Format for Encoding = Data=94. Who said JSON had to stand for anything? -T >>=20 > I like this. There is no need to put JavaScript in the title. I think = the title should be > The JSON Data Interchange Format. /me doffs hat Either works for me, and seems much better than the current title. - m&m Matt Miller < mamille2@cisco.com > Cisco Systems, Inc. --Apple-Mail=_FED293B7-044E-487A-A510-A59726AA41AB Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMezCCBjQw ggQcoAMCAQICAR4wDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDE1NVoX DTE3MTAyNDIxMDE1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMcJg8zOLdgasSmkLhOrlr6KMoOMpohBllVHrdRvEg/q6r8jR+EK 75xCGhR8ToREoqe7zM9/UnC6TS2y9UKTpT1v7RSMzR0t6ndl0TWBuUr/UXBhPk+Kmy7bI4yW4urC +y7P3/1/X7U8ocb8VpH/Clt+4iq7nirMcNh6qJR+xjOhV+VHzQMALuGYn5KZmc1NbJQYclsGkDxD z2UbFqE2+6vIZoL+jb9x4Pa5gNf1TwSDkOkikZB1xtB4ZqtXThaABSONdfmv/Z1pua3FYxnCFmdr /+N2JLKutIxMYqQOJebr/f/h5t95m4JgrM3Y/w7YX9d7YAL9jvN4SydHsU6n65cCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRTcu2SnODaywFc fH6WNU7y1LhRgjAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBAAqDCH14qywG XLhjjF6uHLkjd02hcdh9hrw+VUsv+q1eeQWB21jWj3kJ96AUlPCoEGZ/ynJNScWy6QMVQjbbMXlt UfO4n4bGGdKo3awPWp61tjAFgraLJgDk+DsSvUD6EowjMTNx25GQgyYJ5RPIzKKR9tQW8gGK+2+R HxkUCTbYFnL6kl8Ch507rUdPPipJ9CgJFws3kDS3gOS5WFMxcjO5DwKfKSETEPrHh7p5shuuNktv sv6hxHTLhiMKX893gxdT3XLS9OKmCv87vkINQcNEcIIoFWbP9HORz9v3vQwR4e3ksLc2JZOAFK+s sS5XMEoznzpihEP0PLc4dCBYjbvSD7kxgDwZ+Aj8Q9PkbvE9sIPP7ON0fz095HdThKjiVJe6vofq +n6b1NBc8XdrQvBmunwxD5nvtTW4vtN6VY7mUCmxsCieuoBJ9OlqmsVWQvifIYf40dJPZkk9YgGT zWLpXDSfLSplbY2LL9C9U0ptvjcDjefLTvqSFc7tw1sEhF0n/qpA2r0GpvkLRDmcSwVyPvmjFBGq Up/pNy8ZuPGQmHwFi2/14+xeSUDG2bwnsYJQG2EdJCB6luQ57GEnTA/yKZSTKI8dDQa8Sd3zfXb1 9mOgSF0bBdXbuKhEpuP9wirslFe6fQ1t5j5R0xi72MZ8ikMu1RQZKCyDbMwazlHiMIIGPzCCBSeg AwIBAgIDBoRIMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcN MTMwNDMwMjE1NDQyWhcNMTQwNTAyMDUzOTA0WjBbMRkwFwYDVQQNExBiN2F6NndOY0t0R3JtMEpF MRswGQYDVQQDDBJtYW1pbGxlMkBjaXNjby5jb20xITAfBgkqhkiG9w0BCQEWEm1hbWlsbGUyQGNp c2NvLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJbKBMsG+9UFTx9uq/bhhXgu vJvO8z7cwKaqqwZhVf5z/kHFyCNijtmTOE+YXjA8mWR4aoBwB5SvGypI/cJUofJ+AlBTC4g+RMx/ K0Ab4/jQqTQz9CDzMOB+Wm+rt8ZJ7A8ZzOJmNDAsf/VvB8l2A1SQz1UsAixgH16NTr8SlblAXEKk 4hwpCudUiNjjQokqJ0H686UBKVorcZSgXaza8XMqGtJF/8mNhR9GQYi7Xht1ky+9LFOrto2daZto KJRwMeVusVdHUeKEQSu7jztw8HchH3KEb7Q+r5X+hhDZoddfKE8d5eyPuhiZdrzv7OlNZ0fSLdx7 3AE3nx9/R5YlXucCAwEAAaOCAtgwggLUMAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQW MBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQUxGd+/qrdVudHrIKkw5xOMY7eaLUwHwYD VR0jBBgwFoAUU3Ltkpzg2ssBXHx+ljVO8tS4UYIwHQYDVR0RBBYwFIESbWFtaWxsZTJAY2lzY28u Y29tMIIBTAYDVR0gBIIBQzCCAT8wggE7BgsrBgEEAYG1NwECAzCCASowLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0 Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBp c3N1ZWQgYWNjb3JkaW5nIHRvIHRoZSBDbGFzcyAxIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9m IHRoZSBTdGFydENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBw dXJwb3NlIGluIGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMDYG A1UdHwQvMC0wK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUxLWNybC5jcmwwgY4G CCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIv Y2xhc3MxL2NsaWVudC9jYTBCBggrBgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2Vy dHMvc3ViLmNsYXNzMS5jbGllbnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRz c2wuY29tLzANBgkqhkiG9w0BAQUFAAOCAQEAlDhXbGEI7lbqUcu5r2JHZaMsbRZda/99ZqODzWGX 0llou9jGccsAWDPPwRRe2+ROpXfH4cuJZElTcLDeZSp/qpXKhjYieFSX8+Ml9sKEj5UOSqQLyoLk PtrIJV12Jk3nuG2Jc0UeEnGwK/aqtzy7+bfEVI0ziyVM2gChHh0RH74KyiwYWknbOTRIkZcz/ulE DVFQp63uj6wfmDNvAUHBAdhKVqA1S/rfP1KcDZpf1NfvwXJibiqTRA6K1EOxTJOP41n/XdvHqHXL RWL2xrOUI9/URANr/ok3OrsuZEMFnAAGefS1bWS/hFtUGVkHGiKEBbyDW7da2ULXbuC7umrQnzGC A28wggNrAgEBMIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkG A1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwaESDAJBgUrDgMCGgUA oIIBrzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMzA2MDUxNzU5 MjBaMCMGCSqGSIb3DQEJBDEWBBT3eVZn9TnrKNZv2fPbLO97usdaNzCBpQYJKwYBBAGCNxAEMYGX MIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3Mg MSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwaESDCBpwYLKoZIhvcNAQkQAgsxgZeg gZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1 cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAx IFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDBoRIMA0GCSqGSIb3DQEBAQUABIIBAJG1 1OF6cr83xVDKXzeMfAyhHzEwzY2HPUTSErF7SnSGtwNweJOMuJJ9vLg+6rP2ZdaAGtfUck6wLG2+ D59Gz8fYTRlwRTx+e0RJGZ3oNMEc5kZXLVuVn27ulOvNQ/21x+ZLaWy7n0A8Ki9CBnMeWEzwlPLi uKju1uviyYjI0BIEecpVUQdg6KFAcSgaJsWPbXy0eSr+nUnIB/Bq7nNf6u6a4vdBmqVtxSA3ZC4E kw/qf/lt4mEt2hCQXo1C22RD7PeHeANBrPcgYO5aMKHq16vvN3D15F2vK+EHFjDa/J8XxW1/Zalo Pb5YmMrjC5aFRMquJ87dQetAQeQjMmtbT+IAAAAAAAA= --Apple-Mail=_FED293B7-044E-487A-A510-A59726AA41AB-- From paul.hoffman@vpnc.org Wed Jun 5 11:01:46 2013 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 4D51221F9988 for ; Wed, 5 Jun 2013 11:01:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bQn20lLXd6I5 for ; Wed, 5 Jun 2013 11:01:45 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 2389921F9A15 for ; Wed, 5 Jun 2013 11:01:43 -0700 (PDT) Received: from [10.20.30.90] (50-0-66-165.dsl.dynamic.sonic.net [50.0.66.165]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r55I1g2L089755 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 5 Jun 2013 11:01:43 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Paul Hoffman In-Reply-To: <51AF7988.6040009@crockford.com> Date: Wed, 5 Jun 2013 11:01:41 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <61407E6F-4178-471A-931C-D98E6F0C9756@vpnc.org> References: <20130605162246.GG3680@mercury.ccil.org> <51AF7988.6040009@crockford.com> To: "json@ietf.org" X-Mailer: Apple Mail (2.1508) Subject: Re: [Json] Unpaired surrogates in JSON strings X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 05 Jun 2013 18:01:46 -0000 On Jun 5, 2013, at 10:46 AM, Douglas Crockford = wrote: > On 6/5/2013 9:22 AM, John Cowan wrote: >> RFC 4627 Section 1 says: >>=20 >> A string is a sequence of zero or more Unicode characters. >>=20 >> However, the grammar of strings permits things like "foo\uDC00bar", >> which contains an escape sequence that does not correspond to any >> Unicode character. This provides backward compatibility with = JavaScript, >> where a string is not a sequence of characters but a sequence of = UTF-16 >> code units. >>=20 >> If Section 1 is normative, then there is a contradiction with Section = 4, >> which says: >>=20 >> A JSON parser MUST accept all texts that conform to the JSON >> grammar. >>=20 >> In my view, JSONbis processors should be REQUIRED to produce only = strings >> that conform to Section 1. >>=20 > Such a requirement will be breaking. Breaking changes are out of = scope. How is that "breaking"? Section 1 has a definition of strings, and = Section 4 says that the parser must accept all texts that conform to the = grammar. Surrogate code points are not characters, according to the = Unicode spec. > I like the suggestion that section 1 should be talking about code = points instead of characters. That seems like a significant change that would cause parsers that = currently follow Section 1 to fail. --Paul Hoffman From cromis@gmail.com Wed Jun 5 10:52:29 2013 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 E8FF721F9BCA for ; Wed, 5 Jun 2013 10:52:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jez+Ynw1p0tu for ; Wed, 5 Jun 2013 10:52:28 -0700 (PDT) Received: from mail-qa0-x233.google.com (mail-qa0-x233.google.com [IPv6:2607:f8b0:400d:c00::233]) by ietfa.amsl.com (Postfix) with ESMTP id 4452D21F9B32 for ; Wed, 5 Jun 2013 10:52:21 -0700 (PDT) Received: by mail-qa0-f51.google.com with SMTP id i13so1332758qae.3 for ; Wed, 05 Jun 2013 10:52:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:content-type; bh=eY2wIq4NupbP/A1b9PK+KNieC85nVuWqUEId3YuqM68=; b=Y5d+909qBXEaY1HKn14p01fXMH158Cq1hRjHsPu5ni7byQj4OTRI947Hvp9Hk+SLql Bxx49MV/yJvLSiAw1Shlf7PwzKRtmNg7vyoxaF4PVczQ51it0kFmGQKApmQlop3leO9C VjqyHiXl4QPs24EtUlVRM6Y90xdE3tHq8ZVVh2rOHbWr4r8yCTkltwl9E/MUwmcebsDh 53fT8OelascF2GnjnaHO0Ez4I9I7zs+L4THFKHHHZ3kedJPbh2g+RkXzaZ0m9tGYqus+ wqU76TZMZL5GzWIxeH9PnxLUP5DzLWp3yI6BPPIHl7BEGlM1b/1iJSPD9ImYjNwKLCy0 Eehg== X-Received: by 10.229.204.4 with SMTP id fk4mr49162qcb.88.1370454738926; Wed, 05 Jun 2013 10:52:18 -0700 (PDT) MIME-Version: 1.0 Sender: cromis@gmail.com Received: by 10.49.106.228 with HTTP; Wed, 5 Jun 2013 10:51:58 -0700 (PDT) In-Reply-To: References: <51AE63B1.80800@crockford.com> From: Jacob Davies Date: Wed, 5 Jun 2013 10:51:58 -0700 X-Google-Sender-Auth: gM6bqGPy3HXdhPrFKl1IsQOoygw Message-ID: To: "json@ietf.org" Content-Type: multipart/alternative; boundary=001a11c29274e5358204de6bdbbd Subject: Re: [Json] Limitations on number size? X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 05 Jun 2013 18:06:39 -0000 --001a11c29274e5358204de6bdbbd Content-Type: text/plain; charset=ISO-8859-1 On Tue, Jun 4, 2013 at 9:05 PM, Nico Williams wrote: > It might be nice to be able to specify some ranges that MUST be > supported by decoders, but in practice I think we can't (and probably > shouldn't try to) even do that. > My past reading of the number section and the many references to Javascript in the spec led me to believe that the number type was Javascript's number type, and that compliance required you to accept & emit numbers only in that range (i.e. IEEE 754 64-bit numbers minus NaN and infinities). Implementation limits on the length of strings or size of arrays or objects were not specified either, but those are large enough in most languages that you're unlikely to run into them unexpectedly; if you are thinking of sending a terabyte of text in string or an object with a trillion keys it has probably occurred to you that some special interoperability concerns will apply. But just sending large 64-bit integers as numbers in a JSON string will cause you interoperability problems with Javascript and a lot of other JSON parsers, and my experience & some quick searches indicate this has been a common bug (or misunderstanding, perhaps) in implementations. I wouldn't say a size restriction should be specified either. But I think it might be worth noting this particular interoperability concern in the specification rather than just as a best practice. --001a11c29274e5358204de6bdbbd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, Jun 4, 2013 at 9:05 PM, Nico Williams <nico@c= ryptonector.com> wrote:
It m= ight be nice to be able to specify some ranges that MUST be
supported by decoders, but in practice I think we can't (and probably shouldn't try to) even do that.

My past reading of the number section and the many references to Javascr= ipt in the spec led me to believe that the number type was Javascript's= number type, and that compliance required you to accept & emit numbers= only in that range (i.e.=A0IEEE 754 64-bit numbers minus NaN and infinities).

=
Implementation lim= its on the length of strings or size of arrays or objects were not specifie= d either, but those are large enough in most languages that you're unli= kely to run into them unexpectedly; if you are thinking of sending a teraby= te of text in string or an object with a trillion keys it has probably occu= rred to you that some special interoperability concerns will apply. But jus= t sending large 64-bit integers as numbers in a JSON string will cause you = interoperability problems with Javascript and a lot of other JSON parsers, = and my experience & some quick searches indicate this has been a common= bug (or misunderstanding, perhaps) in implementations.

I wouldn't say a size restriction shoul= d be specified either. But I think it might be worth noting this particular= interoperability concern in the specification rather than just as a best p= ractice.
--001a11c29274e5358204de6bdbbd-- From gsalguei@cisco.com Wed Jun 5 11:06:46 2013 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 8877421F8930 for ; Wed, 5 Jun 2013 11:06:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fwgvar7PLNgh for ; Wed, 5 Jun 2013 11:06:39 -0700 (PDT) Received: from av-tac-rtp.cisco.com (av-tac-rtp.cisco.com [64.102.19.209]) by ietfa.amsl.com (Postfix) with ESMTP id A648421F896D for ; Wed, 5 Jun 2013 11:06:38 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from chook.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r55I6a4n025542 for ; Wed, 5 Jun 2013 14:06:36 -0400 (EDT) Received: from rtp-gsalguei-8912.cisco.com (rtp-gsalguei-8912.cisco.com [10.116.132.51]) by chook.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r55I6aiu022416; Wed, 5 Jun 2013 14:06:36 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Gonzalo Salgueiro In-Reply-To: <51AF7C55.3070606@crockford.com> Date: Wed, 5 Jun 2013 14:06:36 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <51AF7C55.3070606@crockford.com> To: Douglas Crockford X-Mailer: Apple Mail (2.1503) Cc: json@ietf.org Subject: Re: [Json] Security Considerations X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 05 Jun 2013 18:06:46 -0000 Completely agree. Needs some serious updating and would love to see it = be more JS agnostic. --G On Jun 5, 2013, at 1:58 PM, Douglas Crockford = wrote: > The section on security considerations is completely inadequate. It is = describing a use of JavaScript eval that is now considered to be a very = bad practice, and it provides no advice for other languages. >=20 > It should instead be advising care when constructing JSON texts, = insisting on proper encoding practices and avoidance of concatenation. > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json >=20 From tbray@textuality.com Wed Jun 5 11:12:53 2013 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 0957621F9931 for ; Wed, 5 Jun 2013 11:12:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.042 X-Spam-Level: X-Spam-Status: No, score=0.042 tagged_above=-999 required=5 tests=[AWL=-0.409, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_SORBS_DUL=0.877, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xPXtyvRqJ4L7 for ; Wed, 5 Jun 2013 11:12:48 -0700 (PDT) Received: from mail-ve0-x22e.google.com (mail-ve0-x22e.google.com [IPv6:2607:f8b0:400c:c01::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 41C7121F9B3A for ; Wed, 5 Jun 2013 11:12:33 -0700 (PDT) Received: by mail-ve0-f174.google.com with SMTP id oz10so1484627veb.5 for ; Wed, 05 Jun 2013 11:11:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=ubG/hNNxfg8kpc848l/mD2Z0MR3B1x+qYlpE3djdhjg=; b=Ecv4QDjsviTV6LxHZlKdIPt8GcGU/JaW/8N+Vwwxd1wiykhq2ZUYIw8eHKkfKbFIGC KbQFLgrTzjOHODLoayIQH23lVOU+y6nA1XthmGbIXU6O3DnEPCPYvfmFQgVKyNeIfSzA GlDx11v7lyT/W3DX1QykAmYLOgAhvpRhN3UY3PrYjCfP/5rN5YB9AsmzabPEU7jPvwlC ltgUT2BI2gMbqj40X9G8OkHflpAQd4R8zmZ152TJTtWpWFJe2ARkJltafPbaV09BVgrQ 8EBHIlIG4PLd38TPxJTtggm5KmlU8kk06ewo4gHCXpwe55+/0DRapQ/4gebZBXeTx1fE JMiQ== MIME-Version: 1.0 X-Received: by 10.220.193.202 with SMTP id dv10mr7164816vcb.24.1370455917743; Wed, 05 Jun 2013 11:11:57 -0700 (PDT) Received: by 10.220.48.14 with HTTP; Wed, 5 Jun 2013 11:11:57 -0700 (PDT) X-Originating-IP: [96.49.81.176] In-Reply-To: <51AF7B3B.4030108@crockford.com> References: <51AF7B3B.4030108@crockford.com> Date: Wed, 5 Jun 2013 11:11:57 -0700 Message-ID: From: Tim Bray To: Douglas Crockford Content-Type: multipart/alternative; boundary=047d7b673dba2866d704de6c221f X-Gm-Message-State: ALoCoQkB/N2MYtaFjg10kxiRusajSXObkjGdPg19VJ9ALoTK9v5l89klTQWjRLaRh6VRH+zZbhB+ Cc: Nico Williams , Paul Hoffman , "json@ietf.org" Subject: Re: [Json] Proposed change to the title of the spec X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 05 Jun 2013 18:12:53 -0000 --047d7b673dba2866d704de6c221f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable +1 On Wed, Jun 5, 2013 at 10:54 AM, Douglas Crockford w= rote: > On 6/5/2013 9:53 AM, Tim Bray wrote: > >> I=E2=80=99m +0 on this but think it would be just wonderful to take Java= Script >> out of the name. New title: =E2=80=9CThe JSON Format for Encoding Data= =E2=80=9D. Who said >> JSON had to stand for anything? -T >> >> I like this. There is no need to put JavaScript in the title. I think > the title should be > The JSON Data Interchange Format. > --047d7b673dba2866d704de6c221f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
+1


On Wed, Jun 5, 2013 at 10:54 AM, Douglas Crockford <d= ouglas@crockford.com> wrote:
On 6/5/2013 9:53 AM, Tim B= ray wrote:
I=E2=80=99m +0 on this but think it would be just wonderful to take JavaScr= ipt out of the name. New title: =E2=80=9CThe JSON Format for Encoding Data= =E2=80=9D. Who said JSON had to stand for anything? -T

I like this. There is no need to put JavaScript in the title. I think the t= itle should be
The JSON Data Interchange Format.

--047d7b673dba2866d704de6c221f-- From douglas@crockford.com Wed Jun 5 11:20:41 2013 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 952CA21F9B7D for ; Wed, 5 Jun 2013 11:20:41 -0700 (PDT) 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=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZZIItcQdHiKO for ; Wed, 5 Jun 2013 11:20:35 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id 67C4A21F9B2F for ; Wed, 5 Jun 2013 11:20:35 -0700 (PDT) Received: from [192.168.114.223] ([216.113.168.135]) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis) id 0MfWk7-1V3Mb32Xn9-00OrvL; Wed, 05 Jun 2013 14:20:04 -0400 Message-ID: <51AF8149.5090907@crockford.com> Date: Wed, 05 Jun 2013 11:19:53 -0700 From: Douglas Crockford User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Paul Hoffman References: <20130605162246.GG3680@mercury.ccil.org> <51AF7988.6040009@crockford.com> <61407E6F-4178-471A-931C-D98E6F0C9756@vpnc.org> In-Reply-To: <61407E6F-4178-471A-931C-D98E6F0C9756@vpnc.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V02:K0:DXY2xwjgGo5d9857EzFG+EdGBOHkxhaWfwSMiXHGCtT k1u/ny764HjsEc9Sq6aEDFCeYRytsGBskef0hCGBocIZBE1No2 IoZNVwcDEKrduZGk7GrzTvRTIYI18eiQldv5nrkENhWrFrvXvi MXJgSgsuBVdMzhzDgNEkAedZ1IDhXZKxjJrWBbmeSSSf4slylr zbD73VAyugYcWgxqL2Ss9hyK5YqhJ9hiN/vhyWN6UZTuiYZ1db lkajmmTpNR+9R09ymUd1D3MJBN5ASrpIHflOZxeF8NV2icxJJ2 jRhUjNOs9RWl1uhhypEosbCPErGXmEYdrshbp/Ja2cLezKGkGW XBOmp885mo9WrHm3xL4+l3VaCT+Eu5p+nNdokJYec Cc: "json@ietf.org" Subject: Re: [Json] Unpaired surrogates in JSON strings X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 05 Jun 2013 18:20:42 -0000 On 6/5/2013 11:01 AM, Paul Hoffman wrote: > > > On Jun 5, 2013, at 10:46 AM, Douglas Crockford wrote: > >> On 6/5/2013 9:22 AM, John Cowan wrote: >>> RFC 4627 Section 1 says: >>> >>> A string is a sequence of zero or more Unicode characters. >>> >>> However, the grammar of strings permits things like "foo\uDC00bar", >>> which contains an escape sequence that does not correspond to any >>> Unicode character. This provides backward compatibility with JavaScript, >>> where a string is not a sequence of characters but a sequence of UTF-16 >>> code units. >>> >>> If Section 1 is normative, then there is a contradiction with Section 4, >>> which says: >>> >>> A JSON parser MUST accept all texts that conform to the JSON >>> grammar. >>> >>> In my view, JSONbis processors should be REQUIRED to produce only strings >>> that conform to Section 1. >>> >> Such a requirement will be breaking. Breaking changes are out of scope. > How is that "breaking"? Section 1 has a definition of strings, and Section 4 says that the parser must accept all texts that conform to the grammar. Surrogate code points are not characters, according to the Unicode spec. > >> I like the suggestion that section 1 should be talking about code points instead of characters. > That seems like a significant change that would cause parsers that currently follow Section 1 to fail. > It is not a change, it is a clarification. JavaScript, Java, and many other languages have strings of code points, owing to their being set before Unicode grew surrogate pairs. So strings in those languages are composed of code points. JSON is tolerant of that reality. From douglas@crockford.com Wed Jun 5 11:35:22 2013 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 47E4F21F9843 for ; Wed, 5 Jun 2013 11:34:33 -0700 (PDT) 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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jtNkqgWimSfw for ; Wed, 5 Jun 2013 11:34:19 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id 8171D21F96FF for ; Wed, 5 Jun 2013 11:34:06 -0700 (PDT) Received: from [192.168.114.223] ([216.113.168.135]) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis) id 0MC3mC-1UbX6I3iIi-0095O2; Wed, 05 Jun 2013 14:33:40 -0400 Message-ID: <51AF8479.5080002@crockford.com> Date: Wed, 05 Jun 2013 11:33:29 -0700 From: Douglas Crockford User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "json@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V02:K0:NZgbpqJoJOaGpqYMjknol8VHyqppeMFGTTNr67mKDEW z8c26veSEFDvA7Iqc34i+tKBxuqNp+Ml8TT2L/i9ClHh8HF7FA 0MGOhLLccoQIji71nvNnfbbxf3qyYH+Uxb5dqhME86MBIg+ImT SHR+aAR9isodNC0wPdOohxkdG1waCztWdB3mbd9cO/M+9W2Qoa MnYF1i2M+jo+abZa3bq4uIrimeJYaeypgmEI9UiBCCiVoL1RF6 sJNdEbN9kNBW52n3UbF3Fg0F3rZg87orD3PZ5mqMTwULaEcZut /KEwWO0Ue9WtSfody7Lc0y1VFYgKX6El3RNe+v5xKUvxsLk+LK Q1WLk/ZIjR83KpzFAY9rRDphFv8pdipyHwwBGEl7A Subject: [Json] The names within an object SHOULD be unique. X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 05 Jun 2013 18:35:23 -0000 This was the biggest blunder in the RFC. SHOULD should have been MUST. It is, sadly, too late to repair this. Instead, we must specify what happens when you do the thing you SHOULD NOT do. We need to provide implementations some slack here because some implementations do the right thing and reject. Some implementations do the lazy thing and take that last use of the name. From douglas@crockford.com Wed Jun 5 11:37:58 2013 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 A0F7D21F9B5E for ; Wed, 5 Jun 2013 11:37:58 -0700 (PDT) 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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QN3WUQvuYlxZ for ; Wed, 5 Jun 2013 11:37:52 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id 99C1A21F9B3F for ; Wed, 5 Jun 2013 11:37:52 -0700 (PDT) Received: from [192.168.114.223] ([216.113.168.135]) by mrelay.perfora.net (node=mrus2) with ESMTP (Nemesis) id 0MOfLq-1Un40W1zPS-00692y; Wed, 05 Jun 2013 14:37:51 -0400 Message-ID: <51AF8575.5060706@crockford.com> Date: Wed, 05 Jun 2013 11:37:41 -0700 From: Douglas Crockford User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "json@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V02:K0:G5FVrBeHctLGPAsz6m/LNr2KZDVtNsDS8GHBr2XAKz0 F7oqOaqcAg7/CAN5LM5X2G3IGXSobLsZPaEumU/HTjjD5bzOsK 8qb2N+WladI+jDTgqiKWJpP9LLAOCDMb1rscNFfEPuzMVaykDZ Jd+q3t4CsO7ZSvxtICKtnpXpGbB+kd9lc530LWsceDJ9F5EZXZ Zgm0E/nlE90lxSlllBSKFpACY1At0qmSlcrEcE/u7x8fJeH/RD AHQZ85X/LzAeb4FfAvvx9R2MuJwN15Yv1DVLgHfP9eRrKHwBdn vNVc5FP7UyBBu7AhE0rb2fDhXru8iuWUyQQfmEx6itg0xNcrfo k4xXheOMlv+NZjfZkJdg4ocZ2qH3VqnWmrODXWEyd Subject: [Json] Encoding X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 05 Jun 2013 18:37:58 -0000 I think the section on encoding is not saying anything useful and should be completely removed. From tbray@textuality.com Wed Jun 5 11:38:52 2013 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 8039A21F9B65 for ; Wed, 5 Jun 2013 11:38:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.313 X-Spam-Level: * X-Spam-Status: No, score=1.313 tagged_above=-999 required=5 tests=[AWL=-0.833, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_PBL=0.905, RDNS_NONE=0.1, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RIcafyHJCsqu for ; Wed, 5 Jun 2013 11:38:48 -0700 (PDT) Received: from mail-ve0-x22e.google.com (mail-ve0-x22e.google.com [IPv6:2607:f8b0:400c:c01::22e]) by ietfa.amsl.com (Postfix) with ESMTP id EE3B021F9700 for ; Wed, 5 Jun 2013 11:38:47 -0700 (PDT) Received: by mail-ve0-f174.google.com with SMTP id oz10so1527164veb.33 for ; Wed, 05 Jun 2013 11:38:06 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=cFiGOiB3NSDevqidsbzpBbYJGq07DUkzvBtpOCkqNoE=; b=cQdufY5KsAscMhZR7rQvMXtBGZG9kySzYNIwEaOXso58qZO2K3v8USEuwN8y3zCCcw EfUBuqwBhH3tyoodwyWSQeQ1KQghyCKwekD2GvurLlS/a1c3YSSFIgqK8c5lrJtSNCgG niVQKikaehG8/4DLSQLn4bhLyb7hTu6msrKKvnuCemnxlkns/bgB3/8Y7VhRkOLejrt/ Q83+zPMTNWQYhUxzCX50faGYx+MbFHIZ7ie9cnGN/qAXgamB1L4K+z/WGSOM3gXghoJL Jvv6RRidW+eMdlOeW9JADlyj3h4uoOTY9P113nfbyyM9QFP+GuF4LnMazH08Nkuy5VwA xWTA== MIME-Version: 1.0 X-Received: by 10.52.89.234 with SMTP id br10mr17663943vdb.103.1370457486487; Wed, 05 Jun 2013 11:38:06 -0700 (PDT) Received: by 10.220.48.14 with HTTP; Wed, 5 Jun 2013 11:38:06 -0700 (PDT) X-Originating-IP: [24.114.41.136] Received: by 10.220.48.14 with HTTP; Wed, 5 Jun 2013 11:38:06 -0700 (PDT) In-Reply-To: <51AF8479.5080002@crockford.com> References: <51AF8479.5080002@crockford.com> Date: Wed, 5 Jun 2013 11:38:06 -0700 Message-ID: From: Tim Bray To: Douglas Crockford Content-Type: multipart/alternative; boundary=20cf307f37d6a983e404de6c7f96 X-Gm-Message-State: ALoCoQnGHc0hM7Z94wCb2LTmXS4OBdPAK4oCzOpYYz8QwRp4wC0/0LSEQkZEEUyLNzRVn6KRW7wE Cc: json@ietf.org Subject: Re: [Json] The names within an object SHOULD be unique. X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 05 Jun 2013 18:38:52 -0000 --20cf307f37d6a983e404de6c7f96 Content-Type: text/plain; charset=UTF-8 Or, leave it as is and address it in the best practices doc. -T On Jun 5, 2013 11:35 AM, "Douglas Crockford" wrote: > This was the biggest blunder in the RFC. SHOULD should have been MUST. > > It is, sadly, too late to repair this. Instead, we must specify what > happens when you do the thing you SHOULD NOT do. We need to provide > implementations some slack here because some implementations do the right > thing and reject. Some implementations do the lazy thing and take that last > use of the name. > ______________________________**_________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/**listinfo/json > --20cf307f37d6a983e404de6c7f96 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Or, leave it as is and address it in the best practices doc.=
-T

On Jun 5, 2013 11:35 AM, "Douglas Crockford= " <douglas@crockford.com> wrote:
This was the biggest blunder in the RFC. SHOULD should have been MUST.

It is, sadly, too late to repair this. Instead, we must specify what happen= s when you do the thing you SHOULD NOT do. We need to provide implementatio= ns some slack here because some implementations do the right thing and reje= ct. Some implementations do the lazy thing and take that last use of the na= me.
_______________________________________________
json mailing list
json@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/json
--20cf307f37d6a983e404de6c7f96-- From markus.lanthaler@gmx.net Wed Jun 5 11:43:01 2013 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 D681821F8825 for ; Wed, 5 Jun 2013 11:43:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.15 X-Spam-Level: X-Spam-Status: No, score=0.15 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Rv5e-whAm8V for ; Wed, 5 Jun 2013 11:42:55 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by ietfa.amsl.com (Postfix) with ESMTP id D70C021F9B85 for ; Wed, 5 Jun 2013 11:42:31 -0700 (PDT) Received: from mailout-de.gmx.net ([10.1.76.2]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0M8LTo-1UWUs83Gi2-00vyS5 for ; Wed, 05 Jun 2013 20:42:14 +0200 Received: (qmail invoked by alias); 05 Jun 2013 18:42:14 -0000 Received: from 84-115-182-43.dynamic.surfer.at (EHLO Vostro3500) [84.115.182.43] by mail.gmx.net (mp002) with SMTP; 05 Jun 2013 20:42:14 +0200 X-Authenticated: #419883 X-Provags-ID: V01U2FsdGVkX19WStJFnaxW/kRMFp0YujUDRE8nBZIW8dsQlJzW9N urfsrCMjSse+1S From: "Markus Lanthaler" To: References: In-Reply-To: Date: Wed, 5 Jun 2013 20:42:08 +0200 Message-ID: <037d01ce621c$6372b030$2a581090$@lanthaler@gmx.net> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac5iDTX6np3j/9ndR8KQVqmRG3TCzwADxWFA Content-Language: de X-Y-GMX-Trusted: 0 Subject: Re: [Json] Proposed change to the title of the spec X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 05 Jun 2013 18:43:01 -0000 On Wednesday, June 05, 2013 6:53 PM, Tim Bray wrote: > I=E2=80=99m +0 on this but think it would be just wonderful to take > JavaScript out of the name. New title: =E2=80=9CThe JSON Format for > Encoding Data=E2=80=9D. Who said JSON had to stand for anything? -T +1 -- Markus Lanthaler @markuslanthaler From cabo@tzi.org Wed Jun 5 11:43:59 2013 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 C41CB21F9B91 for ; Wed, 5 Jun 2013 11:43:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EJAIaBV-kCcd for ; Wed, 5 Jun 2013 11:43:54 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 87D2421F9B8E for ; Wed, 5 Jun 2013 11:43:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r55IhRNC028615; Wed, 5 Jun 2013 20:43:27 +0200 (CEST) Received: from [127.0.0.1] (zoo.informatik.uni-bremen.de [134.102.218.16]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id B0AEA384C; Wed, 5 Jun 2013 20:43:26 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Content-Type: text/plain; charset=windows-1252 From: Carsten Bormann In-Reply-To: Date: Wed, 5 Jun 2013 20:43:26 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <51AE6E95.3050007@stpeter.im> <51AE736D.7030209@stpeter.im> <5DC8FE77-10A8-4835-8415-ACC3FC323663@tzi.org> To: Tim Bray X-Mailer: Apple Mail (2.1503) Cc: "Matt Miller \(mamille2\)" , "json@ietf.org" Subject: Re: [Json] Proposed change: update the Unicode version X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 05 Jun 2013 18:43:59 -0000 On Jun 5, 2013, at 18:56, Tim Bray wrote: >> It would help me if you could briefly explain what the reference to = 2.7 specifically adds here. >> (To me that is a bit confusing, as 2.7 is about internal programming = language representation, not about representation for interchange. But = maybe I just don't understand.) >=20 > Hm? The first paragraph says =93A Unicode string data type is simply = an ordered sequence of code units. Thus a Unicode 8-bit string is an = ordered sequence of 8-bit code units, a Unicode 16-bit string is an = ordered sequence of 16-bit code units, and a Unicode 32-bit string is an = ordered sequence of 32-bit code units.=94 If you were trying to answer my question I must admit that I'm not any = further along in understanding why the reference is to 2.7. 4627 Section 3 is about encoding JSON on the wire (correct me if that = impression is wrong). (Actually, it doesn't say that much, the meat is = then section 6, which with the title change raises the question whether = application/json and the JSON format are the same thing or not. But I = digress.) Unicode section 2.7 is most emphatically NOT about Unicode on = the wire, it is about data types in programming languages. Much of it = is about the problems of processing incomplete UTF-16 strings (unpaired = surrogates) in programming languages and their libraries. The section in the Unicode standard about encoding is 2.6. This defines = seven encoding schemes, some of which mainly differ in their treatment = of BOMs. BOMs are not allowed by the JSON grammar, but it is not = entirely obvious that that applies to the sequence of characters = obtained after decoding the Unicode encoding scheme. Now Douglas says: > I think the section on encoding is not saying anything useful and = should be completely removed. Works for me (and makes this discussion moot). Gr=FC=DFe, Carsten From cowan@ccil.org Wed Jun 5 11:47:10 2013 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 CA48B21F9BAC for ; Wed, 5 Jun 2013 11:47:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T78Oev+avoH9 for ; Wed, 5 Jun 2013 11:47:03 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id 5B11D21F9B8C for ; Wed, 5 Jun 2013 11:47:03 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1UkIje-0002qc-7x; Wed, 05 Jun 2013 14:47:02 -0400 Date: Wed, 5 Jun 2013 14:47:02 -0400 From: John Cowan To: Douglas Crockford Message-ID: <20130605184702.GB6999@mercury.ccil.org> References: <20130605162246.GG3680@mercury.ccil.org> <51AF7988.6040009@crockford.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <51AF7988.6040009@crockford.com> User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Cc: json@ietf.org Subject: Re: [Json] Unpaired surrogates in JSON strings X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 05 Jun 2013 18:47:11 -0000 Douglas Crockford scripsit: > Such a requirement will be breaking. Breaking changes are out of scope. How is it a breaking change to limit what documents are allowed to be *generated*? -- I don't know half of you half as well John Cowan as I should like, and I like less than half cowan@ccil.org of you half as well as you deserve. http://www.ccil.org/~cowan --Bilbo From douglas@crockford.com Wed Jun 5 11:58:58 2013 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 C04F521F9BF8 for ; Wed, 5 Jun 2013 11:58:11 -0700 (PDT) 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=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HJBoD9srWVlp for ; Wed, 5 Jun 2013 11:58:05 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id 479AF21F9C17 for ; Wed, 5 Jun 2013 11:57:48 -0700 (PDT) Received: from [192.168.114.223] ([216.113.168.135]) by mrelay.perfora.net (node=mrus3) with ESMTP (Nemesis) id 0MePod-1V2G5N3o6x-00POY2; Wed, 05 Jun 2013 14:57:25 -0400 Message-ID: <51AF8A09.50806@crockford.com> Date: Wed, 05 Jun 2013 11:57:13 -0700 From: Douglas Crockford User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: John Cowan References: <20130605162246.GG3680@mercury.ccil.org> <51AF7988.6040009@crockford.com> <20130605184702.GB6999@mercury.ccil.org> In-Reply-To: <20130605184702.GB6999@mercury.ccil.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V02:K0:dq1jo95+rZU7SmS8YQx/hFN/73/z7JPMwyzCB91p5rm b5SDXLmC0dcN1vPbbvLQCVvD7d3uA6TiLSL3NpAzXZLftmw70w F9ypcAZbpgMkYKB9Tt9xI977jUdfwI/piY3P/ncWuk+E6U89mL BwFkOcsCMaH9ANZGL0kyCq+B4E1fbmUJlQ6v7qiRpqFvkWBOot 9RwnbIUgamaGGhhw0p9Dg0TELPsxJgZNNvWM70P4fz6Rdz3TZ1 j0A5C8uDjGcHjHX7lee01rW63XFBt/bkTGA7c5oLXT6Sln2i1i hzGQCkxP+CGEaDI7KWvkdnqaN3RUf3v1s+f+eMzvD2M4xMVZ3u hv48YXPuVTUEmzAb/WVw= Cc: json@ietf.org Subject: Re: [Json] Unpaired surrogates in JSON strings X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 05 Jun 2013 18:58:58 -0000 On 6/5/2013 11:47 AM, John Cowan wrote: > Douglas Crockford scripsit: > >> Such a requirement will be breaking. Breaking changes are out of scope. > How is it a breaking change to limit what documents are allowed to be > *generated*? > Because JSON is currently being used in applications that deliver those codepoints. I believe that ECMA cannot accept if this is changed. From douglas@crockford.com Wed Jun 5 12:00:26 2013 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 5481D21F84D8 for ; Wed, 5 Jun 2013 12:00:26 -0700 (PDT) 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=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KeHIO4NucA0g for ; Wed, 5 Jun 2013 12:00:20 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id C0FAE21F8168 for ; Wed, 5 Jun 2013 12:00:09 -0700 (PDT) Received: from [192.168.114.223] ([216.113.168.135]) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis) id 0M1m9C-1UPsNC1PtS-00u4FU; Wed, 05 Jun 2013 14:59:50 -0400 Message-ID: <51AF8A9B.1020900@crockford.com> Date: Wed, 05 Jun 2013 11:59:39 -0700 From: Douglas Crockford User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Tim Bray References: <51AF8479.5080002@crockford.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V02:K0:pRBZZwWO9bK4I7oF+yohVLCK1txjUzuNbSa/iJWDLdQ DJwj5HYoO7iuHEbzSNfHJBGW9eTmlEXSm/gTVlBFr9edQEhOFO I1jluW72vtNiz6McqDADW+HaY/vbCUbn4IQQ1NynDvoDocCRSJ Q4PoDK6pua6FjyB3IHPM0f9vZeb5apW2MeHy9np6gA/7X2p9Dj 15rXgfv5SlO/d0D0AdnG7dfVBcl+80wBP/8OwFd1DHv7YNtxOJ yYO/hVX2c7cc5j0uvj4WbO9xztP3fErqI0Y2NkEgHurQpMlD51 kkKKh6KsqXK5a0teJOWEwUZxjOB0oG1ZHlVDbwFRJSxxeiA+EE ZDMLaWRB+eTG665HjhTCx7mxFG5ciAo1np8+3DaOs Cc: json@ietf.org Subject: Re: [Json] The names within an object SHOULD be unique. X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 05 Jun 2013 19:00:26 -0000 On 6/5/2013 11:38 AM, Tim Bray wrote: > > Or, leave it as is and address it in the best practices doc. > -T > > On Jun 5, 2013 11:35 AM, "Douglas Crockford" > wrote: > > This was the biggest blunder in the RFC. SHOULD should have been MUST. > > It is, sadly, too late to repair this. Instead, we must specify > what happens when you do the thing you SHOULD NOT do. We need to > provide implementations some slack here because some > implementations do the right thing and reject. Some > implementations do the lazy thing and take that last use of the name. > I like that, except that I am concerned about security exploits that are possible if some systems keep the first use and others keep the last. HTTP, for example, suffered from this. So I would like to be more specific. An implementation SHOULD reject, but if it accepts, it MUST take the last use. From cowan@ccil.org Wed Jun 5 12:00:35 2013 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 15A7521F8168 for ; Wed, 5 Jun 2013 12:00:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FxR87tZjhFFe for ; Wed, 5 Jun 2013 12:00:30 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id 09C0621F826B for ; Wed, 5 Jun 2013 12:00:27 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1UkIwc-0004CV-H5; Wed, 05 Jun 2013 15:00:26 -0400 Date: Wed, 5 Jun 2013 15:00:26 -0400 From: John Cowan To: Douglas Crockford Message-ID: <20130605190026.GD6999@mercury.ccil.org> References: <51AF8479.5080002@crockford.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <51AF8479.5080002@crockford.com> User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Cc: "json@ietf.org" Subject: Re: [Json] The names within an object SHOULD be unique. X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 05 Jun 2013 19:00:35 -0000 Douglas Crockford scripsit: > This was the biggest blunder in the RFC. SHOULD should have been MUST. > > It is, sadly, too late to repair this. I agree that it's too late to repair this on the acceptance side. But why can't we say that parsers MUST accept such documents but authors/producers/ generators MUST NOT create them? > Instead, we must specify what happens when you do the thing you SHOULD > NOT do. +1 to that. > We need to provide implementations some slack here because some > implementations do the right thing and reject. Some implementations > do the lazy thing and take that last use of the name. Or, indeed, the first use. -- They tried to pierce your heart John Cowan with a Morgul-knife that remains in the http://www.ccil.org/~cowan wound. If they had succeeded, you would become a wraith under the domination of the Dark Lord. --Gandalf From tbray@textuality.com Wed Jun 5 12:12:21 2013 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 7350721F93FB for ; Wed, 5 Jun 2013 12:12:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.957 X-Spam-Level: X-Spam-Status: No, score=0.957 tagged_above=-999 required=5 tests=[AWL=-1.161, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_SORBS_DUL=0.877, RDNS_NONE=0.1, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id txidq+Jq1PX4 for ; Wed, 5 Jun 2013 12:12:14 -0700 (PDT) Received: from mail-vb0-x22d.google.com (mail-vb0-x22d.google.com [IPv6:2607:f8b0:400c:c02::22d]) by ietfa.amsl.com (Postfix) with ESMTP id E357721F9BC9 for ; Wed, 5 Jun 2013 12:12:13 -0700 (PDT) Received: by mail-vb0-f45.google.com with SMTP id 12so1386230vbf.32 for ; Wed, 05 Jun 2013 12:12:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=nDNm3IilY2XLP1K2hJyNLe6XDVaKuMYv8mtZ5XRLkC8=; b=ik041DJDAxxaMQ/aWTKzHF+7LdQGwz6lviV1eJEexAmKk36TGAgZcvI46JwrG2VUEj rd8k1nhPYp3JvlpcA1gr2KKmzuaMxDVA++Zp2BqpVG8UQJF80ep4WMKY8nn3qSrAEsJs X+0RYBbncLKkFE+idC0aaH/xSJmD1W/LBi/OoVTMZKv2BRiC5OPz/Q4BDwrfNspdkf4Y 2a57q/OgD/WEQJG0TGwfbilMiwpz2mRdzeaW8fWMHhidtBShU9MPWFp3XOrKqzCiv9RG qb7mnqabEKpRBvJNS111ikrtiV5rd3XihxVC/IVuc5FTo/gefwOmx7s1hdNBe3TKWlIb ZEQg== MIME-Version: 1.0 X-Received: by 10.58.6.141 with SMTP id b13mr21137995vea.45.1370459533142; Wed, 05 Jun 2013 12:12:13 -0700 (PDT) Received: by 10.220.48.14 with HTTP; Wed, 5 Jun 2013 12:12:13 -0700 (PDT) X-Originating-IP: [96.49.81.176] In-Reply-To: <51AF8575.5060706@crockford.com> References: <51AF8575.5060706@crockford.com> Date: Wed, 5 Jun 2013 12:12:13 -0700 Message-ID: From: Tim Bray To: Douglas Crockford Content-Type: multipart/alternative; boundary=047d7b672c48a707c104de6cf9c9 X-Gm-Message-State: ALoCoQmBtKv3BtzANWnzbLHzs41RN9ec22TDlMJHzJVe6aOsAk0VZEXiSHPoHlCiVn74Z8yYNsv+ Cc: "json@ietf.org" Subject: Re: [Json] Encoding X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 05 Jun 2013 19:12:21 -0000 --047d7b672c48a707c104de6cf9c9 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable You mean http://tools.ietf.org/html/draft-ietf-json-rfc4627bis-00#section-3= ? This is the only place that says default UTF-8, unless we adopt the previous proposal that says so in the definition of String. I don=E2=80=99= t think it=E2=80=99s OK to drop the UTF-8 mandate. The language about encoding recognition is not actively harmful, but you=E2= =80=99re right, doesn=E2=80=99t add much value. -T On Wed, Jun 5, 2013 at 11:37 AM, Douglas Crockford w= rote: > I think the section on encoding is not saying anything useful and should > be completely removed. > ______________________________**_________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/**listinfo/json > --047d7b672c48a707c104de6cf9c9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
You mean http://tools.ietf.org/html/draft-ietf-json-rf= c4627bis-00#section-3 ?

This is the only place that says default= UTF-8, unless we adopt the previous proposal that says so in the definitio= n of String.=C2=A0 I don=E2=80=99t think it=E2=80=99s OK to drop the UTF-8 = mandate.

The language about encoding recognition is not actively harmful, but yo= u=E2=80=99re right, doesn=E2=80=99t add much value. -T


On Wed, Jun 5, 2013 at = 11:37 AM, Douglas Crockford <douglas@crockford.com> wrot= e:
I think the section on encoding is not sayin= g anything useful and should be completely removed.
_______________________________________________
json mailing list
json@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/json

--047d7b672c48a707c104de6cf9c9-- From markus.lanthaler@gmx.net Wed Jun 5 12:17:23 2013 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 AD45521F9B8E for ; Wed, 5 Jun 2013 12:17:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.283 X-Spam-Level: X-Spam-Status: No, score=-0.283 tagged_above=-999 required=5 tests=[AWL=0.867, BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q6CcW8KxIZGq for ; Wed, 5 Jun 2013 12:17:17 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) by ietfa.amsl.com (Postfix) with ESMTP id 6358D21F9BEE for ; Wed, 5 Jun 2013 12:17:13 -0700 (PDT) Received: from mailout-de.gmx.net ([10.1.76.12]) by mrigmx.server.lan (mrigmx002) with ESMTP (Nemesis) id 0MUBZ6-1UsewQ3LsI-00QyFA for ; Wed, 05 Jun 2013 21:17:08 +0200 Received: (qmail invoked by alias); 05 Jun 2013 19:17:08 -0000 Received: from 84-115-182-43.dynamic.surfer.at (EHLO Vostro3500) [84.115.182.43] by mail.gmx.net (mp012) with SMTP; 05 Jun 2013 21:17:08 +0200 X-Authenticated: #419883 X-Provags-ID: V01U2FsdGVkX1/UdioHIz3UAiMrtPDAiQJg8XFR5sOak8NXKjYShE h577zy0pxaym4B From: "Markus Lanthaler" To: References: <51AF8479.5080002@crockford.com> <51AF8A9B.1020900@crockford.com> In-Reply-To: <51AF8A9B.1020900@crockford.com> Date: Wed, 5 Jun 2013 21:17:02 +0200 Message-ID: <03d701ce6221$439bcd50$cad367f0$@lanthaler@gmx.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac5iHx/1RJuFRtXeRampjXavCbr5sAAATpLw Content-Language: de X-Y-GMX-Trusted: 0 Subject: Re: [Json] The names within an object SHOULD be unique. X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 05 Jun 2013 19:17:23 -0000 On Wednesday, June 05, 2013 9:00 PM, Douglas Crockford wrote: > On 6/5/2013 11:38 AM, Tim Bray wrote: > > > > Or, leave it as is and address it in the best practices doc. > > -T > > > > On Jun 5, 2013 11:35 AM, "Douglas Crockford" > > wrote: > > > > This was the biggest blunder in the RFC. SHOULD should have been > > MUST. > > > > It is, sadly, too late to repair this. Instead, we must specify > > what happens when you do the thing you SHOULD NOT do. We need to > > provide implementations some slack here because some > > implementations do the right thing and reject. Some > > implementations do the lazy thing and take that last use of the > > name. > > > > I like that, except that I am concerned about security exploits that > are possible if some systems keep the first use and others keep the > last. HTTP, for example, suffered from this. So I would like to be more > specific. An implementation SHOULD reject, but if it accepts, it MUST > take the last use. This seems like the best approach to me to address this unfortunate situation. This is so fundamental (and often discussed) that I think it really belongs in the specification. It would also make sense to add a clear interoperability warning and perhaps explain that this "feature" is there only due to historic reasons. -- Markus Lanthaler @markuslanthaler From sgbeal@googlemail.com Wed Jun 5 12:27:28 2013 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 0A24321F9B33 for ; Wed, 5 Jun 2013 12:27:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eORU3CagOcWy for ; Wed, 5 Jun 2013 12:27:26 -0700 (PDT) Received: from mail-wg0-x230.google.com (mail-wg0-x230.google.com [IPv6:2a00:1450:400c:c00::230]) by ietfa.amsl.com (Postfix) with ESMTP id 4C70F21F9AFF for ; Wed, 5 Jun 2013 12:27:25 -0700 (PDT) Received: by mail-wg0-f48.google.com with SMTP id f12so1645678wgh.3 for ; Wed, 05 Jun 2013 12:27:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=HcyZYOIxE3Dc63S7yGZQt29su8aJBFjLGxnT2Q+YRxI=; b=czdUhkjDCE5GQ2ffjRtixmagvn9f/9dn2csMFdHBXtJ9N0XgLWhZZCxpOWK1R5LOP+ bkeVeMvja9l/5uYN04zgny8GQ6yVv9Z6XbGf1ga/Eawb8jxuegttqZbBCeUjKqk+bi5Q c2tJ2KjdcSzJSJL4P/5mc/A+zHT3RzmanYoa2uJTzeOkrQODrtJo3cD6mVQ57Ej1uJtT g7qdPUtdCVpU/0aXHqGxuP02qrXUgZdCh1AclRWSWIIM2G/76xWcHRAVA/OdBC8A4Vg+ vRE0VB4cwXGaarterSCWcc15thhxntYfQHGdjbN9SpoElyMj9sLtuJ9M/X/Gkr9i93Z/ u1sw== MIME-Version: 1.0 X-Received: by 10.180.74.81 with SMTP id r17mr8153505wiv.49.1370460441583; Wed, 05 Jun 2013 12:27:21 -0700 (PDT) Received: by 10.194.42.230 with HTTP; Wed, 5 Jun 2013 12:27:21 -0700 (PDT) In-Reply-To: References: <51AF8575.5060706@crockford.com> Date: Wed, 5 Jun 2013 21:27:21 +0200 Message-ID: From: Stephan Beal To: Tim Bray Content-Type: multipart/alternative; boundary=f46d043d65d3cca5ee04de6d2fb6 Cc: Douglas Crockford , "json@ietf.org" Subject: Re: [Json] Encoding X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 05 Jun 2013 19:29:20 -0000 --f46d043d65d3cca5ee04de6d2fb6 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Wed, Jun 5, 2013 at 9:12 PM, Tim Bray wrote: > The language about encoding recognition is not actively harmful, but > you=92re right, doesn=92t add much value. -T > (and this time to the list...) FWIW: the implication of the recognition possibilities didn't occur to me until reading that bit, so i found it helpful. To be clear, i understand you to be referring to the 2nd paragraph of the link: Since the first two characters of a JSON text will always be ASCII characters [RFC0020 ], it is possible to determine whether an octet stream is UTF-8, UTF-16 (BE or LE), or UTF-32 (BE or LE) by looking at the pattern of nulls in the first four octets. --=20 ----- stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal --f46d043d65d3cca5ee04de6d2fb6 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
On Wed, Jun 5, 2013 at 9:12 PM, Tim Bray <tbray@textua= lity.com> wrote:
The language about encoding recognition i= s not actively harmful, but you=92re right, doesn=92t add much value. -T

(and this time to the list...)=

FWIW: the implication of the recognition possibilities didn't= occur to me until reading that bit, so i found it helpful. To be clear, i = understand you to be referring to the 2nd paragraph of the link:

Since the firs=
t two characters of a JSON text will always be ASCII
   characters [RFC0020=
], it is possible to determine whether an octet
   stream is UTF-8, UTF-16 (BE or LE), or UTF-32 (BE or LE) by looking
   at the pattern of nulls in the first four octets.
= =A0

--
----- stephan beal
http://wanderinghorse= .net/home/stephan/
--f46d043d65d3cca5ee04de6d2fb6-- From sgbeal@googlemail.com Wed Jun 5 12:31:02 2013 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 C8BAF21F8464 for ; Wed, 5 Jun 2013 12:31:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KMX5XNAbFV5G for ; Wed, 5 Jun 2013 12:31:00 -0700 (PDT) Received: from mail-wg0-x234.google.com (mail-wg0-x234.google.com [IPv6:2a00:1450:400c:c00::234]) by ietfa.amsl.com (Postfix) with ESMTP id 6235A21F9B06 for ; Wed, 5 Jun 2013 12:31:00 -0700 (PDT) Received: by mail-wg0-f52.google.com with SMTP id z12so1044257wgg.19 for ; Wed, 05 Jun 2013 12:30:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Fn8wsDrwQgoy9d5waGs4//T0F+SL+7x7zpLCEwuws48=; b=fLVTFuJUfD5bRB+oyrnzHhEUZ9wOy1YnoqF3SMP7kLby2Ld31j10W4wuMbQU3JFL6z Zf5reTWpnCKA5+P0dBYRTf29hYNfSEbD7MLA6ECpeWPgglw2IVQueLwaUSpTxSJcBIj5 AWTCY9cUB3/zoflEaHHZKM+IzeHaj/6KbmMMQTD+ZaQAKZExPKVWmEYC+zSe095AjYt5 VNkZ6oT5nHkJzpXuOKfs5RGjht2tA5jM4hlczruJVTSgAJ1XlKIPHzxTsYMCo9Uwkylv bETItughcjCpm1H45MteUr3ptvcWhLvnQ6dhXvxJM/D2VVDapQ5xKrGJiAfKIQcAdnqn I5jQ== MIME-Version: 1.0 X-Received: by 10.180.12.72 with SMTP id w8mr8179926wib.4.1370460639647; Wed, 05 Jun 2013 12:30:39 -0700 (PDT) Received: by 10.194.42.230 with HTTP; Wed, 5 Jun 2013 12:30:39 -0700 (PDT) In-Reply-To: <51af8f23.85f8420a.597e.0ccbSMTPIN_ADDED_BROKEN@mx.google.com> References: <51AF8479.5080002@crockford.com> <51AF8A9B.1020900@crockford.com> <51af8f23.85f8420a.597e.0ccbSMTPIN_ADDED_BROKEN@mx.google.com> Date: Wed, 5 Jun 2013 21:30:39 +0200 Message-ID: From: Stephan Beal To: Markus Lanthaler Content-Type: multipart/alternative; boundary=001a11c243869adece04de6d3b6a Cc: "json@ietf.org" Subject: Re: [Json] The names within an object SHOULD be unique. X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 05 Jun 2013 19:31:02 -0000 --001a11c243869adece04de6d3b6a Content-Type: text/plain; charset=ISO-8859-1 On Wed, Jun 5, 2013 at 9:17 PM, Markus Lanthaler wrote: > On Wednesday, June 05, 2013 9:00 PM, Douglas Crockford wrote: > > specific. An implementation SHOULD reject, but if it accepts, it MUST > > take the last use. > > This seems like the best approach to me to address this unfortunate > situation. > @Markus: sorry for the accidental off-list reply. gmail is sending to the sender by default. +1 > This is so fundamental (and often discussed) that I think it > really belongs in the specification. It would also make sense to add a > clear > interoperability warning and perhaps explain that this "feature" is there > only due to historic reasons. i wouldn't quite go so far as to say it's strictly historical in nature. It gives implementations leeway on what is essentially a corner case (who actively generates non-unique keys?). Forcing a specific behaviour here could potentially leave a lot of current 100% JSON-compliant parsers suddenly non-compliant because of [what i perceive as] an unusual corner case. Pointing it out as a potential pitfall, sure, but i wouldn't claim that it's "historical baggage." -- ----- stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal --001a11c243869adece04de6d3b6a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Jun 5, 2013 at 9:17 PM, Markus Lanthaler=A0<= markus.lanthaler@gmx.net>=A0wrote:
On Wednesday, June 05, 2013 9:00 PM, Douglas Crockfo= rd wrote:
> specific. An implementation SHOUL= D reject, but if it accepts, it MUST
> take the last use.

This seems like the best approach to me to address = this unfortunate
situation.

= @Markus: sorry for the accidental off-list reply. gmail is sending to the s= ender by default.=A0

+1
=A0
This is so fundamental (and often discussed) that I think it
really belongs in the specification. It would also make sense to add a clea= r
interoperability warning and perhaps explain that this "feature&q= uot; is there
only due to historic reasons.

i wouldn't quite go so far as to s= ay it's strictly historical in nature. It gives implementations leeway = on what is essentially a corner case (who actively generates non-unique key= s?). Forcing a specific behaviour here could potentially leave a lot of cur= rent 100% JSON-compliant parsers suddenly non-compliant because of [what i = perceive as] an unusual corner case. Pointing it out as a potential pitfall= , sure, but i wouldn't claim that it's "historical baggage.&qu= ot;

--
----- stephan beal
http://wa= nderinghorse.net/home/stephan/
--001a11c243869adece04de6d3b6a-- From jsontest@yahoo.com Wed Jun 5 12:44:57 2013 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 7B1DA21F8265 for ; Wed, 5 Jun 2013 12:44:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lPOp4FCj-vH0 for ; Wed, 5 Jun 2013 12:44:51 -0700 (PDT) Received: from nm24-vm5.bullet.mail.gq1.yahoo.com (nm24-vm5.bullet.mail.gq1.yahoo.com [98.136.217.100]) by ietfa.amsl.com (Postfix) with ESMTP id EA2EA21F9AFE for ; Wed, 5 Jun 2013 12:44:50 -0700 (PDT) Received: from [98.137.12.60] by nm24.bullet.mail.gq1.yahoo.com with NNFMP; 05 Jun 2013 19:44:29 -0000 Received: from [208.71.42.192] by tm5.bullet.mail.gq1.yahoo.com with NNFMP; 05 Jun 2013 19:44:29 -0000 Received: from [127.0.0.1] by smtp203.mail.gq1.yahoo.com with NNFMP; 05 Jun 2013 19:44:29 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1370461469; bh=PcH6RHxVD4w3Nzteh8e8zi8kZSzYMxdazJO+kROSyrU=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:References:In-Reply-To:Mime-Version:Content-Type:Content-Transfer-Encoding:Message-Id:Cc:X-Mailer:From:Subject:Date:To; b=Zx6BWPVMnyBPbal+7Dm5b88g8RMm6wu7uUN1jD8yLkSoAkCazCKZKP3hvdCMDlF9QmfftyXWHYUz7RGLQF9tpxe81jtzeDFg6CA5ylBNws+rtmUK+lJXKWQL+N/T9xbnN2dlkYZAzWDdp7f1tzESBA/ltLFhZm21CyMISaU/ca4= X-Yahoo-Newman-Id: 520042.52456.bm@smtp203.mail.gq1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: OHfdkU0VM1nKHFWFI6iwZdH.FEF3DN4Poh9_tS38kVM5oub iWeoPTu1Lt.i7OvVrLekN7704mknlcRpunQJ02zKpcYL83KbuFASp5tYOKgw VSmRC8fPzyeFEVVxV4YEPztP1VGgzb5b6akgTVNqhSmPioZTGstAc.lPDWAr Xl2OK2H9pAYd9RFbFCmzFNceFHjMjSBqYaG6mPUqdRcvqwSmJkDqWGQm5tA9 gIwwFB6oxPu73Ewn0LErcZsS208tLZvC.roWwYSTFjPS8_dHLKb7tYjbiwCZ qSdR7Xi2Sn2QQQ6NqdoG6_fS6P1NE9DDsfmdpZXs2.KpJXJ4tDGH_px0VJ2m nSyKZfgWK28FOGukKI0JF28Tk6Cc7WVRkJWms03YUGd49MZtq8ZsXE84ZzFy kN7MKCbVVvfF1V5j089WSKrDz9EiGB_37Qh3uVFkIOXMx8KqdLRXqGNqJYCZ MjCZnom5Gc4AAiPowuo1mJERM4R29xcYcH.c9XRr8B5nWnDKSB3dm3scT1YZ 6vh5JDd9nPJUWQyHtGFVnBWnunaG0 X-Yahoo-SMTP: indQcmSswBC8IKsm6t4aCAPskK3T X-Rocket-Received: from [192.168.0.102] (jsontest@76.29.100.42 with ) by smtp203.mail.gq1.yahoo.com with SMTP; 05 Jun 2013 12:44:29 -0700 PDT References: <51AF7B3B.4030108@crockford.com> In-Reply-To: <51AF7B3B.4030108@crockford.com> Mime-Version: 1.0 (1.0) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPod Mail (9B206) From: Vinny A Date: Wed, 5 Jun 2013 14:43:07 -0500 To: Douglas Crockford Cc: Nico Williams , Tim Bray , Paul Hoffman , "json@ietf.org" Subject: Re: [Json] Proposed change to the title of the spec X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 05 Jun 2013 19:44:58 -0000 On Jun 5, 2013, at 12:54 PM, Douglas Crockford wrote= : > I like this. There is no need to put JavaScript in the title. I think the t= itle should be > The JSON Data Interchange Format. +1 ----------------- Vinny www.jsontest.com From nico@cryptonector.com Wed Jun 5 12:56:20 2013 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 DEE9721F8CF4 for ; Wed, 5 Jun 2013 12:56:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.894 X-Spam-Level: X-Spam-Status: No, score=-1.894 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C3L3rSl1htt3 for ; Wed, 5 Jun 2013 12:56:15 -0700 (PDT) Received: from homiemail-a26.g.dreamhost.com (mailbigip.dreamhost.com [208.97.132.5]) by ietfa.amsl.com (Postfix) with ESMTP id 3F9E521F8F83 for ; Wed, 5 Jun 2013 12:56:10 -0700 (PDT) Received: from homiemail-a26.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a26.g.dreamhost.com (Postfix) with ESMTP id E9202B807F for ; Wed, 5 Jun 2013 12:56:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=iq+19DWBYRkCsmWKRGOF NtYiGtY=; b=qhANwjZJs8nOT8oaVsXWw0jlLwtRrBCCkjuk5OLsfPC0lK62Ekz8 dZmlbaMou99/CLs06pceEwVHj3NPvu3w5RG3GifXdMxcYBShGbrmkluaifDUpphW YuV5SC0GLRU8uBCQSQGaZqlkEfthNvDbBcPRbS0mxpCJ5ZWzVvcjNU4= Received: from mail-wi0-f180.google.com (mail-wi0-f180.google.com [209.85.212.180]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a26.g.dreamhost.com (Postfix) with ESMTPSA id 941CCB806B for ; Wed, 5 Jun 2013 12:56:09 -0700 (PDT) Received: by mail-wi0-f180.google.com with SMTP id hn14so1646921wib.13 for ; Wed, 05 Jun 2013 12:56:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=n2z5DbCOGGh5jMH1WroW6bALr6xfVlitH7bOWzOc5ek=; b=AdNzxxyB1SfEBAvYxNw+QjVbSVyPU/SZ2dnNTRjBcpjJdv4oDXozVDQ03ZYBYSRfHi 4jufCPD+lpxAhj4bVfYRK99YYfAaaeJnNCG78oZ0TGq+KH2cQ4WMVjvZu2FXBouL5vrN hKc18CkGVeMn4REeFVdDA0IYsB3DUYJNYB1UssYLp1B57D08qKhv3uAheEovZMUgIIko pghEo5/eVvlzX59s7qJSTymwop7zhaVzk4nUr9B/eppBSE8rdolLtvkh32jqaX1X3oaS 2BIcdiB52m90FM+crXIlFRxbxXesz88Sx0zDPoMo5Ei0qbgF0+0w1mpcCZYMM9orC0Yq q0aw== MIME-Version: 1.0 X-Received: by 10.194.77.66 with SMTP id q2mr30606620wjw.34.1370462167929; Wed, 05 Jun 2013 12:56:07 -0700 (PDT) Received: by 10.216.63.136 with HTTP; Wed, 5 Jun 2013 12:56:07 -0700 (PDT) In-Reply-To: References: <51AF8479.5080002@crockford.com> <51AF8A9B.1020900@crockford.com> <51af8f23.85f8420a.597e.0ccbSMTPIN_ADDED_BROKEN@mx.google.com> Date: Wed, 5 Jun 2013 14:56:07 -0500 Message-ID: From: Nico Williams To: Stephan Beal Content-Type: text/plain; charset=UTF-8 Cc: Markus Lanthaler , "json@ietf.org" Subject: Re: [Json] The names within an object SHOULD be unique. X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 05 Jun 2013 19:56:20 -0000 On Wed, Jun 5, 2013 at 2:30 PM, Stephan Beal wrote: > i wouldn't quite go so far as to say it's strictly historical in nature. It > gives implementations leeway on what is essentially a corner case (who > actively generates non-unique keys?). Forcing a specific behaviour here If no one does that then we can make a "breaking" change here that breaks no one, no? (I'm being the devil's advocate here.) > could potentially leave a lot of current 100% JSON-compliant parsers > suddenly non-compliant because of [what i perceive as] an unusual corner > case. Pointing it out as a potential pitfall, sure, but i wouldn't claim > that it's "historical baggage." There's no compliance police here. If some change merely leaves us with non-compliant implementations then maybe I don't care, after all they'd still compliant with the old RFC and could be updated to be compliant with the new one. But we mustn't break interoperability any more than it already was. If indeed there are senders with duplicate keys (and different values) that alternately get to talk to receivers that take the first or last key, then there's already broken interop, so picking one of the two should be fair game. But I bet we have little real data on this, so we'll end up assuming that such a change can break interop. Nico -- From mmorley@mpcm.com Wed Jun 5 12:57:37 2013 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 25A8421F9AFA for ; Wed, 5 Jun 2013 12:57:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oO42P3Tqu-L6 for ; Wed, 5 Jun 2013 12:57:36 -0700 (PDT) Received: from mail-la0-x22c.google.com (mail-la0-x22c.google.com [IPv6:2a00:1450:4010:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 3023E21F9AD2 for ; Wed, 5 Jun 2013 12:57:35 -0700 (PDT) Received: by mail-la0-f44.google.com with SMTP id er20so1849308lab.3 for ; Wed, 05 Jun 2013 12:57:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :x-gm-message-state; bh=uyPLgv7NWv47U8nqVfZcfhwFWzOOjFzw0D03bGTSOZw=; b=GJb8pJEv5IVtYJLWVv5yB2xwDpLB3qRox8JtnUwJAVo0xYV2Utrzl3ZOl6xyAhuDMj RbD6QFN+dsIX/UMPIuWMqJ5NJ/nD3TufkuNhcZbPS3lDG4He3QVGM0hOYGE/qraQ4Hui c3C0G5Iy67NQQPnS1OeG63nQMloycU6XBJEZ89JA1opvZWDZ8/ebfXvbag8c57vjdTL2 6yPLaKh4fGjQ/5/oD7UFn+vgXfifzff7VP4QzurjKndO8TpvqR6dV5CZQJE/hUaX1rK+ VADHSVxzzCO0DBsQmFgCiLebSMMjEae9SEduFrrsTnBZXcQIB2LYxOf3krbJpv4q067Q GbLQ== MIME-Version: 1.0 X-Received: by 10.112.130.163 with SMTP id of3mr15814429lbb.41.1370462241456; Wed, 05 Jun 2013 12:57:21 -0700 (PDT) Sender: mmorley@mpcm.com Received: by 10.114.160.69 with HTTP; Wed, 5 Jun 2013 12:57:21 -0700 (PDT) In-Reply-To: <51AF7B3B.4030108@crockford.com> References: <51AF7B3B.4030108@crockford.com> Date: Wed, 5 Jun 2013 15:57:21 -0400 X-Google-Sender-Auth: UtkvcFjXgA6B9Oef2UQmzr887Nc Message-ID: From: Matthew Morley To: Douglas Crockford Content-Type: multipart/alternative; boundary=047d7b3a883a14927c04de6d9b3d X-Gm-Message-State: ALoCoQm2uzapu1IEVLEX3fQuKfIU0jxowBt9C55IXxJIx6M/67UuI4bUObp7FyH+/g2fzZvkbHEP Cc: Nico Williams , Tim Bray , Paul Hoffman , "json@ietf.org" Subject: Re: [Json] Proposed change to the title of the spec X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 05 Jun 2013 19:57:37 -0000 --047d7b3a883a14927c04de6d9b3d Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Wed, Jun 5, 2013 at 1:54 PM, Douglas Crockford wr= ote: > On 6/5/2013 9:53 AM, Tim Bray wrote: > >> I=92m +0 on this but think it would be just wonderful to take JavaScript >> out of the name. New title: =93The JSON Format for Encoding Data=94. Who= said >> JSON had to stand for anything? -T >> >> I like this. There is no need to put JavaScript in the title. I think > the title should be > The JSON Data Interchange Format. +1 --=20 Matthew P. C. Morley --047d7b3a883a14927c04de6d9b3d Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
On Wed, Jun 5, 2013 at 1:54 PM, Douglas Crockford <do= uglas@crockford.com> wrote:
On 6/5/2013 9:53 AM, Tim Bray wrote:
I=92m +0 on this but think it would be just wonderful to take JavaScript ou= t of the name. New title: =93The JSON Format for Encoding Data=94. Who said= JSON had to stand for anything? -T

I like this. There is no need to put JavaScript in the title. I think the t= itle should be
The JSON Data Interchange Format.

+1

--
Matthew P. C. Morley
--047d7b3a883a14927c04de6d9b3d-- From cromis@gmail.com Wed Jun 5 13:08:53 2013 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 3DB7621F9A9F for ; Wed, 5 Jun 2013 13:08:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qYovVDvJE-3L for ; Wed, 5 Jun 2013 13:08:52 -0700 (PDT) Received: from mail-qa0-x230.google.com (mail-qa0-x230.google.com [IPv6:2607:f8b0:400d:c00::230]) by ietfa.amsl.com (Postfix) with ESMTP id 6A58921F9A19 for ; Wed, 5 Jun 2013 13:08:52 -0700 (PDT) Received: by mail-qa0-f48.google.com with SMTP id cm16so428472qab.14 for ; Wed, 05 Jun 2013 13:08:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=kE22aE48HTEhyTAqNl1KzRUy+tSQKn2OIwbKn4o9g0s=; b=NoCCrvXwQWIJJ7dPQeIgG9X1ewRKYuJG2T1e1141jaJMcqvwSEVyHJg+GL9n2WbQ4h 5LpvtewpwXfuNu/4XFwzlhYF6N8SuCW6cCQiAHI6bUeaS03J37IicocaQ4JF9eCLn4pf uUBK8HUSzimr6hPOAklYfePxSopfGsvGovrWOJx3Dddmuns8mZ/0aer/dGocfqigMaPK 8z3jGMIkOEl0XAhI2MA7qout1p07C1kCqjCTITRi+wU/Vvr86GLAZEfsg7elc3cXiVdN /B6CUhYlfTHd6UM1ZJO9uaiKtY9cJBUqSsG7n8ekaA6fPhdesMps+NNb6QeZWO3vPgsc wGeQ== X-Received: by 10.49.96.104 with SMTP id dr8mr35705055qeb.43.1370462929183; Wed, 05 Jun 2013 13:08:49 -0700 (PDT) MIME-Version: 1.0 Sender: cromis@gmail.com Received: by 10.49.106.228 with HTTP; Wed, 5 Jun 2013 13:08:29 -0700 (PDT) In-Reply-To: <51AF8575.5060706@crockford.com> References: <51AF8575.5060706@crockford.com> From: Jacob Davies Date: Wed, 5 Jun 2013 13:08:29 -0700 X-Google-Sender-Auth: bo8h1meOve6Jq-FtZkqOviB7NDA Message-ID: To: Douglas Crockford Content-Type: multipart/alternative; boundary=047d7b6da860129efd04de6dc438 Cc: "json@ietf.org" Subject: Re: [Json] Encoding X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 05 Jun 2013 20:08:53 -0000 --047d7b6da860129efd04de6dc438 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Jun 5, 2013 at 11:37 AM, Douglas Crockford wrote: > I think the section on encoding is not saying anything useful and should be completely removed. I agree with a caveat about UTF-8 as the default, because it is possible for two compliant implementations to communicate using any text encoding (e.g. ASCII) provided they agree on escaping characters it cannot represent literally, as long as it can literally represent all of [a-zA-Z0-9+-.{}[",:/\]\\]. It's reasonable to specify UTF-8 as the default where a content-type but no encoding is given, but otherwise leave it unspecified. The part on detecting encoding is of historical interest but not really relevant anymore. --047d7b6da860129efd04de6dc438 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Jun 5, 2013 at 11:37 AM, Douglas Crockford <douglas@crockford.com> wrote:<= br>> I think the section on encoding is not saying anything useful and s= hould be completely removed.

I agree with a caveat about UTF-8 as the default, because it is possibl= e for two compliant implementations to communicate using any text encoding = (e.g. ASCII) provided they agree on escaping characters it cannot represent= literally, as long as it can literally represent all of [a-zA-Z0-9+-.{}[&q= uot;,:/\]\\]. It's reasonable to specify UTF-8 as the default where a c= ontent-type but no encoding is given, but otherwise leave it unspecified.
The part on detecting encoding is of historical interest but= not really relevant anymore.
--047d7b6da860129efd04de6dc438-- From lear@cisco.com Wed Jun 5 13:08:59 2013 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 2F02421F9AB8 for ; Wed, 5 Jun 2013 13:08:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QNIzk3kyyFnS for ; Wed, 5 Jun 2013 13:08:53 -0700 (PDT) Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com [144.254.224.147]) by ietfa.amsl.com (Postfix) with ESMTP id 797C921F9A19 for ; Wed, 5 Jun 2013 13:08:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=801; q=dns/txt; s=iport; t=1370462933; x=1371672533; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=YA2CC8YyaOWruCzffM8dMbGwFp3KOXdElvVZc6xI1XA=; b=XceWyC7wdqw22dZTzE/6ZS6EiQ++8dEBqXvuiznvnbUB40tPg1kKMc5z WI0TaRM2iQ0tjj03C16CiDX0msGPT+iiIeXHWIw8iblTZiGCaDb0W2xon x/jF880uLEl+AfGyq96OtmWiGxTANv7o0qQrKbzuu7USIlXF/+kS2gjPw k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhsFAP2Zr1GQ/khN/2dsb2JhbABagwmDbLwDfxZ0giMBAQEEI1UBEAsYAgIFFgsCAgkDAgECAUUGDQEHAQGICawTkT+BJo4FB4JHgRQDlz+RQIMROg X-IronPort-AV: E=Sophos;i="4.87,809,1363132800"; d="scan'208";a="14490669" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-4.cisco.com with ESMTP; 05 Jun 2013 20:08:52 +0000 Received: from dhcp-10-61-109-56.cisco.com (dhcp-10-61-109-56.cisco.com [10.61.109.56]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r55K8m9o003971 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 5 Jun 2013 20:08:50 GMT Message-ID: <51AF9ACF.5020507@cisco.com> Date: Wed, 05 Jun 2013 22:08:47 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Douglas Crockford References: <51AF8479.5080002@crockford.com> In-Reply-To: <51AF8479.5080002@crockford.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "json@ietf.org" Subject: Re: [Json] The names within an object SHOULD be unique. X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 05 Jun 2013 20:08:59 -0000 Hi, On 6/5/13 8:33 PM, Douglas Crockford wrote: > This was the biggest blunder in the RFC. SHOULD should have been MUST. > > It is, sadly, too late to repair this. Instead, we must specify what > happens when you do the thing you SHOULD NOT do. We need to provide > implementations some slack here because some implementations do the > right thing and reject. Some implementations do the lazy thing and > take that last use of the name. Demonstrating my age, an old trick we've done that goes back to RFC-1123 is to say MUST NOT send, and then implementations MAY NOT process, and if they do MUST process thusly... That gives you the possibility of potentially getting rid of something at a later date. I don't know if you want to use it here. It only sometimes works. Eliot From douglas@crockford.com Wed Jun 5 13:11:58 2013 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 ED26721F9AFE for ; Wed, 5 Jun 2013 13:11:57 -0700 (PDT) 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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A4l3Kjk3oPKl for ; Wed, 5 Jun 2013 13:11:51 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id B12FE21F9B08 for ; Wed, 5 Jun 2013 13:11:51 -0700 (PDT) Received: from [192.168.114.223] ([216.113.168.135]) by mrelay.perfora.net (node=mrus4) with ESMTP (Nemesis) id 0LeeAA-1U2kUb0nWw-00pmVf; Wed, 05 Jun 2013 16:11:29 -0400 Message-ID: <51AF9B65.9080606@crockford.com> Date: Wed, 05 Jun 2013 13:11:17 -0700 From: Douglas Crockford User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Tim Bray References: <51AF8575.5060706@crockford.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Provags-ID: V02:K0:abN9EtgwB1UjtaeoqbKwAgi6oC0jh08D7WOT6tquA7n VuVIlLl9ermKmEGLleYx0oZdxo88WQzaglMsCbZ1E7x/HzF6GN NFJmeI9/O2yb9sghKyJuSM0aj29udzG4z14/df7o6MwhwkgaWp 8l/QzxvAUwfTxD99OZ9g3mI0iDt0DmX4R3CWormTapobYUM6ky hlgYZne8MiOudfQszXbrs+Qul9BoZoeO3KOO+XpRiTosfGCeip nWEBR8WwteGhub13yaOvnDPAYZBdk1tRcnL3eYppMMKv0XBBil wJS83KiBBVZLfWVm59ECRI95aCQSKE4B+2KmFoIaHV+2pGDiY0 P8C49aOUyR3LDmEuY1Pk0HAZPCqQ92leHguS2Mttz Cc: "json@ietf.org" Subject: Re: [Json] Encoding X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 05 Jun 2013 20:11:58 -0000 On 6/5/2013 12:12 PM, Tim Bray wrote: > You mean > http://tools.ietf.org/html/draft-ietf-json-rfc4627bis-00#section-3 ? > > This is the only place that says default UTF-8, unless we adopt the > previous proposal that says so in the definition of String. I don’t > think it’s OK to drop the UTF-8 mandate. > > The language about encoding recognition is not actively harmful, but > you’re right, doesn’t add much value. -T > Not harmful, but not important. I added section 3 originally because at that time the web was knee deep in charsets and Unicode adoption was quite slow. So I insisted that the local charsets not be allowed so that I could avoid putting charset declarations into JSON. Now, 12 years later, Unicode is now well established. So the thing that Section 3 was trying to do is no longer needed. I don't think the format needs to mandate the encoding. Perhaps that belongs in the best practices doc. From petejson@codalogic.com Wed Jun 5 13:04:20 2013 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 796B521F9AD2 for ; Wed, 5 Jun 2013 13:04:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.667 X-Spam-Level: * X-Spam-Status: No, score=1.667 tagged_above=-999 required=5 tests=[BAYES_50=0.001, SARE_HEAD_XUNSENT=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y9Rs-WXo-jPP for ; Wed, 5 Jun 2013 13:04:15 -0700 (PDT) Received: from codalogic.com (codalogic.com [94.136.60.219]) by ietfa.amsl.com (Postfix) with ESMTP id 501B321F9AB8 for ; Wed, 5 Jun 2013 13:04:12 -0700 (PDT) Received: (qmail 32753 invoked from network); 5 Jun 2013 21:04:11 +0100 Received: from host86-132-241-164.range86-132.btcentralplus.com (HELO codalogic) (86.132.241.164) by codalogic.com with (RC4-MD5 encrypted) SMTP; 5 Jun 2013 21:04:10 +0100 Message-ID: <0739B3A790114EA9BF865EF2E93B4E4F@codalogic> From: "Pete Cordell" To: References: <51AF8575.5060706@crockford.com> X-Unsent: 1 x-vipre-scanned: 02E5989200481002E599DF Date: Wed, 5 Jun 2013 21:04:40 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Subject: Re: [Json] Encoding X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 05 Jun 2013 20:17:32 -0000 Original Message From: "Douglas Crockford" >I think the section on encoding is not saying anything useful and should be >completely removed. As a humble hacker I found section 3 adds the most helpful additional pragmatic information beyond the diagrams at json.org. Also, I'd be surprised if Unicode assumes the first characters will be ASCII, so I wouldn't expect to find encoding deduction rules along similar lines there, so the section seems to add some value. A more explicit statement on whether BOMs are or are not allowed would be helpful also. Humbly yours, Pete Cordell Codalogic Ltd C++ tools for C++ programmers, http://codalogic.com Read & write XML in C++, http://www.xml2cpp.com From tsaloranta@gmail.com Wed Jun 5 13:18:34 2013 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 CC51B21F94F9 for ; Wed, 5 Jun 2013 13:18:33 -0700 (PDT) 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=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JCbvUIflv0tl for ; Wed, 5 Jun 2013 13:18:31 -0700 (PDT) Received: from mail-wg0-x232.google.com (mail-wg0-x232.google.com [IPv6:2a00:1450:400c:c00::232]) by ietfa.amsl.com (Postfix) with ESMTP id 488A621F91A3 for ; Wed, 5 Jun 2013 13:18:31 -0700 (PDT) Received: by mail-wg0-f50.google.com with SMTP id k13so1731273wgh.29 for ; Wed, 05 Jun 2013 13:18:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Cv0RbV7hQecsVhgN4AeSbZasZvnpK+aUnEOIdwcoKKU=; b=hlpyWbqeJC1eKHJ4c46O3pUnnkkVs5gtvVLXLcBsQds2wYgBsWVxzNmV9RBEgHsWyW ZJLD+QU1S077f3hK5aoenvDI31Il+2IA6Q4mpj96G6vvqhn/DxTk24hhnyqGvsgz+e9v xmUBtiaQ3THg0sWQi9Q6726usA2LsAa8ACFL8btw9h3so0xaFr1PLiZkT2g27dEJFSRf oXMSfROMGA+TCFL/q7JseiXmo+DNY+eYna58TfMRssLx9QCPJuSBe9IFf28J0HHy41ro 76FDUM75b+vw5SjHtirfY2Xo8v/Sj03kKI1QIWlJtZgnYIEoFi8wJKPnNxHdA/XuXazg vuBA== MIME-Version: 1.0 X-Received: by 10.180.97.106 with SMTP id dz10mr8348126wib.2.1370463510422; Wed, 05 Jun 2013 13:18:30 -0700 (PDT) Received: by 10.227.97.6 with HTTP; Wed, 5 Jun 2013 13:18:30 -0700 (PDT) In-Reply-To: References: <51AF8575.5060706@crockford.com> Date: Wed, 5 Jun 2013 13:18:30 -0700 Message-ID: From: Tatu Saloranta To: Jacob Davies Content-Type: multipart/alternative; boundary=f46d0442712eb7691804de6de6d5 Cc: Douglas Crockford , "json@ietf.org" Subject: Re: [Json] Encoding X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 05 Jun 2013 20:18:34 -0000 --f46d0442712eb7691804de6de6d5 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Jun 5, 2013 at 1:08 PM, Jacob Davies wrote: > On Wed, Jun 5, 2013 at 11:37 AM, Douglas Crockford > wrote: > > I think the section on encoding is not saying anything useful and should > be completely removed. > > I agree with a caveat about UTF-8 as the default, because it is possible > for two compliant implementations to communicate using any text encoding > (e.g. ASCII) provided they agree on escaping characters it cannot represent > literally, as long as it can literally represent all of > [a-zA-Z0-9+-.{}[",:/\]\\]. It's reasonable to specify UTF-8 as the default > where a content-type but no encoding is given, but otherwise leave it > unspecified. > > Allowing character encodings other than existing ones (UTF-8/16/32) would be a breaking change -- compliant libraries currently can count on simple and reliable auto-detection -- and I can not see how use of other encodings (except for special case of ASCII, as that simply falls within UTF-8 umbrella) would be considered compliant currently. Is there a reason to expand set of allowed encodings? That would remove one nice simplicity aspect, for little or no benefit. > The part on detecting encoding is of historical interest but not really > relevant anymore. > > I thought it is among more useful parts, as it points out that auto-detection is easy to do. It is similar to XML spec's (non-authoritative) part in how XML encoding is to be detected. -+ Tatu +- --f46d0442712eb7691804de6de6d5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Jun 5, 2013 at 1:08 PM, Jacob Davies <jacob@well.com= > wrote:
On Wed, Jun 5, 2013 at 11:37 AM, Douglas= Crockford <d= ouglas@crockford.com> wrote:
> I think= the section on encoding is not saying anything useful and should be comple= tely removed.

I agree with a caveat about UTF-8 as the default, because it is p= ossible for two compliant implementations to communicate using any text enc= oding (e.g. ASCII) provided they agree on escaping characters it cannot rep= resent literally, as long as it can literally represent all of [a-zA-Z0-9+-= .{}[",:/\]\\]. It's reasonable to specify UTF-8 as the default whe= re a content-type but no encoding is given, but otherwise leave it unspecif= ied.


Allowing character encodings other than existing ones (UTF-8/1= 6/32) would be a breaking change -- compliant libraries currently can count= on simple and reliable auto-detection -- and I can not see how use of othe= r encodings (except for special case of ASCII, as that simply falls within = UTF-8 umbrella) would be considered compliant currently.

Is there a reason to e= xpand set of allowed encodings? That would remove one nice simplicity aspec= t, for little or no benefit.
=A0
The part on detecting encoding is of histo= rical interest but not really relevant anymore.


I thought it is among more useful parts, as it points out that auto-detecti= on is easy to do. It is similar to XML spec's (non-authoritative) part = in how XML encoding is to be detected.

-+ Tat= u +-

--f46d0442712eb7691804de6de6d5-- From douglas@crockford.com Wed Jun 5 13:19:43 2013 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 E879221F9298 for ; Wed, 5 Jun 2013 13:19:42 -0700 (PDT) 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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QZwMJMVFxIfn for ; Wed, 5 Jun 2013 13:19:37 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id D94D921F9412 for ; Wed, 5 Jun 2013 13:19:35 -0700 (PDT) Received: from [192.168.114.223] ([216.113.168.135]) by mrelay.perfora.net (node=mrus3) with ESMTP (Nemesis) id 0MbOcG-1V0t5l399A-00Jalx; Wed, 05 Jun 2013 16:19:35 -0400 Message-ID: <51AF9D4C.5060403@crockford.com> Date: Wed, 05 Jun 2013 13:19:24 -0700 From: Douglas Crockford User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "json@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V02:K0:UxwR5fZwS5OQeukEvwymgbFwC5KLWBS1GCXkdwxs4pV 0FM6hgaZq04u58BZsCgDsLJDZCuH0DnBhutuPhukWKEqcibMls +K88w/zy6s4tXbZ/dGze3O/3H0ZEyX8TYFTVdrf6YKYuF3p2yt fgRgwxKQemYjJzjc6bP35DS4HfiZFuvgk4bb5Eg4Xb/bxODMg/ OKnKpv6E/pji4sfzHNCRZBz/18DBZsDFelI0auWjityIAzj64G iWkgUiOPt8odv3dh3Qgq0wB0VnQPH2/jXKheIKBPlqFemhcKwD LCPxOxRVXoWWUxAf01zo/QOXgOZLnZsA4iIxiciNt7Dl8g9gBP ONk2pAlbmmZX+i0b3+cb5+10l2KtmBbw2Op9OkCCC Subject: [Json] Strings X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 05 Jun 2013 20:19:43 -0000 It should say explicitly that these three all produce exactly the same result: "\u002F" "\/" "/" I have seen confusion about this. From tsaloranta@gmail.com Wed Jun 5 13:22:16 2013 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 BBC1721F9642 for ; Wed, 5 Jun 2013 13:22:16 -0700 (PDT) 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=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Do1h0jQrZEML for ; Wed, 5 Jun 2013 13:22:16 -0700 (PDT) Received: from mail-we0-x231.google.com (mail-we0-x231.google.com [IPv6:2a00:1450:400c:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id 9058321F939E for ; Wed, 5 Jun 2013 13:22:15 -0700 (PDT) Received: by mail-we0-f177.google.com with SMTP id m19so1696647wev.36 for ; Wed, 05 Jun 2013 13:22:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ACNg/BrdDwpDFt2NnpzRVRHhZ75MLA1XNF3OElJyScs=; b=dqwREEA96HA+gCrLC0LETeTjhvvJ0jyghsiZvPMTNi27VchLG1E0kTaIpvUa3NE9EV pqCI4KDivBqxLtEyc3kkYpq1UlwYIiX3B/422bx0k/BO8gBuRMRT9G62zYdX4FfFY64A KoC21cYCmJw4jQOm7/YnH/z8DDKxPBMHdphA1Wdt4qVaKbHhjbZ+55MwMM/D8hIQz27L lPL/9AnNcLWuwherXRN9GiLS48JrqzI5OTi5Cf0tpFk+SFPDFz1DAtrOBMQ8UP5ZOfDg MVmoA32a4+3GQ0eY8tNc0D4lfEqp44vDymZn27jKE8vpcaXgFm2k9MvlXIN457nPnHda tVsQ== MIME-Version: 1.0 X-Received: by 10.180.86.38 with SMTP id m6mr8426595wiz.25.1370463734705; Wed, 05 Jun 2013 13:22:14 -0700 (PDT) Received: by 10.227.97.6 with HTTP; Wed, 5 Jun 2013 13:22:14 -0700 (PDT) In-Reply-To: <51AF9B65.9080606@crockford.com> References: <51AF8575.5060706@crockford.com> <51AF9B65.9080606@crockford.com> Date: Wed, 5 Jun 2013 13:22:14 -0700 Message-ID: From: Tatu Saloranta To: Douglas Crockford Content-Type: multipart/alternative; boundary=f46d0443064215b57b04de6df4f7 Cc: Tim Bray , "json@ietf.org" Subject: Re: [Json] Encoding X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 05 Jun 2013 20:22:16 -0000 --f46d0443064215b57b04de6df4f7 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Wed, Jun 5, 2013 at 1:11 PM, Douglas Crockford wr= ote: > On 6/5/2013 12:12 PM, Tim Bray wrote: > >> You mean http://tools.ietf.org/html/**draft-ietf-json-rfc4627bis-00#** >> section-3? >> >> This is the only place that says default UTF-8, unless we adopt the >> previous proposal that says so in the definition of String. I don=92t th= ink >> it=92s OK to drop the UTF-8 mandate. >> >> The language about encoding recognition is not actively harmful, but >> you=92re right, doesn=92t add much value. -T >> >> Not harmful, but not important. I added section 3 originally because at > that time the web was knee deep in charsets and Unicode adoption was quit= e > slow. So I insisted that the local charsets not be allowed so that I coul= d > avoid putting charset declarations into JSON. > > Now, 12 years later, Unicode is now well established. So the thing that > Section 3 was trying to do is no longer needed. I don't think the format > needs to mandate the encoding. Perhaps that belongs in the best practices > doc. > > If limitation on allowed encodings was lifted or removed, what would the replacement then be? Unlike XML that specifies an in-document way of specifying encoding, JSON has no equivalent mechanism. And use of externally provided encoding declaration would either be mandated, or suggested along with specifying default encoding (UTF-8) that must be assumed in absence of such information. I think it would be better to leave the limitation in place; if one absolutely must work with non-compliant content, they are free to transcode content from unsupported encoding into canonical one(s). This is what happens currently with tools in Java space. -+ Tatu +- --f46d0443064215b57b04de6df4f7 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
On Wed, Jun 5, 2013 at 1:11 PM, Douglas Crockford <do= uglas@crockford.com> wrote:
On 6/5/2013 12:12 PM, Tim = Bray wrote:
You mean http://tools.ietf.org/html/draft-ietf= -json-rfc4627bis-00#section-3 ?

This is the only place that says default UTF-8, unless we adopt the previou= s proposal that says so in the definition of String. I don=92t think it=92s= OK to drop the UTF-8 mandate.

The language about encoding recognition is not actively harmful, but you=92= re right, doesn=92t add much value. -T

Not harmful, but not important. I added section 3 originally because at tha= t time the web was knee deep in charsets and Unicode adoption was quite slo= w. So I insisted that the local charsets not be allowed so that I could avo= id putting charset declarations into JSON.

Now, 12 years later, Unicode is now well established. So the thing that Sec= tion 3 was trying to do is no longer needed. I don't think the format n= eeds to mandate the encoding. Perhaps that belongs in the best practices do= c.


If= limitation on allowed encodings was lifted or removed, what would the repl= acement then be? Unlike XML that specifies an in-document way of specifying= encoding, JSON has no equivalent mechanism. And use of externally provided= encoding declaration would either be mandated, or suggested along with spe= cifying default encoding (UTF-8) that must be assumed in absence of such in= formation.

I think it would be better to leave the lim= itation in place; if one absolutely must work with non-compliant content, t= hey are free to transcode content from unsupported encoding into canonical = one(s). This is what happens currently with tools in Java space.

-+ Tatu +-

= =A0
--f46d0443064215b57b04de6df4f7-- From douglas@crockford.com Wed Jun 5 13:22:52 2013 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 4C19E21F9993 for ; Wed, 5 Jun 2013 13:22:52 -0700 (PDT) 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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7FYjvN5nVTGh for ; Wed, 5 Jun 2013 13:22:46 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id 5C87921F939E for ; Wed, 5 Jun 2013 13:22:46 -0700 (PDT) Received: from [192.168.114.223] ([216.113.168.135]) by mrelay.perfora.net (node=mrus0) with ESMTP (Nemesis) id 0Lm2Tx-1UAiUg13Qn-00ZiRe; Wed, 05 Jun 2013 16:22:42 -0400 Message-ID: <51AF9E06.7040208@crockford.com> Date: Wed, 05 Jun 2013 13:22:30 -0700 From: Douglas Crockford User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Tatu Saloranta References: <51AF8575.5060706@crockford.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V02:K0:viQvA958inCItpiMeAthuSdL5lITiqYu2Sm+HXHglcC f+sMIOEHUCXyPrMgkjeidQ3S5syDm94s4YTREZ0xr/y0Mys54Z CNA2bsGUfVhmHKoZUGjYPwd1jg28FAjKF44bosuc69E25bcd1y tTKAzR40ius05qKz2BSshDoORQRapntHpgLDYS/5Jo6prikxDM x3ajwjlc37e6+VDlD7rRX00x8C9JyMdQgI95sqEtB0TTZQLN5u KLf2VoTjCR0pJH7P+3xLc/R7T67nVag9qN9daVlec/zKo+XCiI eCxwKZxQAKyMCSJf/2kXlmpKyU0OkymwDzIG8Faw5r0QZx9IbG eay6zQIVhxzznl8KW4FEf4GxFiytOYLfakYsxBA0W Cc: Jacob Davies , "json@ietf.org" Subject: Re: [Json] Encoding X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 05 Jun 2013 20:22:52 -0000 On 6/5/2013 1:18 PM, Tatu Saloranta wrote: > On Wed, Jun 5, 2013 at 1:08 PM, Jacob Davies > wrote: > > On Wed, Jun 5, 2013 at 11:37 AM, Douglas Crockford > > wrote: > > I think the section on encoding is not saying anything useful > and should be completely removed. > > I agree with a caveat about UTF-8 as the default, because it is > possible for two compliant implementations to communicate using > any text encoding (e.g. ASCII) provided they agree on escaping > characters it cannot represent literally, as long as it can > literally represent all of [a-zA-Z0-9+-.{}[",:/\]\\]. It's > reasonable to specify UTF-8 as the default where a content-type > but no encoding is given, but otherwise leave it unspecified. > > > Allowing character encodings other than existing ones (UTF-8/16/32) > would be a breaking change -- compliant libraries currently can count > on simple and reliable auto-detection -- and I can not see how use of > other encodings (except for special case of ASCII, as that simply > falls within UTF-8 umbrella) would be considered compliant currently. > > Is there a reason to expand set of allowed encodings? That would > remove one nice simplicity aspect, for little or no benefit. > > The part on detecting encoding is of historical interest but not > really relevant anymore. > > > I thought it is among more useful parts, as it points out that > auto-detection is easy to do. It is similar to XML spec's > (non-authoritative) part in how XML encoding is to be detected. > I am not aware of any implementation that does that detection. Everyone uses UTF-8, at least on the wire. That is a practice that is so well established now that I don't think the format needs to mention it. From tsaloranta@gmail.com Wed Jun 5 13:30:20 2013 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 5314A21F8F29 for ; Wed, 5 Jun 2013 13:30:20 -0700 (PDT) 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=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Y67WuulooZg for ; Wed, 5 Jun 2013 13:30:19 -0700 (PDT) Received: from mail-wg0-x22d.google.com (mail-wg0-x22d.google.com [IPv6:2a00:1450:400c:c00::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 2D83421F8F0C for ; Wed, 5 Jun 2013 13:30:19 -0700 (PDT) Received: by mail-wg0-f45.google.com with SMTP id n12so1719996wgh.0 for ; Wed, 05 Jun 2013 13:30:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=4/AINf/NO1ROHoeRRSsnASgdgmDAsOzcQUg/OSP0jpY=; b=uPSciZJvzqmkusMiNRnAl9OLEiFNUs9mAUTsULfnDcEkusSNlqJPzEcep20rdCjAGK skwe5WC8t8koOniMHeXZXhm1n7MEtS6pDGtIUxc+vXqWVrt5ypypVr94ujftCrxbFUaN xoPsJ+OLOfZeKZ5491SHum3c64DOCEeZdMAehQ062cCqv3IhR4N5TNhOYzb6HJ410i0L jHKZFZVtCo+0p94yXNzhHZdEUjSZceihWd5az3J8ueyN99lyno8/oD5zBQAJ1XXD+CY7 Wk6bmWKyPv/ndt4NG2I06uNMwBMAVQVaZthwYUGRTTqaRm1/DNz8muIWbV3FKy3NTyGN CsRQ== MIME-Version: 1.0 X-Received: by 10.194.249.231 with SMTP id yx7mr20222385wjc.13.1370464218232; Wed, 05 Jun 2013 13:30:18 -0700 (PDT) Received: by 10.227.97.6 with HTTP; Wed, 5 Jun 2013 13:30:18 -0700 (PDT) In-Reply-To: <51AF9E06.7040208@crockford.com> References: <51AF8575.5060706@crockford.com> <51AF9E06.7040208@crockford.com> Date: Wed, 5 Jun 2013 13:30:18 -0700 Message-ID: From: Tatu Saloranta To: Douglas Crockford Content-Type: multipart/alternative; boundary=001a11c29cc4e7bef104de6e10db Cc: Jacob Davies , "json@ietf.org" Subject: Re: [Json] Encoding X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 05 Jun 2013 20:30:20 -0000 --001a11c29cc4e7bef104de6e10db Content-Type: text/plain; charset=ISO-8859-1 On Wed, Jun 5, 2013 at 1:22 PM, Douglas Crockford wrote: > On 6/5/2013 1:18 PM, Tatu Saloranta wrote: > >> On Wed, Jun 5, 2013 at 1:08 PM, Jacob Davies > jacob@well.com>> wrote: >> >> On Wed, Jun 5, 2013 at 11:37 AM, Douglas Crockford >> **> wrote: >> > I think the section on encoding is not saying anything useful >> and should be completely removed. >> >> I agree with a caveat about UTF-8 as the default, because it is >> possible for two compliant implementations to communicate using >> any text encoding (e.g. ASCII) provided they agree on escaping >> characters it cannot represent literally, as long as it can >> literally represent all of [a-zA-Z0-9+-.{}[",:/\]\\]. It's >> reasonable to specify UTF-8 as the default where a content-type >> but no encoding is given, but otherwise leave it unspecified. >> >> >> Allowing character encodings other than existing ones (UTF-8/16/32) would >> be a breaking change -- compliant libraries currently can count on simple >> and reliable auto-detection -- and I can not see how use of other encodings >> (except for special case of ASCII, as that simply falls within UTF-8 >> umbrella) would be considered compliant currently. >> >> Is there a reason to expand set of allowed encodings? That would remove >> one nice simplicity aspect, for little or no benefit. >> >> The part on detecting encoding is of historical interest but not >> really relevant anymore. >> >> >> I thought it is among more useful parts, as it points out that >> auto-detection is easy to do. It is similar to XML spec's >> (non-authoritative) part in how XML encoding is to be detected. >> >> I am not aware of any implementation that does that detection. Everyone > uses UTF-8, at least on the wire. That is a practice that is so well > established now that I don't think the format needs to mention it. > For JSON, Jackson (the leading Java JSON lib) has done this from beginning, and actually supports all legal encodings, including UTF-32. Most other libraries just punt the problem by requiring caller to pass in Reader that does byte->char decoding; but that seems odd given how easy auto-detection and handling is. For XML all serious Java libs do auto-detection; Xerces, Woodstox and Aalto to name some. Non-normative rules from XML spec are very valuable to get this part right; and it works well. But I do not see how one could omit specification of how encoding is to be detected, given that a HUGE number of interoperability problems are directly caused by mismatch between encoding writer used and reader assumes. Relying on contextual encoding information may work for HTTP (but I doubt even that, helping developers on daily basis); but there is more to JSON usage than HTTP exchange. -+ Tatu +- --001a11c29cc4e7bef104de6e10db Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Jun 5, 2013 at 1:22 PM, Douglas Crockford <do= uglas@crockford.com> wrote:
On 6/5/2013 1:18 PM, Tatu Saloranta wrote:
On Wed, Jun 5, 2013 at 1:08 PM, Jacob Davies <jacob@well.com <mailto:jacob@well.com>> wrote:

=A0 =A0 On Wed, Jun 5, 2013 at 11:37 AM, Douglas Crockford
=A0 =A0 <doug= las@crockford.com <mailto:douglas@crockford.com>> wrote:
=A0 =A0 > I think the section on encoding is not saying anything useful<= br> =A0 =A0 and should be completely removed.

=A0 =A0 I agree with a caveat about UTF-8 as the default, because it is
=A0 =A0 possible for two compliant implementations to communicate using
=A0 =A0 any text encoding (e.g. ASCII) provided they agree on escaping
=A0 =A0 characters it cannot represent literally, as long as it can
=A0 =A0 literally represent all of [a-zA-Z0-9+-.{}[",:/\]\\]. It's=
=A0 =A0 reasonable to specify UTF-8 as the default where a content-type
=A0 =A0 but no encoding is given, but otherwise leave it unspecified.


Allowing character encodings other than existing ones (UTF-8/16/32) would b= e a breaking change -- compliant libraries currently can count on simple an= d reliable auto-detection -- and I can not see how use of other encodings (= except for special case of ASCII, as that simply falls within UTF-8 umbrell= a) would be considered compliant currently.

Is there a reason to expand set of allowed encodings? That would remove one= nice simplicity aspect, for little or no benefit.

=A0 =A0 The part on detecting encoding is of historical interest but not =A0 =A0 really relevant anymore.


I thought it is among more useful parts, as it points out that auto-detecti= on is easy to do. It is similar to XML spec's (non-authoritative) part = in how XML encoding is to be detected.

I am not aware of any implementation that does that detection. Everyone use= s UTF-8, at least on the wire. That is a practice that is so well establish= ed now that I don't think the format needs to mention it.


For JSON, Jackson (the leading Java JSON lib)= has done this from beginning, and actually supports all legal encodings, i= ncluding UTF-32. Most other libraries just punt the problem by requiring ca= ller to pass in Reader that does byte->char decoding; but that seems odd= given how easy auto-detection and handling is.

For XML all serious Java libs do auto-detection; Xerces, Woodstox and Aalt= o to name some. Non-normative rules from XML spec are very valuable to get = this part right; and it works well.

But I do not see how one could omit specification of how encoding is to be= detected, given that a HUGE number of interoperability problems are direct= ly caused by mismatch between encoding writer used and reader assumes. Rely= ing on contextual encoding information may work for HTTP (but I doubt even = that, helping developers on daily basis); but there is more to JSON usage t= han HTTP exchange.

-+ Tatu +-


--001a11c29cc4e7bef104de6e10db-- From markus.lanthaler@gmx.net Wed Jun 5 13:42:07 2013 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 37F8511E80A4 for ; Wed, 5 Jun 2013 13:42:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.244 X-Spam-Level: X-Spam-Status: No, score=0.244 tagged_above=-999 required=5 tests=[AWL=-0.095, BAYES_05=-1.11, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MFEtn028J2Pm for ; Wed, 5 Jun 2013 13:42:01 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) by ietfa.amsl.com (Postfix) with ESMTP id 24BA921E804B for ; Wed, 5 Jun 2013 13:42:00 -0700 (PDT) Received: from mailout-de.gmx.net ([10.1.76.2]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0LrGyY-1UGXe736ey-0138xs for ; Wed, 05 Jun 2013 22:41:59 +0200 Received: (qmail invoked by alias); 05 Jun 2013 20:41:59 -0000 Received: from 84-115-182-43.dynamic.surfer.at (EHLO Vostro3500) [84.115.182.43] by mail.gmx.net (mp002) with SMTP; 05 Jun 2013 22:41:59 +0200 X-Authenticated: #419883 X-Provags-ID: V01U2FsdGVkX19UC8kxogBUR/X77qYRW39DAfAUf6Gr49xoxkTTqS DEKpRcVkU0uOQb From: "Markus Lanthaler" To: References: <51AF9D4C.5060403@crockford.com> In-Reply-To: <51AF9D4C.5060403@crockford.com> Date: Wed, 5 Jun 2013 22:41:54 +0200 Message-ID: <043d01ce622d$1e002760$5a007620$@lanthaler@gmx.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac5iKgwDPeZBFD4uQc+f1xjLA7HCVgAAoXpA Content-Language: de X-Y-GMX-Trusted: 0 Subject: Re: [Json] Strings X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 05 Jun 2013 20:42:07 -0000 On Wednesday, June 05, 2013 10:19 PM, Douglas Crockford wrote: > It should say explicitly that these three all produce exactly the same > result: > > "\u002F" > "\/" > "/" > > I have seen confusion about this. Me too. By default, PHP e.g. serializes a "/" to "\/". I'm wondering whether it would make sense to recommend that serializers use "/"? -- Markus Lanthaler @markuslanthaler From markus.lanthaler@gmx.net Wed Jun 5 13:45:57 2013 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 DD34D21F9A98 for ; Wed, 5 Jun 2013 13:45:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.481 X-Spam-Level: X-Spam-Status: No, score=-0.481 tagged_above=-999 required=5 tests=[AWL=0.669, BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AG3B9osxEX5Q for ; Wed, 5 Jun 2013 13:45:52 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) by ietfa.amsl.com (Postfix) with ESMTP id CB56F21E804B for ; Wed, 5 Jun 2013 13:45:51 -0700 (PDT) Received: from mailout-de.gmx.net ([10.1.76.35]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0M5aK6-1UUtCI30au-00xcd9 for ; Wed, 05 Jun 2013 22:45:50 +0200 Received: (qmail invoked by alias); 05 Jun 2013 20:45:50 -0000 Received: from 84-115-182-43.dynamic.surfer.at (EHLO Vostro3500) [84.115.182.43] by mail.gmx.net (mp035) with SMTP; 05 Jun 2013 22:45:50 +0200 X-Authenticated: #419883 X-Provags-ID: V01U2FsdGVkX1/J7NtQ9UfJOAFSm7FjvWg2qxFtNsvNEOhlm3B1kn EfOMQs/WDgjQl7 From: "Markus Lanthaler" To: References: <51AF8575.5060706@crockford.com> <51AF9E06.7040208@crockford.com> In-Reply-To: <51AF9E06.7040208@crockford.com> Date: Wed, 5 Jun 2013 22:45:45 +0200 Message-ID: <043e01ce622d$a7c551a0$f74ff4e0$@lanthaler@gmx.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac5iKoWbDzveTx3BQzCUJmVpJOcrTQAAqbAQ Content-Language: de X-Y-GMX-Trusted: 0 Subject: Re: [Json] Encoding X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 05 Jun 2013 20:45:58 -0000 On Wednesday, June 05, 2013 10:23 PM, Douglas Crockford wrote: > On 6/5/2013 1:18 PM, Tatu Saloranta wrote: > > Allowing character encodings other than existing ones (UTF-8/16/32) > > would be a breaking change -- compliant libraries currently can count > > on simple and reliable auto-detection -- and I can not see how use of > > other encodings (except for special case of ASCII, as that simply > > falls within UTF-8 umbrella) would be considered compliant currently. > > > > [...] > > > I am not aware of any implementation that does that detection. Everyone > uses UTF-8, at least on the wire. That is a practice that is so well > established now that I don't think the format needs to mention it. The reason why it is so well established (for JSON at least) is because it was in the RFC for a decade. I see no harm in leaving it in. I had the charset discussion more than once and pointing people to the RFC was by far the easiest way to convince them that e.g., no charset media type param is necessary. -- Markus Lanthaler @markuslanthaler From markus.lanthaler@gmx.net Wed Jun 5 13:52:27 2013 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 20B7021F90EF for ; Wed, 5 Jun 2013 13:52:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.593 X-Spam-Level: X-Spam-Status: No, score=-0.593 tagged_above=-999 required=5 tests=[AWL=0.557, BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g+FmhmGixwWI for ; Wed, 5 Jun 2013 13:52:20 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by ietfa.amsl.com (Postfix) with ESMTP id F2F1821F909A for ; Wed, 5 Jun 2013 13:52:18 -0700 (PDT) Received: from mailout-de.gmx.net ([10.1.76.30]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0LcE27-1U0mim3Sx3-00jXyV for ; Wed, 05 Jun 2013 22:52:13 +0200 Received: (qmail invoked by alias); 05 Jun 2013 20:52:13 -0000 Received: from 84-115-182-43.dynamic.surfer.at (EHLO Vostro3500) [84.115.182.43] by mail.gmx.net (mp030) with SMTP; 05 Jun 2013 22:52:13 +0200 X-Authenticated: #419883 X-Provags-ID: V01U2FsdGVkX1/mAMFLwJrmdKwUQtQMqxcwFhCYYXzeFE7pmpLGce nACmJv/8rd8DZP From: "Markus Lanthaler" To: "'Nico Williams'" , "'Stephan Beal'" References: <51AF8479.5080002@crockford.com> <51AF8A9B.1020900@crockford.com> <51af8f23.85f8420a.597e.0ccbSMTPIN_ADDED_BROKEN@mx.google.com> In-Reply-To: Date: Wed, 5 Jun 2013 22:52:08 +0200 Message-ID: <043f01ce622e$8c20f1b0$a462d510$@lanthaler@gmx.net> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac5iJ6FQ2SrTxenVQA+npbcVvgX75gABhE1A Content-Language: de X-Y-GMX-Trusted: 0 Cc: json@ietf.org Subject: Re: [Json] The names within an object SHOULD be unique. X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 05 Jun 2013 20:52:27 -0000 On Wednesday, June 05, 2013 9:56 PM, Nico Williams wrote: > On Wed, Jun 5, 2013 at 2:30 PM, Stephan Beal wrote: >> i wouldn't quite go so far as to say it's strictly historical in = nature. It >> gives implementations leeway on what is essentially a corner case = (who >> actively generates non-unique keys?). Forcing a specific behaviour = here >=20 > If no one does that then we can make a "breaking" change here that > breaks no one, no? (I'm being the devil's advocate here.) I've seen people using this for comments. People relied on the fact that = serializers ignored all but the last occurrence of a key. > > could potentially leave a lot of current 100% JSON-compliant parsers > > suddenly non-compliant because of [what i perceive as] an unusual > > corner case. Pointing it out as a potential pitfall, sure, but i > > wouldn't claim that it's "historical baggage." >=20 > There's no compliance police here. If some change merely leaves us > with non-compliant implementations then maybe I don't care, after all > they'd still compliant with the old RFC and could be updated to be > compliant with the new one. But we mustn't break interoperability any > more than it already was. If indeed there are senders with duplicate > keys (and different values) that alternately get to talk to receivers > that take the first or last key, then there's already broken interop, > so picking one of the two should be fair game. But I bet we have > little real data on this, so we'll end up assuming that such a change > can break interop. I think we have to choose one to get interoperability. I've seen some = systems that merge the values of multiple keys in an array but most do = what JavaScript does, i.e., they ignore all but the last key. I really like the proposal Eliot Lear made in another thread: > Demonstrating my age, an old trick we've done that goes back to RFC- > 1123 is to say MUST NOT send, and then implementations MAY NOT = process, > and if they do MUST process thusly... >=20 > That gives you the possibility of potentially getting rid of something > at a later date. I don't know if you want to use it here. It only > sometimes works. -- Markus Lanthaler @markuslanthaler From cabo@tzi.org Wed Jun 5 13:53:15 2013 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 8174021F9AE2 for ; Wed, 5 Jun 2013 13:53:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zhCwdORGMkqZ for ; Wed, 5 Jun 2013 13:53:02 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 25C5121F9ADC for ; Wed, 5 Jun 2013 13:53:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r55Kqsfp011217; Wed, 5 Jun 2013 22:52:54 +0200 (CEST) Received: from [127.0.0.1] (zoo.informatik.uni-bremen.de [134.102.218.16]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id D3B5C38C1; Wed, 5 Jun 2013 22:52:53 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <51AF9B65.9080606@crockford.com> Date: Wed, 5 Jun 2013 22:52:53 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <899742DD-BD76-4BD6-93BF-BADC2DF3E3F2@tzi.org> References: <51AF8575.5060706@crockford.com> <51AF9B65.9080606@crockford.com> To: Douglas Crockford X-Mailer: Apple Mail (2.1503) Cc: Tim Bray , "json@ietf.org" Subject: Re: [Json] Encoding X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 05 Jun 2013 20:53:15 -0000 On Jun 5, 2013, at 22:11, Douglas Crockford = wrote: > I don't think the format needs to mandate the encoding. So what about the text in "encoding considerations" in section 6? Note that application/json does not have a charset parameter, so "not = mandating the encoding" isn't really an option here. On Jun 5, 2013, at 22:22, Douglas Crockford = wrote: > Everyone uses UTF-8, at least on the wire. +1 Wouldn't it be nice if the specification reflected reality here with a = MUST or at least a SHOULD. (If that is not possible, maybe it would be sufficient to include that = precious sentence in the bis document...) Gr=FC=DFe, Carsten From jsontest@yahoo.com Wed Jun 5 13:59:59 2013 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 F39AD21F8E12 for ; Wed, 5 Jun 2013 13:59:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.902 X-Spam-Level: X-Spam-Status: No, score=-0.902 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bDdgE5N3CInU for ; Wed, 5 Jun 2013 13:59:53 -0700 (PDT) Received: from nm12-vm0.bullet.mail.bf1.yahoo.com (nm12-vm0.bullet.mail.bf1.yahoo.com [98.139.213.140]) by ietfa.amsl.com (Postfix) with ESMTP id D832421E804B for ; Wed, 5 Jun 2013 13:59:49 -0700 (PDT) Received: from [98.139.215.140] by nm12.bullet.mail.bf1.yahoo.com with NNFMP; 05 Jun 2013 20:59:49 -0000 Received: from [98.139.213.10] by tm11.bullet.mail.bf1.yahoo.com with NNFMP; 05 Jun 2013 20:59:49 -0000 Received: from [127.0.0.1] by smtp110.mail.bf1.yahoo.com with NNFMP; 05 Jun 2013 20:59:49 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1370465989; bh=kBe96tWO9pZZQ8C1CmMdx7bld90MJLRL1z11WmbvIi8=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:References:In-Reply-To:Mime-Version:Content-Transfer-Encoding:Content-Type:Message-Id:Cc:X-Mailer:From:Subject:Date:To; b=StAZS14uTpwyv1Wt9WI/YQ6uTnmmev7uXzLICQPIaxNP11705ja2R+Iqo7wZ+6jopMvPWQ7lggQHdHjr/nwd0cZxblAyCkw8q4c4IO6M4qH4dBHAPUDzGeGFYfUeesnmSrIg2hkUDFawvQXT75zroukLFJsYDPn5Uxvft2zRdBY= X-Yahoo-Newman-Id: 184469.8512.bm@smtp110.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: aLR8aFsVM1llZEZ0RJ7nlAHeJPDE2EDtA7vNKFgMfhcpgrs .1WZEpY0Eq4rVXrO2eH_hbM8o85lL.V.Cmxo1IHNT0qMm_br09PxDvNRTcgN jZolSW9lWnzSRopjx5a6pooDYf4l.rkv8fTqqsqSdg1.w_aJTkSB20WaQtb6 ZBMd2vFHutXUGe_1KYArjJBWnvtrzESJesdZod9vRpB47Sxr9a0KdNw33GZ4 m7VJVdphLqM58RnA9NwweEnRw0_E0zx2JIr4_YT_CgqFWMM3hcpbg.gOqqO0 A1JM3fSjzmG5SxRPQO2QjIIoSxcACWnJLx.RF_nC8cvEd746ak7pHT.D3ZKi T.m2gYiNsAiaa2kUWo7YaeV9D5Ep6MjYHlg4_zCSTMNankPh7xy.0Q2fS.8d GCuMXDi8rcAIB7I1_HhBfaCRtoe_aKZ_4geRr_Pr86fQ18j7j6PPQHhjhRgm km4Z7b3C.W1NB8zpShCtqCiM5afK6IbUUpkUSfbq_ckLwLL1VqaeVYBibOYM eMfMIpK6YzEpFWWqS_jWLHZdafBPqHdg- X-Yahoo-SMTP: indQcmSswBC8IKsm6t4aCAPskK3T X-Rocket-Received: from [192.168.0.102] (jsontest@76.29.100.42 with ) by smtp110.mail.bf1.yahoo.com with SMTP; 05 Jun 2013 13:59:49 -0700 PDT References: <51AF8479.5080002@crockford.com> <51AF9ACF.5020507@cisco.com> In-Reply-To: <51AF9ACF.5020507@cisco.com> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary=Apple-Mail-1F694060-4B7B-44FA-BFE9-DA2C43BF5964 Message-Id: X-Mailer: iPod Mail (9B206) From: Vinny A Date: Wed, 5 Jun 2013 15:59:45 -0500 To: Eliot Lear Cc: Douglas Crockford , "json@ietf.org" Subject: Re: [Json] The names within an object SHOULD be unique. X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 05 Jun 2013 20:59:59 -0000 --Apple-Mail-1F694060-4B7B-44FA-BFE9-DA2C43BF5964 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jun 5, 2013, at 2:30 PM, Stephan Beal wrote: > It gives implementations leeway on what is essentially a corner case (who a= ctively generates non-unique keys?). Forcing a specific behaviour here could= potentially leave a lot of current 100% JSON-compliant parsers suddenly non= -compliant because of [what i perceive as] an unusual corner case. If parsers are accepting duplicate keys, they're already non-compliant. RFC 4= 627 states that keys should be unique, and the org.json reference parser thr= ows an exception when it hits a duplicate key (line 1186 in JSONObject). If any implementation is relying on using duplicate keys, they should also u= nderstand that they are already violating best practice. On Jun 5, 2013, at 3:08 PM, Eliot Lear wrote: > Demonstrating my age, an old trick we've done that goes back to RFC-1123 > is to say MUST NOT send, and then implementations MAY NOT process, and > if they do MUST process thusly... While I'd prefer to simply state that implementations MUST generate unique k= eys, Mr. Lear's suggestion gets my +1. ----------------- Vinny www.jsontest.com --Apple-Mail-1F694060-4B7B-44FA-BFE9-DA2C43BF5964 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Jun 5, 20= 13, at 2:30 PM, Stephan Beal <sg= beal@googlemail.com> wrote:
It gives implementations l= eeway on what is essentially a corner case (who actively generates non-uniqu= e keys?). Forcing a specific behaviour here could potentially leave a lot of= current 100% JSON-compliant parsers suddenly non-compliant because of [what= i perceive as] an unusual corner case.

If parsers are accepting duplicate keys, they're already non-comp= liant. RFC 4627 states that keys should be unique, and the org.json referenc= e parser throws an exception when it hits a duplicate key (line 1186 in JSON= Object).

If any implementation is relying on using d= uplicate keys, they should also understand that they are already violating b= est practice.

On Jun 5, 2013, at 3:08 PM, Eliot Lear &l= t;lear@cisco.com> wrote:
Demonstrating my age, an old trick we've done that goes back to RFC-= 1123
is to say MUST NOT send, and then implementations MAY N= OT process, and
if they do MUST process thusly...

While I'd prefer to simply state that implemen= tations MUST generate unique keys, Mr. Lear's suggestion gets my +1.

-----------------
Vinny

= = --Apple-Mail-1F694060-4B7B-44FA-BFE9-DA2C43BF5964-- From sgbeal@googlemail.com Wed Jun 5 14:14:37 2013 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 5EE6621E8083 for ; Wed, 5 Jun 2013 14:14:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.677 X-Spam-Level: X-Spam-Status: No, score=-1.677 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Eb8KrjyvDZVy for ; Wed, 5 Jun 2013 14:14:36 -0700 (PDT) Received: from mail-ea0-x22d.google.com (mail-ea0-x22d.google.com [IPv6:2a00:1450:4013:c01::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 7BD1121E8087 for ; Wed, 5 Jun 2013 14:14:36 -0700 (PDT) Received: by mail-ea0-f173.google.com with SMTP id g15so1450556eak.4 for ; Wed, 05 Jun 2013 14:14:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=CdoPCTNneWqIsIyKDf7tsJkscRIGhaFdFkCn+NswueM=; b=ui79g8RigoeWzM+6oTKLFEpIsy8vNC8AjwpVb3HJQkp0tKuaawcTVTc2/lF6IoBdh/ 4EBpUtpHf6CwZL3qDaSSXYju9uSI3rCotC/3EWaSIE/PJvyda7R4roLYLv+xfxATiM0g wzikBGMiqj1UwVFf9KcOm86XLkWaGzb5CtW84y2DFq8WNuyk+9o1R3/0Z2fw1VFdMsYu S49LJ9IDhW6yr4w8A9E7Eh6oFlB+7Y+9lwwF2Wp4rFbHRDbu8fYlI1SQ8k4d83h/7xJt oVmlBkbl/KYIrgV4+E91ZYnsuwnJHu5ya152cFxKMvkI+h0DXGO5HLoIpd3hd6ABkUtW T5Pw== MIME-Version: 1.0 X-Received: by 10.181.12.1 with SMTP id em1mr8556545wid.4.1370466873170; Wed, 05 Jun 2013 14:14:33 -0700 (PDT) Received: by 10.194.42.230 with HTTP; Wed, 5 Jun 2013 14:14:33 -0700 (PDT) In-Reply-To: References: <51AF8479.5080002@crockford.com> <51AF9ACF.5020507@cisco.com> Date: Wed, 5 Jun 2013 23:14:33 +0200 Message-ID: From: Stephan Beal To: "json@ietf.org" Content-Type: multipart/alternative; boundary=f46d043c7e3026e40404de6eafc1 Subject: Re: [Json] The names within an object SHOULD be unique. X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 05 Jun 2013 21:14:37 -0000 --f46d043c7e3026e40404de6eafc1 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Jun 5, 2013 at 10:59 PM, Vinny A wrote: > If parsers are accepting duplicate keys, they're already non-compliant. > RFC 4627 states that keys should be unique, and the org.json reference > parser throws an exception when it hits a duplicate key (line 1186 in > JSONObject). > (Sorry, Vinny - gmail is giving me all kinds of grief with the list replies.) "should" is not "must" :/. > If any implementation is relying on using duplicate keys, they should also > understand that they are already violating best practice. > Absolutely. > While I'd prefer to simply state that implementations MUST generate unique > keys, Mr. Lear's suggestion gets my +1. > But that only solves the generator side of the equation, and that solution would imply that the parser also MUST NOT parse them (because they "can't" be generated, so why bother?), regardless of best/worse-practice. i.e. it would force changes onto existing parsers if they want to be officially compliant. Maybe i'm nit-picking, but that point could certainly disappoint some people who would have to re-label their implementations as "JSON comp^H^H^H^Halmost-compliant". --f46d043c7e3026e40404de6eafc1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Jun 5, 2013 at 10:59 PM, V= inny A=A0<jsontest@yahoo.com>=A0wrote:
If parsers are accepting duplicate keys, they'= re already non-compliant. RFC 4627 states that keys should be unique, and t= he org.json reference parser throws an exception when it hits a duplicate k= ey (line 1186 in JSONObject).

(Sorry, Vinny - gmail is givin= g me all kinds of grief with the list replies.)

<= div>"should" is not "must" :/.=A0
=A0
If = any implementation is relying on using duplicate keys, they should also und= erstand that they are already violating best practice.

Absolutely.
=A0
While I'd = prefer to simply state that implementations MUST generate unique keys, Mr. = Lear's suggestion gets my +1.

<= /div>
But that only solves the generator side of the equation, and that solu= tion would imply that the parser also MUST NOT parse them (because they &qu= ot;can't" be generated, so why bother?), regardless of best/worse-= practice. i.e. it would force changes onto existing parsers if they want to= be officially compliant. Maybe i'm nit-picking, but that point could c= ertainly disappoint some people who would have to re-label their implementa= tions as "JSON comp^H^H^H^Halmost-compliant".
--f46d043c7e3026e40404de6eafc1-- From cromis@gmail.com Wed Jun 5 14:16:48 2013 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 4E86321F963F for ; Wed, 5 Jun 2013 14:16:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.191 X-Spam-Level: X-Spam-Status: No, score=-2.191 tagged_above=-999 required=5 tests=[AWL=-0.285, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_SXLIFE=1.07] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mLK7RvL7Zubr for ; Wed, 5 Jun 2013 14:16:43 -0700 (PDT) Received: from mail-qe0-f44.google.com (mail-qe0-f44.google.com [209.85.128.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0F62721F9263 for ; Wed, 5 Jun 2013 14:16:42 -0700 (PDT) Received: by mail-qe0-f44.google.com with SMTP id 6so1424376qeb.31 for ; Wed, 05 Jun 2013 14:16:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:content-type; bh=ruOuxo6YeaTTpHES2xJJwq1VD7dg68TvfSA7zXky290=; b=0dw3pUBbkUzoRjTeQBz4M4pupWA5IuboQ+eLVHUxix12MS6P49jn6Vy/9vBi2dErC1 /e69tmAXWI+X2yDkymUzSJtH3NnSQZOpV47dYSdYWJoQ8r1ihOzd56lQHCwFSO5kn8mA 8s7XQfaFPuMHXvPrempgyT5YqB+1jIe2KYkerNBWkGLVXyirFGPqi9T1V8A0/RjSbDry hwk7Za5utnCnoBbU5u0fdh1wWKKyVwACodiRqww4S6y94iZ1LDO3W+AB85r7Dy0JLB3T F6AOYBDh1r80mFjKNo9ZJJKH58Q0+4wiiBtBR0AdI/4OpygCHoN50WhpBwZlPvLccu0I XBsw== X-Received: by 10.224.177.201 with SMTP id bj9mr9495087qab.14.1370467002258; Wed, 05 Jun 2013 14:16:42 -0700 (PDT) MIME-Version: 1.0 Sender: cromis@gmail.com Received: by 10.49.106.228 with HTTP; Wed, 5 Jun 2013 14:16:21 -0700 (PDT) In-Reply-To: References: <51AF8575.5060706@crockford.com> From: Jacob Davies Date: Wed, 5 Jun 2013 14:16:21 -0700 X-Google-Sender-Auth: vbKLAKYy_dsgOQSO0AguK-oLUVA Message-ID: To: "json@ietf.org" Content-Type: multipart/alternative; boundary=20cf303b39f1d8d9f004de6eb66f Subject: Re: [Json] Encoding X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 05 Jun 2013 21:16:48 -0000 --20cf303b39f1d8d9f004de6eb66f Content-Type: text/plain; charset=ISO-8859-1 On Wed, Jun 5, 2013 at 1:18 PM, Tatu Saloranta wrote: > Allowing character encodings other than existing ones (UTF-8/16/32) would be a breaking change -- compliant libraries currently can count on simple and reliable auto-detection -- and I can not see how use of other encodings (except for special case of ASCII, as that simply falls within UTF-8 umbrella) would be considered compliant currently. The point is that the entire discussion of encoding is irrelevant other than assuming UTF-8 if no encoding is specified. The language should not be concerned with the binary representation of the characters it is written. I can write a perfectly valid JSON text on paper with a pen, including non-ASCII Unicode characters in a string. Am I a non-compliant implementation? I think you can simply talk about JSON as a language consisting of a series of characters drawn from the basic JSON alphabet, except inside quoted string values that may not contain a small set of whitespace and control characters, but may contain other literal characters. Reading a JSON text produces a model containing nulls, booleans, numbers (of unspecified representation), Unicode strings, arrays, and objects. Worrying about whether the input text contained the literal bytes f09f98bf instead of d83dde3f or a hand-drawn crying cat face on paper isn't necessary (and irrelevant in those environments where the encoding is interpreted at a level below that of JSON parsing). I do not believe it has any effect on compliance or interoperability since there is no existing requirement that all encodings or all possible documents be accepted. (I doubt many implementations handle UTF-32 in the absence of an external encoding specification, for instance.) All that the current wording on encoding winds up saying is that a bunch of potentially useful things that unambiguously work are not compliant (e.g. two parties agreeing to put JSON in EBCDIC text columns in DB2 as long as they escape everything outside the basic JSON alphabet). The requirement that you assume UTF-8 unless you have agreed on another encoding by some external channel should be enough to unambiguously interpret any series of bytes that claims to be JSON without an encoding specified. If you agree on some other binary encoding with your partner, that's not the business of the specification. --20cf303b39f1d8d9f004de6eb66f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Jun 5, 2013 at 1:18 PM, Tatu Saloranta <tsaloranta@gmail.com> wrote:
>= ; Allowing character encodings other than existing ones (UTF-8/16/32) would= be a breaking change -- compliant libraries currently can count on simple = and reliable auto-detection -- and I can not see how use of other encodings= (except for special case of ASCII, as that simply falls within UTF-8 umbre= lla) would be considered compliant currently.

The point is that the entire discussion of encoding is irrelevant other= than assuming UTF-8 if no encoding is specified. The language should not b= e concerned with the binary representation of the characters it is written.= I can write a perfectly valid JSON text on paper with a pen, including non= -ASCII Unicode characters in a string. Am I a non-compliant implementation?=

I think you can simply talk about JSON as a language consisting of a se= ries of characters drawn from the basic JSON alphabet, except inside quoted= string values that may not contain a small set of whitespace and control c= haracters, but may contain other literal characters. Reading a JSON text pr= oduces a model containing nulls, booleans, numbers (of unspecified represen= tation), Unicode strings, arrays, and objects. Worrying about whether the i= nput text contained the literal bytes f09f98bf instead of d83dde3f or a han= d-drawn crying cat face on paper isn't necessary (and irrelevant in tho= se environments where the encoding is interpreted at a level below that of = JSON parsing).

I do not believe it has any effect on compliance = or interoperability since there is no existing requirement that all encodin= gs or all possible documents be accepted. (I doubt many implementations han= dle UTF-32 in the absence of an external encoding specification, for instan= ce.) All that the current wording on encoding winds up saying is that a bun= ch of potentially useful things that unambiguously work are not compliant (= e.g. two parties agreeing to put JSON in EBCDIC text columns in DB2 as long= as they escape everything outside the basic JSON alphabet).

The requirement that you assume UTF-8 unles= s you have agreed on another encoding by some external channel should be en= ough to unambiguously interpret any series of bytes that claims to be JSON = without an encoding specified. If you agree on some other binary encoding w= ith your partner, that's not the business of the specification.
--20cf303b39f1d8d9f004de6eb66f-- From douglas@crockford.com Wed Jun 5 14:30:06 2013 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 0849A21F921F for ; Wed, 5 Jun 2013 14:30:02 -0700 (PDT) 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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZTtKyGpcTyvN for ; Wed, 5 Jun 2013 14:29:45 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id CAD5711E80AE for ; Wed, 5 Jun 2013 14:29:44 -0700 (PDT) Received: from [192.168.114.223] ([216.113.168.135]) by mrelay.perfora.net (node=mrus4) with ESMTP (Nemesis) id 0Mhi4R-1V5bQ83Xal-00MRh0; Wed, 05 Jun 2013 17:29:42 -0400 Message-ID: <51AFADBA.9070405@crockford.com> Date: Wed, 05 Jun 2013 14:29:30 -0700 From: Douglas Crockford User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Markus Lanthaler References: <51AF9D4C.5060403@crockford.com> <043d01ce622d$1e002760$5a007620$@lanthaler@gmx.net> In-Reply-To: <043d01ce622d$1e002760$5a007620$@lanthaler@gmx.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V02:K0:dFMjzF+E5PDgU/7ES8vlfF/323N56UmFFZMDf3DlezY wbBixylJAnbN7UloAmJs+0Jqz3u+aBJnfGDKitNOh0bmglfunO bRV/fwqm/Cm2zmqH6D896XnzLvWpXZET1cS59tcsT5dtk9ZGXW YE/oMgBGE780+qP4EWMR/S/zoMRNLVANYSG0j6wBiG8/CxVeP2 Bo4J18NMio787WCI+hxk2Ise2phPj1OP3cm7XGR1vkzzQcoBLV Zr23nQUphpzXwbWWP+/hRbn8KH9xhzosxCnyBYX8+UGSqr7Qzc vQ5osmiQY3c491P/w1RSnuACc7kvVq60oENiZYigc+xOzJiNdu FPCSh74Erzuz2tT/9VqB3/mEr2pp4vHTUivJ5WeP0 Cc: json@ietf.org Subject: Re: [Json] Strings X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 05 Jun 2013 21:30:06 -0000 On 6/5/2013 1:41 PM, Markus Lanthaler wrote: > On Wednesday, June 05, 2013 10:19 PM, Douglas Crockford wrote: >> It should say explicitly that these three all produce exactly the same >> result: >> >> "\u002F" >> "\/" >> "/" >> >> I have seen confusion about this. > Me too. By default, PHP e.g. serializes a "/" to "\/". I'm wondering whether > it would make sense to recommend that serializers use "/"? > PHP does that because it usually generates HTML. If you embed JSON on HTML, then it is sometimes necessary to escape /, so that strings like "" don't cause disaster. Strings like "<\/script>" are safe. PHP could be smarter about how it does that, but it is not my job to tell PHP how to be smarter. From sgbeal@googlemail.com Wed Jun 5 14:33:22 2013 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 F273611E80BA for ; Wed, 5 Jun 2013 14:33:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.181 X-Spam-Level: X-Spam-Status: No, score=-1.181 tagged_above=-999 required=5 tests=[AWL=-0.496, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MISSING_HEADERS=1.292, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YoRJ8NPy5X5r for ; Wed, 5 Jun 2013 14:33:20 -0700 (PDT) Received: from mail-ea0-x22a.google.com (mail-ea0-x22a.google.com [IPv6:2a00:1450:4013:c01::22a]) by ietfa.amsl.com (Postfix) with ESMTP id D5A3D21F99C7 for ; Wed, 5 Jun 2013 14:33:18 -0700 (PDT) Received: by mail-ea0-f170.google.com with SMTP id h10so1616525eaj.29 for ; Wed, 05 Jun 2013 14:33:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:cc :content-type; bh=fVKyWLOjjrVs4xBqT7a1x9nSHMLzzl07FzgXilRwbdA=; b=yJsoskDk1HDdzW0OGsJOETIvro9uynEiDBzcDzC1vhIqENR6qmmRWTj4CmvjptBnvj EiJrGIr+7CcZKA8e6xjFLHCDR0839dl7tzbX3UnHhqT4z6blsEHX4AoPK3SWfSpdGsaB i5x+Q9qOmLzlLrYTYlKkbfXe3li4uwRrAs8L/48Tb6UqDsf8mQVuKYaM1wuk7WeT5yU5 kvYYdUnODQp6YvFXCT1ExhU3SjT+KEGuP3Q3PTwTY3J8ieDj+rHXLMWTzZ+7UXriL+Hi UiaKBQ7ltnnzMhI6Ut0LgFxPH+5HMYpOftC1wwXfDN0f6MlbKwqPvOMj/wHXsavCIkeS 0+kw== MIME-Version: 1.0 X-Received: by 10.181.12.1 with SMTP id em1mr8569049wid.4.1370467997816; Wed, 05 Jun 2013 14:33:17 -0700 (PDT) Received: by 10.194.42.230 with HTTP; Wed, 5 Jun 2013 14:33:17 -0700 (PDT) In-Reply-To: <51AFADBA.9070405@crockford.com> References: <51AF9D4C.5060403@crockford.com> <51AFADBA.9070405@crockford.com> Date: Wed, 5 Jun 2013 23:33:17 +0200 Message-ID: From: Stephan Beal Cc: "json@ietf.org" Content-Type: multipart/alternative; boundary=f46d043c7e302f9c9504de6ef2f3 Subject: Re: [Json] Strings X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 05 Jun 2013 21:33:22 -0000 --f46d043c7e302f9c9504de6ef2f3 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Jun 5, 2013 at 11:29 PM, Douglas Crockford wrote: > Strings like "<\/script>" are safe. PHP could be smarter about how it does > that, but it is not my job to tell PHP how to be smarter. > They recently (5.4) added a flag to disable that: http://php.net/manual/de/function.json-encode.php See JSON_UNESCAPED_SLASHES. -- ----- stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal --f46d043c7e302f9c9504de6ef2f3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Jun 5, 2013 at 11:29 PM, Douglas Crockford <d= ouglas@crockford.com> wrote:
Stri= ngs like "<\/script>" are safe. PHP could be smarter about = how it does that, but it is not my job to tell PHP how to be smarter.

They recently (5.4) added a flag to = disable that:


See JSON_UNESCAPED_SLASHES.
--f46d043c7e302f9c9504de6ef2f3-- From douglas@crockford.com Wed Jun 5 14:56:29 2013 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 DA52721F8B35 for ; Wed, 5 Jun 2013 14:56:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_34=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SeKVQYE64D5F for ; Wed, 5 Jun 2013 14:56:23 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id 9F7DD21F8CB5 for ; Wed, 5 Jun 2013 14:56:22 -0700 (PDT) Received: from [192.168.114.223] ([216.113.168.135]) by mrelay.perfora.net (node=mrus3) with ESMTP (Nemesis) id 0LvVEJ-1UJ1iE0zGF-00zq9s; Wed, 05 Jun 2013 17:56:21 -0400 Message-ID: <51AFB3F8.8060708@crockford.com> Date: Wed, 05 Jun 2013 14:56:08 -0700 From: Douglas Crockford User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Vinny A References: <51AF8479.5080002@crockford.com> <51AF9ACF.5020507@cisco.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V02:K0:DGn+WcFvzwVBBUFZsMOnNxVuBuwN5MANBqqjPoheHMr aSYMK3UF0MsUXewtjvx536smcOyeTbWiQULF3K3QSHYZN/7Ehr PzGbyteJs2b2DrsHOPGezxQDgLMkzN5QXsbK7qazfsRkJ3fc3H qX1S53xf+E98pfybAK8rlCkC0QgDd7j0+Xnj76crBCrDhZ5ajd izNnjSc3vWLMPXgcsz2v8HPFK5x4jGd8a+j2bPvHK/Kfe6vuy5 WKICdnUfiy/LzoJKfqVmwLlPwzk/hKFaszutnIRD2HHFWPrDsM LtxQs3h8PI9I38JdFi1gawWKn41gHREqAQfjAQH0wlDP8y8uHC RAogGQCP5ZEiVRqt0KjMjA5aaYtQ+Wzjex8TJUryc Cc: Eliot Lear , "json@ietf.org" Subject: Re: [Json] The names within an object SHOULD be unique. X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 05 Jun 2013 21:56:29 -0000 On 6/5/2013 1:59 PM, Vinny A wrote: > > On Jun 5, 2013, at 2:30 PM, Stephan Beal > wrote: >> It gives implementations leeway on what is essentially a corner case >> (who actively generates non-unique keys?). Forcing a specific >> behaviour here could potentially leave a lot of current 100% >> JSON-compliant parsers suddenly non-compliant because of [what i >> perceive as] an unusual corner case. > > If parsers are accepting duplicate keys, they're already > non-compliant. RFC 4627 states that keys should be unique, and the > org.json reference parser throws an exception when it hits a duplicate > key (line 1186 in JSONObject). > > If any implementation is relying on using duplicate keys, they should > also understand that they are already violating best practice. There are people who interpreted the SHOULD as DON'T HAVE TO and intentionally duplicated the keys. My personal feeling is that we should change the SHOULD to MUST and let those applications break. But the consensus of ECMA TC39 is that the SHOULD must stand. So regrettably, that means we should be explicit about what happens when this particular bad practice is practiced. From jsontest@yahoo.com Wed Jun 5 14:59:33 2013 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 BD1A421F966B for ; Wed, 5 Jun 2013 14:59:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.398 X-Spam-Level: * X-Spam-Status: No, score=1.398 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qO2qjlwh7S-v for ; Wed, 5 Jun 2013 14:59:28 -0700 (PDT) Received: from nm13.bullet.mail.ne1.yahoo.com (nm13.bullet.mail.ne1.yahoo.com [98.138.90.76]) by ietfa.amsl.com (Postfix) with ESMTP id D9BD821F9634 for ; Wed, 5 Jun 2013 14:59:27 -0700 (PDT) Received: from [98.138.90.54] by nm13.bullet.mail.ne1.yahoo.com with NNFMP; 05 Jun 2013 21:59:26 -0000 Received: from [98.138.226.57] by tm7.bullet.mail.ne1.yahoo.com with NNFMP; 05 Jun 2013 21:59:26 -0000 Received: from [127.0.0.1] by smtp208.mail.ne1.yahoo.com with NNFMP; 05 Jun 2013 21:59:26 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1370469566; bh=rdEKVPNqBoOkBvkyXgN32Q2Apk8M9odd2J1ylO051gY=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:References:In-Reply-To:Mime-Version:Content-Transfer-Encoding:Content-Type:Message-Id:Cc:X-Mailer:From:Subject:Date:To; b=hUw3nM/97AEK6DwsqxZcyJ6QNk0vWhYvr47hslrqXEQkbj1/bclUYRnLUQ1dWAI8d0yU0JOnKXYnxdwpiD/s6d/P2D5sGiOUCHo9WBA8Fk3/BM8a6O8Y79WiOjHUacNPKLr7LDkr3en88DMZOoF7k7NKdmmpw4quMPJStm1xRx4= X-Yahoo-Newman-Id: 927721.60022.bm@smtp208.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: sBUjzAoVM1nTJPnBOOiL_FjiCOsgCaNmgFWJroNu0BTyiV3 V9ZKbJKpsSgK9xrW.PYRtHnkUjve78pmPtaYNGbHjisTM25sXcU3EQc5vkgV WFgmRWY49Z44hO8PbHSmgb_F66anbsknU.321PLcnQfk5BTZ7XZglxx6Zvbz kpOd6Vk2qJiiRzb3qPXqiQjeBQgX5xgQDrgQIYrOIFcoZz.K9Qn.T1xLqjR8 BVIHD5b4TIQ1S0WFEuP9dITRsqWs7_4q7n0nYuLphGsSnx0ohXeB7HzWJEau cWLk6x3AJ__e9ddNWaeE_QQSFvSZCbk4btNq3Tt.U_3EQC4qPtHiGbDeNJTI knK2jL86CE4_Vq.eXq2sMQd5ATxGvsYZFI1deoxz5pkkSXxnFtSRE9wj.BRH Ny7c7aLf57Khhbq3E13N5mFWu4WJnM0eiMc1qJ.a73dmhCDpApzfWxiHa2xb nHspb4POIKUVtrApBH7hZwi427kQLBYySHnjLGEfO.D2xmuw1c._stzPSFEE Y4210C6qMvuM.iUuN4EXZ6pEZ0GH_STY- X-Yahoo-SMTP: indQcmSswBC8IKsm6t4aCAPskK3T X-Rocket-Received: from [192.168.0.102] (jsontest@76.29.100.42 with ) by smtp208.mail.ne1.yahoo.com with SMTP; 05 Jun 2013 14:59:26 -0700 PDT References: <51AF8479.5080002@crockford.com> <51AF9ACF.5020507@cisco.com> In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary=Apple-Mail-B9D5D400-209F-42C9-9048-5CF3AEF6465C Message-Id: <673D38D7-6AB9-4EFF-B176-302063CF5A4C@yahoo.com> X-Mailer: iPod Mail (9B206) From: Vinny A Date: Wed, 5 Jun 2013 16:59:22 -0500 To: Stephan Beal Cc: "json@ietf.org" Subject: Re: [Json] The names within an object SHOULD be unique. X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 05 Jun 2013 21:59:33 -0000 --Apple-Mail-B9D5D400-209F-42C9-9048-5CF3AEF6465C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jun 5, 2013, at 4:14 PM, Stephan Beal wrote: > Maybe i'm nit-picking, but that point could certainly disappoint some peop= le who would have to re-label their implementations as "JSON comp^H^H^H^Halm= ost-compliant". I don't think you're nit picking. You bring up a very valid concern. With th= at said, any choice made is going to disappoint someone out there. JSON implementations vary wildly in how they deal with duplicate keys (rejec= ting them, first key only, last key only, transforming duplicated keys into a= n array) and it gets rather tiresome after a while. Any choice that this mai= ling list makes is going to break something, but it'll be an improvement for= future interoperability. Frankly the actual choice is irrelevant - there ar= e pros/cons to all 4 choices - interop is what matters. Delaying this discussion until bis document writing is also a good idea. On Jun 5, 2013, at 4:14 PM, Stephan Beal wrote: > (Sorry, Vinny - gmail is giving me all kinds of grief with the list replie= s.) >=20 OT: No worries. Yahoo mail is also having difficulty with this list - some e= mails are getting marked as spam by Yahoo's filters. ----------------- Vinny www.jsontest.com= --Apple-Mail-B9D5D400-209F-42C9-9048-5CF3AEF6465C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Jun 5, 2013, a= t 4:14 PM, Stephan Beal <sgbeal@= googlemail.com> wrote:
=
Mayb= e i'm nit-picking, but that point could certainly d= isappoint some people who would have to re-label their implementations as "J= SON comp^H^H^H^Halmost-compliant".

I don't think you're nit picking. You bring up a= very valid concern. With that said, any choice made is going to disappoint s= omeone out there.

JSON implementations vary wildly i= n how they deal with duplicate keys (rejecting them, first key only, last ke= y only, transforming duplicated keys into an array) and it gets rather tires= ome after a while. Any choice that this mailing list makes is going to break= something, but it'll be an improvement for future interoperability. Frankly= the actual choice is irrelevant - there are pros/cons to all 4 choices - in= terop is what matters.

Delaying this discussion unt= il bis document writing is also a good idea.

On Jun 5, 2= 013, at 4:14 PM, Stephan Beal <s= gbeal@googlemail.com> wrote:
(Sorry, Vinny - gmail is giving me all kinds of gri= ef with the list replies.)


OT: No worries. Yahoo mail is also h= aving difficulty with this list - some emails are getting marked as spam by Y= ahoo's filters.

-----------------
Vinny
= --Apple-Mail-B9D5D400-209F-42C9-9048-5CF3AEF6465C-- From jsontest@yahoo.com Wed Jun 5 15:47:15 2013 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 E69CB21F9648 for ; Wed, 5 Jun 2013 15:47:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.257 X-Spam-Level: * X-Spam-Status: No, score=1.257 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HTML_MESSAGE=0.001, J_CHICKENPOX_35=0.6, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aiMtr1oIjKMn for ; Wed, 5 Jun 2013 15:47:10 -0700 (PDT) Received: from nm29-vm1.bullet.mail.bf1.yahoo.com (nm29-vm1.bullet.mail.bf1.yahoo.com [98.139.213.144]) by ietfa.amsl.com (Postfix) with ESMTP id C2F9E21F9622 for ; Wed, 5 Jun 2013 15:47:09 -0700 (PDT) Received: from [98.139.215.142] by nm29.bullet.mail.bf1.yahoo.com with NNFMP; 05 Jun 2013 22:46:45 -0000 Received: from [98.139.213.7] by tm13.bullet.mail.bf1.yahoo.com with NNFMP; 05 Jun 2013 22:46:45 -0000 Received: from [127.0.0.1] by smtp107.mail.bf1.yahoo.com with NNFMP; 05 Jun 2013 22:46:45 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1370472405; bh=pHJ+54SXV8GVWHkOIc2Mp9n1DPySkdR0lM8EDytv9F8=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:References:In-Reply-To:Mime-Version:Content-Type:Received:Message-Id:Content-Transfer-Encoding:Cc:X-Mailer:From:Subject:Content-Length:Date:To; b=zs5Jff8DJfPVWnLZG06ZW2asPsfG8e3E7JZcaHYjvnVX1fTNPbU4LsgDHSJFGxSA07ycRTgKxon2a/JCLqjTWMZ8KXWDPIM3NlIyd+jklhWWbNjwO6PG7stMMKF0opT171w3BgK+9E2nd7YgQ9xNqa15Hrgmtk3HWTx8hSZvB/k= X-Yahoo-Newman-Id: 196080.81713.bm@smtp107.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: yQ81ADgVM1mS4Myb4782olmBNtOtQPwm94dBsdgiwN.20K7 merVWK_vZswsF8LZcIl7ZuPVwwOCF1.nYjeuuqDLK2bmBzdeIDNLs6jAH6r2 RIlxFfS0vn4uCCbXloJ_Q7dh1KZkQmftH73xScZ48plVRz76UQz7SEbU95ry 5oI6TLsNsx..Pe6uDARt.nudXphMU7MKfvQ0BMrRx5u9fbzGEZlRwfSL6W8z SxpGOoZV1iMpVVSJFx5.2vSW0aUxsYzNnXoqeUGhqyjiz40bAt_qJs69suMh mrDNvTwsxEVceMK2lh5gYnGfkuL1H6paOSJn7exdXhJ6JFfKqcK.T9zgxMzy P7euoe_P2Ppsg8YfvtpT1_1nub4VTWCU1wKWSg23E6TmUHzq2unXl4_vrlyS nyvRQRtw.USELFQlKapNPWc4DPM4ocMLmb_Wg0Ltiy_zdWVtSS85JcyoYm_7 cLnDiGIChW.jWg26UIcUT7MwgniKlwW2zdRO0KBcY9.Hr0e.oikrzDoSGm0H 8lUdfop.G X-Yahoo-SMTP: indQcmSswBC8IKsm6t4aCAPskK3T X-Rocket-Received: from [192.168.0.102] (jsontest@76.29.100.42 with ) by smtp107.mail.bf1.yahoo.com with SMTP; 05 Jun 2013 15:46:44 -0700 PDT References: <51AF8479.5080002@crockford.com> <51AF9ACF.5020507@cisco.com> <51AFB3F8.8060708@crockford.com> <8F32953C-C788-4DC9-888E-920E2BEB7FDD@yahoo.com> In-Reply-To: <8F32953C-C788-4DC9-888E-920E2BEB7FDD@yahoo.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=Apple-Mail-7E7FE867-5679-4F22-8F7A-017C3D12A7F5 Received: from [76.29.100.42] by web125606.mail.ne1.yahoo.com via HTTP; Wed, 05 Jun 2013 15:45:08 PDT Message-Id: <831B8E46-F239-4353-8F95-8DF3F9BD2E78@yahoo.com> Content-Transfer-Encoding: 7bit X-Mailer: iPod Mail (9B206) From: Vinny A Date: Wed, 5 Jun 2013 17:46:42 -0500 To: Douglas Crockford Cc: Eliot Lear , "json@ietf.org" Subject: Re: [Json] The names within an object SHOULD be unique. X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 05 Jun 2013 22:47:16 -0000 --Apple-Mail-7E7FE867-5679-4F22-8F7A-017C3D12A7F5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jun 5, 2013, at 4:56 PM, Douglas Crockford wrote:= > There are people who interpreted the SHOULD as DON'T HAVE TO and intention= ally duplicated the keys. My personal feeling is that we should change the S= HOULD to MUST and let those applications break. But the consensus of ECMA TC= 39 is that the SHOULD must stand. My personal opinion echoes yours. I understand ECMA's consensus though. On Jun 5, 2013, at 4:56 PM, Douglas Crockford wrote:= > So regrettably, that means we should be explicit about what happens when t= his particular bad practice is practiced. Do we need to add this to the draft? As in (not proposing this, but as fodde= r for discussion): "The names within an object SHOULD be unique. If duplicat= e names are encountered, the last key:value pair MUST be used." ----------------- Vinny www.jsontest.com --Apple-Mail-7E7FE867-5679-4F22-8F7A-017C3D12A7F5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Jun 5, 2013, a= t 4:56 PM, Douglas Crockford <= douglas@crockford.com> wrote:
> There are people who interpreted the SHOULD as DON'T HAVE TO and inten= tionally duplicated the keys. My personal feeling is that we should change t= he SHOULD to MUST and let those applications break. But the consensus of ECM= A TC39 is that the SHOULD must stand.

My personal opinion echoes yours.= I understand ECMA's consensus though.

On Jun 5, 2013, at 4:56 PM, Douglas Crockford <douglas@crockford.com> wrote:
> So regrettably, that means we should be explic= it about what happens when this particular bad practice is practiced.

Do w= e need to add this to the draft? As in (not proposing this, but as fodder fo= r discussion): "The names within an object SHOULD be unique. If duplicate names are= encountered, the last key:value pair MUST be used."

-----------------
Vinny
www.jsontest.com
= --Apple-Mail-7E7FE867-5679-4F22-8F7A-017C3D12A7F5-- From nico@cryptonector.com Wed Jun 5 16:17:56 2013 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 C361621E804E for ; Wed, 5 Jun 2013 16:17:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.606 X-Spam-Level: X-Spam-Status: No, score=-1.606 tagged_above=-999 required=5 tests=[AWL=-0.229, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_34=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BxvQunYmE8SM for ; Wed, 5 Jun 2013 16:17:42 -0700 (PDT) Received: from homiemail-a32.g.dreamhost.com (caiajhbdccah.dreamhost.com [208.97.132.207]) by ietfa.amsl.com (Postfix) with ESMTP id 8086F21F8C1A for ; Wed, 5 Jun 2013 16:17:42 -0700 (PDT) Received: from homiemail-a32.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a32.g.dreamhost.com (Postfix) with ESMTP id 7EB8058406F for ; Wed, 5 Jun 2013 16:16:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=XTlFCUYTDr+ANAn43jvl KVDbTjE=; b=aduaNXNk+gmHfNzhWz7AYTejZG/5YTLUCgj0ExfQ2U7jPE7k/OGA GuWKEldCrGcx+Znj5cY/eFX2JzSK+o+n6Ab3SmQrNtgAMWRfMNRWfdfJNlu6S4LZ zUBVXrBPrCuk3RKzxZHvKgRkr5KplGm0leMODm6pzDpGTKQI2O+8giU= Received: from mail-ea0-f182.google.com (mail-ea0-f182.google.com [209.85.215.182]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a32.g.dreamhost.com (Postfix) with ESMTPSA id 262C658406A for ; Wed, 5 Jun 2013 16:16:56 -0700 (PDT) Received: by mail-ea0-f182.google.com with SMTP id r16so1800979ead.41 for ; Wed, 05 Jun 2013 16:16:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=0qjXSAy99zYFDpVR7+Bga0iT8JtgO6vtWUyPA/RYC54=; b=Q57Js6mLcfiRDgK0ZafgFiwnjjjX9k/ZsCKpu5cuE3e1dwU/cs63qPAGrqZE5bKYBX cSEezXt+I3gBKmIwEN6/eB4pnqTQEJccK0OKTVlNfrn7uiPstaNSY7vhYI1CmmJXr5TA 24VA1jxKFIsDPTGg4NK3Ra48Ib+L3W/BXEoNU+S4U4svuE0rokwdXLmkvmfG9Hz1tanp BymzuC5GHH3SJ10/iVG8lYFO3vY4GXybwdn4xX6spqIIXXxqxNtMSqUejRjw6zy/vrC+ TfBjXdI4faTFM2C0zjKjbauOehGkTOYjUs80rTNxxEK59TodFSDkuJmTSFT/uQ9AJUvo ZzVg== MIME-Version: 1.0 X-Received: by 10.194.77.66 with SMTP id q2mr30849458wjw.34.1370474215504; Wed, 05 Jun 2013 16:16:55 -0700 (PDT) Received: by 10.216.63.136 with HTTP; Wed, 5 Jun 2013 16:16:55 -0700 (PDT) In-Reply-To: References: <51AF8479.5080002@crockford.com> <51AF9ACF.5020507@cisco.com> Date: Wed, 5 Jun 2013 18:16:55 -0500 Message-ID: From: Nico Williams To: Vinny A Content-Type: text/plain; charset=UTF-8 Cc: Douglas Crockford , Eliot Lear , "json@ietf.org" Subject: Re: [Json] The names within an object SHOULD be unique. X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 05 Jun 2013 23:17:57 -0000 On Wed, Jun 5, 2013 at 3:59 PM, Vinny A wrote: > If parsers are accepting duplicate keys, they're already non-compliant. RFC > 4627 states that keys should be unique, and the org.json reference parser > throws an exception when it hits a duplicate key (line 1186 in JSONObject). Not clear. The RFC uses a passive voice here, not placing a requirement (or, rather, recommendation) on either the encoder nor the parser. It seems more reasonable to read it as a recommendation for encoders than one for parsers. I note that the words "reject", "fail", and "error" don't appear in the RFC, lending even more weight, I think to the interpretation that this SHOULD applies to encoders. Perhaps that should be an action item here: change from passive voice to active as much as possible, with discussion of why some ambiguity (like this one) is left in, if it is. Nico -- From nico@cryptonector.com Wed Jun 5 16:20:25 2013 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 6727C21F882A for ; Wed, 5 Jun 2013 16:20:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.877 X-Spam-Level: X-Spam-Status: No, score=-1.877 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NcRtJgSr3RQZ for ; Wed, 5 Jun 2013 16:20:20 -0700 (PDT) Received: from homiemail-a32.g.dreamhost.com (caiajhbdcbef.dreamhost.com [208.97.132.145]) by ietfa.amsl.com (Postfix) with ESMTP id 2134021F9476 for ; Wed, 5 Jun 2013 16:20:20 -0700 (PDT) Received: from homiemail-a32.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a32.g.dreamhost.com (Postfix) with ESMTP id 4BF48584065 for ; Wed, 5 Jun 2013 16:19:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=A2czOEtMU1KLlylnEuwq H0Hwdqs=; b=MCFmS3RliGnFNMERDmlaWs2SmgHmNXi8emUX7KkyfrdwVYR5+b+t YSFKTm1mq93mFm+Rg4CAzU9Wjpgz/enm9Dq7QxGo/AqVEEoTxsBe3fHFnQRiwdFm k/R+xCZm9pNMYOCJnICe/goGbCOdzEmmggaz/1CUtEPAqNQX2eKtxd8= Received: from mail-ea0-f181.google.com (mail-ea0-f181.google.com [209.85.215.181]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a32.g.dreamhost.com (Postfix) with ESMTPSA id E777E584064 for ; Wed, 5 Jun 2013 16:19:42 -0700 (PDT) Received: by mail-ea0-f181.google.com with SMTP id a11so1871576eae.40 for ; Wed, 05 Jun 2013 16:19:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ozBl1pIFDDhBX3vEYVL1bIlM5OqOOBSZeTCAWUZ1GXI=; b=DfOBMqvRqNCVmyGJfmFbMtjQOV0F6P0jJCM6VOwTDy1jJtK7qOVXLy1edpOgNYBWF0 UMLxMCahUf0Qx6QlPsLC+oM4HSzYo1/KyNeyv39deECsk4mIwvy5Ijp2Tvq2rpxbWikx jb7n15loJ8eZrZCEIdSLMhzgA19NrQIRVq7cD8OZJOTY+nrRJkNlHVvHd4euWc9sue6k TIHBsjDYe9THmYsIq1X6U+At0AJ/rAHqAESBCjlhSlYq/ypR1eIYutckDd7pem25XFIE xtqD91+cnDx/Q1skN1/25AApqt7+AAUVg1EXFJj+0p4Qu4MWvQCfEfOGEwUg2/t2GsHI 69iw== MIME-Version: 1.0 X-Received: by 10.180.107.35 with SMTP id gz3mr8532730wib.0.1370474381695; Wed, 05 Jun 2013 16:19:41 -0700 (PDT) Received: by 10.216.63.136 with HTTP; Wed, 5 Jun 2013 16:19:41 -0700 (PDT) In-Reply-To: <51afa4ff.89e9420a.6d90.212fSMTPIN_ADDED_BROKEN@mx.google.com> References: <51AF8479.5080002@crockford.com> <51AF8A9B.1020900@crockford.com> <51af8f23.85f8420a.597e.0ccbSMTPIN_ADDED_BROKEN@mx.google.com> <51afa4ff.89e9420a.6d90.212fSMTPIN_ADDED_BROKEN@mx.google.com> Date: Wed, 5 Jun 2013 18:19:41 -0500 Message-ID: From: Nico Williams To: Markus Lanthaler Content-Type: text/plain; charset=UTF-8 Cc: Stephan Beal , json@ietf.org Subject: Re: [Json] The names within an object SHOULD be unique. X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 05 Jun 2013 23:20:25 -0000 On Wed, Jun 5, 2013 at 3:52 PM, Markus Lanthaler wrote: > I've seen people using this for comments. People relied on the fact that serializers ignored all but the last occurrence of a key. Oh, this might actually be important. Perhaps the best way to handle comments is to have the "schema" (if there is one, stated or otherwise) specify some keys as being comments, but that doesn't help for free-form data. If I were doing this duplicate-keys-for-comments thing and wanted to ensure interop I'd triplicate them instead, with the value I actually want decoded sent first and last, and the comment sandwiched in between. Painful. From douglas@crockford.com Wed Jun 5 16:27:29 2013 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 B198321E8054 for ; Wed, 5 Jun 2013 16:27:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.278 X-Spam-Level: X-Spam-Status: No, score=-2.278 tagged_above=-999 required=5 tests=[AWL=-0.279, BAYES_00=-2.599, J_CHICKENPOX_35=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mf4l+pURtIGk for ; Wed, 5 Jun 2013 16:27:23 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id 61F0221F999B for ; Wed, 5 Jun 2013 16:27:18 -0700 (PDT) Received: from [192.168.114.223] ([216.113.168.135]) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis) id 0MYyF9-1UwjJW3XOt-00VRTR; Wed, 05 Jun 2013 19:26:42 -0400 Message-ID: <51AFC924.2030805@crockford.com> Date: Wed, 05 Jun 2013 16:26:28 -0700 From: Douglas Crockford User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Vinny A References: <51AF8479.5080002@crockford.com> <51AF9ACF.5020507@cisco.com> <51AFB3F8.8060708@crockford.com> <8F32953C-C788-4DC9-888E-920E2BEB7FDD@yahoo.com> <831B8E46-F239-4353-8F95-8DF3F9BD2E78@yahoo.com> In-Reply-To: <831B8E46-F239-4353-8F95-8DF3F9BD2E78@yahoo.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V02:K0:49z0cfc9RUzrQoLn8Ga5tkIcx3LE8d0EimheFvD4muC oS5HWsDbMhK3IIaPb0Xgn0gvYxtcEzxkn7720QfIkd3+xFvoba ATdbmaO8Gvk8w7Mi3RCEj1ni2e+A1EwwieZhLMDUM8BmFb7OH7 T97/QN6q8B15HKzwcWRoCd8Vk5poeLdtgEQSomXfMtHGNYunSD 5S3ga3uZgqx8KukPBV5PYD62q9/00XDw2W6JjTevY4VHAD5b5i 6fVaOEuax88zDHh0pSdfrUv2dmHSc18eNiSKYTvoNE3fKMjyrt XUeQ7/QkEaEjLcs5MZR/C6L/YSaelBiITdJrWKGDuMbthl56iW KBcKb+KHCmrfkuJxZDlDM69e7FsKq+q6BuWyBVz6x Cc: Eliot Lear , "json@ietf.org" Subject: Re: [Json] The names within an object SHOULD be unique. X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 05 Jun 2013 23:27:29 -0000 On 6/5/2013 3:46 PM, Vinny A wrote: > > On Jun 5, 2013, at 4:56 PM, Douglas Crockford > wrote: > > There are people who interpreted the SHOULD as DON'T HAVE TO and > intentionally duplicated the keys. My personal feeling is that we > should change the SHOULD to MUST and let those applications break. But > the consensus of ECMA TC39 is that the SHOULD must stand. > > My personal opinion echoes yours. I understand ECMA's consensus though. > > On Jun 5, 2013, at 4:56 PM, Douglas Crockford > wrote: > > So regrettably, that means we should be explicit about what happens > when this particular bad practice is practiced. > > Do we need to add this to the draft? As in (not proposing this, but as > fodder for discussion): "The names within an object SHOULD be unique. > If duplicate names are encountered, the last key:value pair MUST be used." > It think it should be added to the draft. If duplicate names are encountered, the parse MAY fail (because some implementations correctly do that), or it MAY succeed by accepting the last duplicated key:value pair. From jhildebr@cisco.com Wed Jun 5 16:36:17 2013 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 E27FB21E809C for ; Wed, 5 Jun 2013 16:36:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NuSCBqVG5rxA for ; Wed, 5 Jun 2013 16:36:13 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id C86B211E80AE for ; Wed, 5 Jun 2013 16:35:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1209; q=dns/txt; s=iport; t=1370475356; x=1371684956; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=MzVsE0K2h7Q00Um8DujizWDgix9N92cWbTPg3lbHwKA=; b=ZdMSdPKTIReTjoL4XzKrm93LqxzuQzWsMyw3onSkBdOvZgCkLr5TgWh7 C/JUAo+vwyNGFK8AZBMIgEQvoANVD09IiFES1B+PSsaef+SRKsssCvSBl IY0fUixLGejL1m0qhwcGChT/l5JT+kI1plavNHMLHXc8Z8m3sbPupW9nS U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhoFALvKr1GtJXG8/2dsb2JhbABZgwkwv0KBABZ0giMBAQEEAQEBNzQLEgEIGAoUNwslAgQBDQUIiAUMvHoEjXSBBjEHgnphA6h/gw+BaT4 X-IronPort-AV: E=Sophos;i="4.87,810,1363132800"; d="scan'208";a="219335843" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-5.cisco.com with ESMTP; 05 Jun 2013 23:35:18 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r55NZIrD000318 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 5 Jun 2013 23:35:18 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.56]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.02.0318.004; Wed, 5 Jun 2013 18:35:17 -0500 From: "Joe Hildebrand (jhildebr)" To: Douglas Crockford , John Cowan Thread-Topic: [Json] Unpaired surrogates in JSON strings Thread-Index: AQHOYgjwaH+sWe/75UqTmsr195d0xpknuQ0AgAAQ1ACAAALZgP//6RgA Date: Wed, 5 Jun 2013 23:35:17 +0000 Message-ID: In-Reply-To: <51AF8A09.50806@crockford.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [10.21.123.84] Content-Type: text/plain; charset="us-ascii" Content-ID: <9B93EFA1EBC90C4F913305361FE598CF@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "json@ietf.org" Subject: Re: [Json] Unpaired surrogates in JSON strings X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 05 Jun 2013 23:36:18 -0000 I don't mind allowing surrogate pairs in \u notation. But I think we should specify what happens when you send just half of the pair. For example, adding this after section 2.5, graph 4: Escape sequences between \uD800 and \uDFFF SHOULD be generated only as valid UTF16 surrogate pairs (this SHOULD is only to allow backward compatibility). When encountering an invalid surrogate pair (such as "foo\uD834bar" or "\uDD1E\uD834"), parsers MAY either throw an error (taking the risk of some backward incompatibility with old generators) or MAY ignore the sequence. On 6/5/13 12:57 PM, "Douglas Crockford" wrote: >On 6/5/2013 11:47 AM, John Cowan wrote: >> Douglas Crockford scripsit: >> >>> Such a requirement will be breaking. Breaking changes are out of scope. >> How is it a breaking change to limit what documents are allowed to be >> *generated*? >> >Because JSON is currently being used in applications that deliver those >codepoints. >I believe that ECMA cannot accept if this is changed. >_______________________________________________ >json mailing list >json@ietf.org >https://www.ietf.org/mailman/listinfo/json > --=20 Joe Hildebrand From jhildebr@cisco.com Wed Jun 5 16:41:28 2013 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 3866721F8F78 for ; Wed, 5 Jun 2013 16:41:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_35=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K8ejuJy0skkr for ; Wed, 5 Jun 2013 16:41:22 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id B576411E80BA for ; Wed, 5 Jun 2013 16:41:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=371; q=dns/txt; s=iport; t=1370475668; x=1371685268; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=a71ONFv2w+04rRNiKeB5xegz1iOtSSbyc7RGX5KUMnI=; b=WVwrLrGKa3MggagITdx0zl7gYvEnxKWMg4KxWeZ0wzQUXACJXGTtAs6z gkY7dLyiEokz3ecJoFcHR9J5yYGaOyxXdmd+NjGTIBzrHLBBWw9cTWPfQ 7/rhxP4Y8EsLYgDdfbqsf7iM4lGTMmFjBUlui6snLDYGjvfSvrbw9b5Tj A=; X-IronPort-AV: E=Sophos;i="4.87,810,1363132800"; d="scan'208";a="219303191" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-2.cisco.com with ESMTP; 05 Jun 2013 23:40:30 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r55NeURm024200 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 5 Jun 2013 23:40:30 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.56]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.02.0318.004; Wed, 5 Jun 2013 18:40:30 -0500 From: "Joe Hildebrand (jhildebr)" To: Douglas Crockford , Vinny A Thread-Topic: [Json] The names within an object SHOULD be unique. Thread-Index: AQHOYhtyf+f4Zs3CA0O//LSHQrFFDJknuj6hgABdkQD//59RgA== Date: Wed, 5 Jun 2013 23:40:29 +0000 Message-ID: In-Reply-To: <51AFC924.2030805@crockford.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [10.21.123.84] Content-Type: text/plain; charset="us-ascii" Content-ID: <0C84EB83EF89124AA3FF82549AD7CBA9@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Eliot Lear , "json@ietf.org" Subject: Re: [Json] The names within an object SHOULD be unique. X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 05 Jun 2013 23:41:28 -0000 On 6/5/13 5:26 PM, "Douglas Crockford" wrote: >It think it should be added to the draft. If duplicate names are >encountered, the parse MAY fail (because some implementations correctly >do that), or it MAY succeed by accepting the last duplicated key:value >pair. +1 do we have a preference for new software? --=20 Joe Hildebrand From tbray@textuality.com Wed Jun 5 16:45:27 2013 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 D357621F848A for ; Wed, 5 Jun 2013 16:45:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.618 X-Spam-Level: X-Spam-Status: No, score=0.618 tagged_above=-999 required=5 tests=[AWL=-0.434, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_35=0.6, RCVD_IN_SORBS_DUL=0.877, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xfre8d3THV3B for ; Wed, 5 Jun 2013 16:45:23 -0700 (PDT) Received: from mail-ve0-x22e.google.com (mail-ve0-x22e.google.com [IPv6:2607:f8b0:400c:c01::22e]) by ietfa.amsl.com (Postfix) with ESMTP id A31AE21F85C9 for ; Wed, 5 Jun 2013 16:45:19 -0700 (PDT) Received: by mail-ve0-f174.google.com with SMTP id oz10so1707876veb.19 for ; Wed, 05 Jun 2013 16:45:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=M3CVbiQ7OgOl5tRFbplerSk+fCnzHkpRgakRTTCLYJg=; b=ccaim2KT5hxRCCDY44Z7LvyPJKQMebhMiYpLJd295luOnDZXIeAVOVqOAn/55kBhzg R7GW+/CMOEi9F0JrpE7mY8Vr8rmONZo8+x5q+wwb+7SMwpKLtkTbihRoquy+sybfN1yp cckF/aWdvLZkRwH0iYRkYZmM4TmCnLda+fDB6EkXf6wr1j9J5V8TEpGklZxyW6jqNDNi ezh9Az+BezW0w8Seh9gDRWGtTWZ//Du2quN97MzxLU7bg+oFwIopKdSPJ3v4draRpnXx 0x+qraV4IxrPexrnQfP8n2dWK9GD8t4ywJv1wvdFxnJ48DvbMrWGfWGrI056eQE7RSgT NkGg== MIME-Version: 1.0 X-Received: by 10.221.4.131 with SMTP id oc3mr21009001vcb.49.1370475912344; Wed, 05 Jun 2013 16:45:12 -0700 (PDT) Received: by 10.220.48.14 with HTTP; Wed, 5 Jun 2013 16:45:12 -0700 (PDT) X-Originating-IP: [96.49.81.176] In-Reply-To: References: <51AFC924.2030805@crockford.com> Date: Wed, 5 Jun 2013 16:45:12 -0700 Message-ID: From: Tim Bray To: "Joe Hildebrand (jhildebr)" Content-Type: multipart/alternative; boundary=089e01293fe2edc9c104de70c9ed X-Gm-Message-State: ALoCoQnRuO+vGIefMJUfzVP8XvtiJu9YlV6QKU2Xqp4TS4u44OU88oZY+A2BWG8nWhX2c+//2VD+ Cc: Vinny A , Eliot Lear , Douglas Crockford , "json@ietf.org" Subject: Re: [Json] The names within an object SHOULD be unique. X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 05 Jun 2013 23:45:28 -0000 --089e01293fe2edc9c104de70c9ed Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Sure, but let=E2=80=99s put that in the best-practices doc. We=E2=80=99re = just defining a format here. -T On Wed, Jun 5, 2013 at 4:40 PM, Joe Hildebrand (jhildebr) < jhildebr@cisco.com> wrote: > On 6/5/13 5:26 PM, "Douglas Crockford" wrote: > > >It think it should be added to the draft. If duplicate names are > >encountered, the parse MAY fail (because some implementations correctly > >do that), or it MAY succeed by accepting the last duplicated key:value > >pair. > > +1 > > do we have a preference for new software? > > -- > Joe Hildebrand > > > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > --089e01293fe2edc9c104de70c9ed Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Sure, but let=E2=80=99s put that in the best-practices doc= .=C2=A0 We=E2=80=99re just defining a format here. -T


On Wed, Jun 5, 2013 at = 4:40 PM, Joe Hildebrand (jhildebr) <jhildebr@cisco.com> wro= te:
On 6/5/13 5:26 PM, "D= ouglas Crockford" <douglas= @crockford.com> wrote:

>It think it should be added to the draft. If duplicate names are
>encountered, the parse MAY fail (because some implementations correctly=
>do that), or it MAY succeed by accepting the last duplicated key:value<= br> >pair.

+1

do we have a preference for new software?

--
Joe Hildebrand



_______________________________________________
json mailing list
json@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/json

--089e01293fe2edc9c104de70c9ed-- From paul.hoffman@vpnc.org Wed Jun 5 16:56:55 2013 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 A307911E80D1 for ; Wed, 5 Jun 2013 16:56:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g5-vGxgnP5ae for ; Wed, 5 Jun 2013 16:56:53 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id E81F111E80AE for ; Wed, 5 Jun 2013 16:56:52 -0700 (PDT) Received: from [10.20.30.90] (50-0-66-165.dsl.dynamic.sonic.net [50.0.66.165]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r55NtwQh099847 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 5 Jun 2013 16:55:59 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Paul Hoffman In-Reply-To: <51AF8A09.50806@crockford.com> Date: Wed, 5 Jun 2013 16:55:58 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130605162246.GG3680@mercury.ccil.org> <51AF7988.6040009@crockford.com> <20130605184702.GB6999@mercury.ccil.org> <51AF8A09.50806@crockford.com> To: Douglas Crockford X-Mailer: Apple Mail (2.1508) Cc: json@ietf.org Subject: Re: [Json] Unpaired surrogates in JSON strings X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 05 Jun 2013 23:56:56 -0000 On Jun 5, 2013, at 11:57 AM, Douglas Crockford = wrote: > On 6/5/2013 11:47 AM, John Cowan wrote: >> Douglas Crockford scripsit: >>=20 >>> Such a requirement will be breaking. Breaking changes are out of = scope. >> How is it a breaking change to limit what documents are allowed to be >> *generated*? >>=20 > Because JSON is currently being used in applications that deliver = those codepoints. Can you say why an application would do that, given the JSON = specification? --Paul Hoffman From paul.hoffman@vpnc.org Wed Jun 5 17:14:24 2013 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 899D021F9691 for ; Wed, 5 Jun 2013 17:14:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wJ+pjFMikv0k for ; Wed, 5 Jun 2013 17:14:23 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 4D5D521F9695 for ; Wed, 5 Jun 2013 17:14:23 -0700 (PDT) Received: from [10.20.30.90] (50-0-66-165.dsl.dynamic.sonic.net [50.0.66.165]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r560EMF9000423 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 5 Jun 2013 17:14:22 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Paul Hoffman In-Reply-To: <51AF9D4C.5060403@crockford.com> Date: Wed, 5 Jun 2013 17:14:21 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <60563185-85A8-4696-8B8C-9282256CFA71@vpnc.org> References: <51AF9D4C.5060403@crockford.com> To: "json@ietf.org" X-Mailer: Apple Mail (2.1508) Subject: Re: [Json] Strings X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 06 Jun 2013 00:14:24 -0000 On Jun 5, 2013, at 1:19 PM, Douglas Crockford = wrote: > It should say explicitly that these three all produce exactly the same = result: >=20 > "\u002F" > "\/" > "/" Proposed wording: just before the ABNF at the end of section 2.5, add: When comparing strings, escaped characters SHOULD compare the same as = their unescaped counterparts. For example, the following three strings = SHOULD be considered equivalent for comparisons: "\u002F" "\/" "/" --Paul Hoffman= From paul.hoffman@vpnc.org Wed Jun 5 17:20:39 2013 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 4FE7721F8B35 for ; Wed, 5 Jun 2013 17:20:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ciMSN8OErBrO for ; Wed, 5 Jun 2013 17:20:38 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 92CA721F8AF4 for ; Wed, 5 Jun 2013 17:20:38 -0700 (PDT) Received: from [10.20.30.90] (50-0-66-165.dsl.dynamic.sonic.net [50.0.66.165]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r560Ka5b000593 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 5 Jun 2013 17:20:37 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Paul Hoffman In-Reply-To: <51AF7C55.3070606@crockford.com> Date: Wed, 5 Jun 2013 17:20:36 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <2E4D08E5-3AF2-42F5-874A-9CD872800717@vpnc.org> References: <51AF7C55.3070606@crockford.com> To: "json@ietf.org" X-Mailer: Apple Mail (2.1508) Subject: Re: [Json] Security Considerations X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 06 Jun 2013 00:20:39 -0000 On Jun 5, 2013, at 10:58 AM, Douglas Crockford = wrote: > The section on security considerations is completely inadequate. It is = describing a use of JavaScript eval that is now considered to be a very = bad practice, and it provides no advice for other languages. >=20 > It should instead be advising care when constructing JSON texts, = insisting on proper encoding practices and avoidance of concatenation. Who wants to take a stab at proposed Security Considerations wording? = This should probably go in Section 7, not Section 6, so that allows a = bit more formatting such as headers and such. --Paul Hoffman From cowan@ccil.org Wed Jun 5 17:23:10 2013 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 C42F921E805D for ; Wed, 5 Jun 2013 17:23:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cHlgBaC38W81 for ; Wed, 5 Jun 2013 17:22:57 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id 7C6BC21E8051 for ; Wed, 5 Jun 2013 17:22:57 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1UkNyg-000446-Rj; Wed, 05 Jun 2013 20:22:54 -0400 Date: Wed, 5 Jun 2013 20:22:54 -0400 From: John Cowan To: Paul Hoffman Message-ID: <20130606002254.GE6999@mercury.ccil.org> References: <20130605162246.GG3680@mercury.ccil.org> <51AF7988.6040009@crockford.com> <20130605184702.GB6999@mercury.ccil.org> <51AF8A09.50806@crockford.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Cc: Douglas Crockford , json@ietf.org Subject: Re: [Json] Unpaired surrogates in JSON strings X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 06 Jun 2013 00:23:10 -0000 Paul Hoffman scripsit: > Can you say why an application would do that, given the JSON specification? Perhaps because its designers believe that Section 4's explicit mustard trumps section 1's definition. -- Her he asked if O'Hare Doctor tidings sent from far John Cowan coast and she with grameful sigh him answered that http://ccil.org/~cowan O'Hare Doctor in heaven was. Sad was the man that word cowan@ccil.org to hear that him so heavied in bowels ruthful. All she there told him, ruing death for friend so young, James Joyce, Ulysses algate sore unwilling God's rightwiseness to withsay. "Oxen of the Sun" From tbray@textuality.com Wed Jun 5 17:31:42 2013 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 42A9621F86AE for ; Wed, 5 Jun 2013 17:31:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.377 X-Spam-Level: X-Spam-Status: No, score=-0.377 tagged_above=-999 required=5 tests=[FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TZ4KlaukiRSW for ; Wed, 5 Jun 2013 17:31:37 -0700 (PDT) Received: from mail-vc0-f174.google.com (mail-vc0-f174.google.com [209.85.220.174]) by ietfa.amsl.com (Postfix) with ESMTP id 1C87D21E804E for ; Wed, 5 Jun 2013 17:19:26 -0700 (PDT) Received: by mail-vc0-f174.google.com with SMTP id kw10so1556387vcb.19 for ; Wed, 05 Jun 2013 17:18:50 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=+4h3Mtr/Qdkd2tKEXjUUSz50MNxDumKWbt+KeR+wFaI=; b=GAf8BHnlmK8AcK0EvvFJ9FKHXaoj/8cV8kKvzGi8p/3Li8tD76lxDOuShj0J6T4cPR meBvcHD/rdom68+D4btUR2b0pHs0VXVnZrBiev3od0g8UtcSMLKNIIzWt2egh1Usa50o 4Nzij/TqxEtT83re1GX4eD4E1sgcQoCZym91MeOpawiEuOxt3D5zlg2+WEBu/uSn3wja o4fQIKJhobSstZL3Uq8Gut5NS+30xD7fwf0HgSi1KvVQObq2mVCbPotZ7C/3+LDnPBg3 LSVGvIRqLzvpYWTtBaVDD4WAD2aTNo4wAhoTMVqpsMcL/s1lzjVio5rgy2GuGBTayttu naxA== MIME-Version: 1.0 X-Received: by 10.52.237.228 with SMTP id vf4mr965887vdc.79.1370477930531; Wed, 05 Jun 2013 17:18:50 -0700 (PDT) Received: by 10.220.48.14 with HTTP; Wed, 5 Jun 2013 17:18:50 -0700 (PDT) X-Originating-IP: [96.49.81.176] In-Reply-To: References: <20130605162246.GG3680@mercury.ccil.org> <51AF7988.6040009@crockford.com> <20130605184702.GB6999@mercury.ccil.org> <51AF8A09.50806@crockford.com> Date: Wed, 5 Jun 2013 17:18:50 -0700 Message-ID: From: Tim Bray To: Paul Hoffman Content-Type: multipart/alternative; boundary=089e0122f6aa38f7d104de7142b8 X-Gm-Message-State: ALoCoQkBQ67AN7l1VYzu7p7vSBFnbcrGeTSuy+Z68RWvj6gcVnaQbRSpm3Pwjiu0YODyRndfSpVd Cc: Douglas Crockford , "json@ietf.org" Subject: Re: [Json] Unpaired surrogates in JSON strings X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 06 Jun 2013 00:31:42 -0000 --089e0122f6aa38f7d104de7142b8 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable In section 2.5 of 4627, a reasonable reading of the text clearly disallows unpaired surrogates, because the discussion is exclusively of characters, which surrogates aren=E2=80=99t; they are code points, but there are no cha= racters that have those code points. From the introduction: =E2=80=9CA string is a = sequence of zero or more Unicode characters=E2=80=9D. Case closed. A loose reading of the BNF probably allows naked surrogates if you ignore what the text says. I think anyone who=E2=80=99s delivering those codepoints is already in viol= ation of 4627, and I don=E2=80=99t think we should retroactively forgive those sins. -T On Wed, Jun 5, 2013 at 4:55 PM, Paul Hoffman wrote: > On Jun 5, 2013, at 11:57 AM, Douglas Crockford > wrote: > > > On 6/5/2013 11:47 AM, John Cowan wrote: > >> Douglas Crockford scripsit: > >> > >>> Such a requirement will be breaking. Breaking changes are out of scop= e. > >> How is it a breaking change to limit what documents are allowed to be > >> *generated*? > >> > > Because JSON is currently being used in applications that deliver those > codepoints. > > Can you say why an application would do that, given the JSON specificatio= n? > > --Paul Hoffman > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > --089e0122f6aa38f7d104de7142b8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
In section 2.5 of 4627, a reasonable reading of the text c= learly disallows unpaired surrogates, because the discussion is exclusively= of characters, which surrogates aren=E2=80=99t; they are code points, but = there are no characters that have those code points. From the introduction:= =E2=80=9CA string is a sequence of zero or more Unicode characters=E2=80= =9D. Case closed.=C2=A0

A loose reading of the BNF probably allows naked surrogates if you igno= re what the text says.=C2=A0

I think anyone who=E2=80=99s deliverin= g those codepoints is already in violation of 4627, and I don=E2=80=99t thi= nk we should retroactively forgive those sins.

-T


On Wed, Jun 5, 2013 at 4:55 PM, Paul Hoffman <paul.hoffman@vpnc.org= > wrote:
On Jun 5, 2013, at 11:57 A= M, Douglas Crockford <douglas@c= rockford.com> wrote:

> On 6/5/2013 11:47 AM, John Cowan wrote:
>> Douglas Crockford scripsit:
>>
>>> Such a requirement will be breaking. Breaking changes are out = of scope.
>> How is it a breaking change to limit what documents are allowed to= be
>> *generated*?
>>
> Because JSON is currently being used in applications that deliver thos= e codepoints.

Can you say why an application would do that, given the JSON specific= ation?

--Paul Hoffman

_______________________________________________
json mailing list
json@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/json

--089e0122f6aa38f7d104de7142b8-- From James.H.Manger@team.telstra.com Wed Jun 5 17:33:05 2013 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 57E5B21F882A for ; Wed, 5 Jun 2013 17:33:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.698 X-Spam-Level: * X-Spam-Status: No, score=1.698 tagged_above=-999 required=5 tests=[HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Se0N6TaEe8zv for ; Wed, 5 Jun 2013 17:32:59 -0700 (PDT) Received: from ipxcvo.tcif.telstra.com.au (ipxcvo.tcif.telstra.com.au [203.35.135.208]) by ietfa.amsl.com (Postfix) with ESMTP id CF1EF21F86D3 for ; Wed, 5 Jun 2013 17:32:55 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.87,810,1363093200"; d="scan'208";a="139908531" Received: from unknown (HELO ipcavi.tcif.telstra.com.au) ([10.97.217.200]) by ipocvi.tcif.telstra.com.au with ESMTP; 06 Jun 2013 10:32:54 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,7097"; a="188983807" Received: from wsmsg3751.srv.dir.telstra.com ([172.49.40.172]) by ipcavi.tcif.telstra.com.au with ESMTP; 06 Jun 2013 10:32:54 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3751.srv.dir.telstra.com ([172.49.40.172]) with mapi; Thu, 6 Jun 2013 10:32:53 +1000 From: "Manger, James H" To: Paul Hoffman , "json@ietf.org" Date: Thu, 6 Jun 2013 10:32:52 +1000 Thread-Topic: [Json] Strings Thread-Index: Ac5iSzlebDpqGWvHQUmd3SwkUrw6LwAAUy8Q Message-ID: <255B9BB34FB7D647A506DC292726F6E1151B10582A@WSMSG3153V.srv.dir.telstra.com> References: <51AF9D4C.5060403@crockford.com> <60563185-85A8-4696-8B8C-9282256CFA71@vpnc.org> In-Reply-To: <60563185-85A8-4696-8B8C-9282256CFA71@vpnc.org> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [Json] Strings X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 06 Jun 2013 00:33:05 -0000 PiA+IEl0IHNob3VsZCBzYXkgZXhwbGljaXRseSB0aGF0IHRoZXNlIHRocmVlIGFsbCBwcm9kdWNl IGV4YWN0bHkgdGhlDQo+IHNhbWUgcmVzdWx0Og0KPiA+DQo+ID4gICAgIlx1MDAyRiINCj4gPiAg ICAiXC8iDQo+ID4gICAgIi8iDQo+IA0KPiBQcm9wb3NlZCB3b3JkaW5nOiBqdXN0IGJlZm9yZSB0 aGUgQUJORiBhdCB0aGUgZW5kIG9mIHNlY3Rpb24gMi41LCBhZGQ6DQo+IA0KPiBXaGVuIGNvbXBh cmluZyBzdHJpbmdzLCBlc2NhcGVkIGNoYXJhY3RlcnMgU0hPVUxEIGNvbXBhcmUgdGhlIHNhbWUg YXMNCj4gdGhlaXIgdW5lc2NhcGVkIGNvdW50ZXJwYXJ0cy4gRm9yIGV4YW1wbGUsIHRoZSBmb2xs b3dpbmcgdGhyZWUgc3RyaW5ncw0KPiBTSE9VTEQgYmUgY29uc2lkZXJlZCBlcXVpdmFsZW50IGZv ciBjb21wYXJpc29uczoNCj4gDQo+ICAgICJcdTAwMkYiDQo+ICAgICJcLyINCj4gICAgIi8iDQoN ClN1cmVseSB0aGVzZSBNVVNUIGNvbXBhcmUgdGhlIHNhbWUsIG5vdCBTSE9VTEQuIFRoZXkgcmVw cmVzZW50IGV4YWN0bHkgdGhlIHNhbWUgc3RyaW5nIChzZXF1ZW5jZSBvZiBjb2RlIHBvaW50cyku DQoNCkFsc28gaW5jbHVkZSAiXHUwMDJmIiAobG93ZXJjYXNlIGhleCkgYXMgYW5vdGhlciBmb3Jt IHRoYXQgcHJvZHVjZXMgZXhhY3RseSB0aGUgc2FtZSByZXN1bHQuDQoNCg0KUC5TLiBBbm90aGVy IGxpdHRsZSBmaXg6IHVwZGF0ZSByZWZlcmVuY2UgdG8gQUJORiBmcm9tIFJGQzQyMzQgdG8gUkZD NTIzNC4NCg0KLS0NCkphbWVzIE1hbmdlcg0K From paul.hoffman@vpnc.org Wed Jun 5 17:58:36 2013 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 3744521F93E0 for ; Wed, 5 Jun 2013 17:58:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.4 X-Spam-Level: X-Spam-Status: No, score=-99.4 tagged_above=-999 required=5 tests=[J_CHICKENPOX_14=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xW1roNwY4ozp for ; Wed, 5 Jun 2013 17:58:35 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id B75DC21F93D4 for ; Wed, 5 Jun 2013 17:58:35 -0700 (PDT) Received: from [10.20.30.90] (50-0-66-165.dsl.dynamic.sonic.net [50.0.66.165]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r560wY79001434 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 5 Jun 2013 17:58:35 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Paul Hoffman In-Reply-To: Date: Wed, 5 Jun 2013 17:58:33 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <83728898-9A2D-4758-9C06-1157E2954CCB@vpnc.org> References: To: "json@ietf.org" X-Mailer: Apple Mail (2.1508) Subject: Re: [Json] Unpaired surrogates in JSON strings X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 06 Jun 2013 00:58:36 -0000 The text says "character" everywhere. It says "code point" exactly once, = when it is talking about a character's code point. The ABNF seems to allow code points, not characters. This is pretty = clearly a mistake. This could be resolved by a warning similar to what Joe proposed, but it = should be stronger. Also, Joe's wording assumes that these code points = are always represented as escape sequences, but the ABNF allows them to = be in a string as raw, unescaped code points. On Jun 5, 2013, at 4:35 PM, Joe Hildebrand (jhildebr) = wrote: > I don't mind allowing surrogate pairs in \u notation. But I think we > should specify what happens when you send just half of the pair. For > example, adding this after section 2.5, graph 4: >=20 > Escape sequences between \uD800 and \uDFFF SHOULD be generated only as > valid UTF16 surrogate pairs (this SHOULD is only to allow backward > compatibility). When encountering an invalid surrogate pair (such as > "foo\uD834bar" or "\uDD1E\uD834"), parsers MAY either throw an error > (taking the risk of some backward incompatibility with old generators) = or > MAY ignore the sequence. Alternate proposal: Code points between U+D800 and U+DFFF SHOULD be generated only as valid UTF16 surrogate pairs; this SHOULD is only to allow backward compatibility with applications that ignored the restriction that strings consist of Unicode characters. A parser that encounters an invalid surrogate pair (such as "foo\uD834bar" or "\uDD1E\uD834"), SHOULD throw an error because the string does not consist of characters; it might ignore the errant code points, but at the risk of allowing strings that other parsers would find illegal. --Paul Hoffman= From tbray@textuality.com Wed Jun 5 18:05:30 2013 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 D934921F94DC for ; Wed, 5 Jun 2013 18:05:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.223 X-Spam-Level: X-Spam-Status: No, score=0.223 tagged_above=-999 required=5 tests=[FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WMjHV+5jyuuR for ; Wed, 5 Jun 2013 18:05:26 -0700 (PDT) Received: from mail-vc0-f175.google.com (mail-vc0-f175.google.com [209.85.220.175]) by ietfa.amsl.com (Postfix) with ESMTP id 06AD521F949F for ; Wed, 5 Jun 2013 18:05:25 -0700 (PDT) Received: by mail-vc0-f175.google.com with SMTP id hr11so1579099vcb.6 for ; Wed, 05 Jun 2013 18:05:25 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=Sdd/TQr0C+5qnE0Qbm4UJzuI2n/r/kQXKzn1sAi18yM=; b=KXnsh58QcIwuxs3vg2l/gaHnlfkaZw7AcOlhyXyqvcFmjisOViHwLuMHrngza9heYC qNjBUrsdj2Dlm6bMEvUGmhMEPTHAPwg2PpeUo1xc47iTR7x49XNBVvOx1QARWBcA2cj6 cjAHhA9ZbsVylxc1lL+U7E3FUF/yLM0CJd8MLapyxH8q2urHnrGyR5Nw+wuBBR7O+0OE gU2HsKsDZfx/LjL2XXHQte+PuJ54PlhLLT5Zb5QvlA1TKNfUDYtkGAf93bjLHqYnzYYe bmfhgFFmVY+52iFUREumVoEOPTpU+R+aDUepO/ON8bkfxWNnGzIVKIpMBRoWki0Magbp spEg== MIME-Version: 1.0 X-Received: by 10.52.237.228 with SMTP id vf4mr1002259vdc.79.1370480725316; Wed, 05 Jun 2013 18:05:25 -0700 (PDT) Received: by 10.220.48.14 with HTTP; Wed, 5 Jun 2013 18:05:25 -0700 (PDT) X-Originating-IP: [24.84.235.32] In-Reply-To: <83728898-9A2D-4758-9C06-1157E2954CCB@vpnc.org> References: <83728898-9A2D-4758-9C06-1157E2954CCB@vpnc.org> Date: Wed, 5 Jun 2013 18:05:25 -0700 Message-ID: From: Tim Bray To: Paul Hoffman Content-Type: multipart/alternative; boundary=089e0122f6aacddd0904de71e896 X-Gm-Message-State: ALoCoQl9Tah3b4A6swoJ3DihTqATeYLzalXO8kuOAgRbHn9c72oyQR7fOMsY1V5jPvUphotDZekN Cc: "json@ietf.org" Subject: Re: [Json] Unpaired surrogates in JSON strings X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 06 Jun 2013 01:05:31 -0000 --089e0122f6aacddd0904de71e896 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Jun 5, 2013 at 5:58 PM, Paul Hoffman wrote: > > Escape sequences between \uD800 and \uDFFF SHOULD be generated only as > > valid UTF16 surrogate pairs > Turn it into MUST. The intent of 4627 is perfectly clear, even if the BNF is buggy. I don=E2=80=99t think this rewrite should allow things that the = previous spec didn=E2=80=99t. -T > (this SHOULD is only to allow backward > > compatibility). When encountering an invalid surrogate pair (such as > > "foo\uD834bar" or "\uDD1E\uD834"), parsers MAY either throw an error > > (taking the risk of some backward incompatibility with old generators) = or > > MAY ignore the sequence. > > Alternate proposal: > > Code points between U+D800 and U+DFFF SHOULD be generated only as > valid UTF16 surrogate pairs; this SHOULD is only to allow backward > compatibility with applications that ignored the restriction that > strings consist of Unicode characters. A parser that encounters > an invalid surrogate pair (such as "foo\uD834bar" or "\uDD1E\uD834"), > SHOULD throw an error because the string does not consist of characters; > it might ignore the errant code points, but at the risk of allowing > strings that other parsers would find illegal. > > --Paul Hoffman > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > --089e0122f6aacddd0904de71e896 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Jun 5, 2013 at 5:58 PM, Paul Hoffman <paul.ho= ffman@vpnc.org> wrote:
> Escape sequences between \uD800 and \uD= FFF SHOULD be generated only as
> valid UTF16 surrogate pairs

Tur= n it into MUST. The intent of 4627 is perfectly clear, even if the BNF is b= uggy.=C2=A0 I don=E2=80=99t think this rewrite should allow things that the= previous spec didn=E2=80=99t. -T

=C2=A0
(this SHOULD is only to allow backward
> compatibility). =C2=A0When encountering an invalid surrogate pair (suc= h as
> "foo\uD834bar" or "\uDD1E\uD834"), parsers MAY eit= her throw an error
> (taking the risk of some backward incompatibility with old generators)= or
> MAY ignore the sequence.

Alternate proposal:

Code points between U+D800 and U+DFFF SHOULD be generated only as
valid UTF16 surrogate pairs; this SHOULD is only to allow backward
compatibility with applications that ignored the restriction that
strings consist of Unicode characters. A parser that encounters
an invalid surrogate pair (such as "foo\uD834bar&quo= t; or "\uDD1E\uD834"),
SHOULD throw an error because the string does not consist of characte= rs;
it might ignore the errant code points, but at the risk of allowing
strings that other parsers would find illegal.

--Paul Hoffman
_____________________= __________________________
json mailing list
json@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/json

--089e0122f6aacddd0904de71e896-- From douglas@crockford.com Wed Jun 5 18:08:45 2013 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 F3B7621F9632 for ; Wed, 5 Jun 2013 18:08:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eEja2DFKJhTy for ; Wed, 5 Jun 2013 18:08:39 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id 1477221F9631 for ; Wed, 5 Jun 2013 18:08:38 -0700 (PDT) Received: from [192.168.0.108] (173-228-7-202.dsl.static.sonic.net [173.228.7.202]) by mrelay.perfora.net (node=mrus2) with ESMTP (Nemesis) id 0Mbx30-1V0HgN2BTa-00JGuD; Wed, 05 Jun 2013 21:08:37 -0400 Message-ID: <51AFE107.7020301@crockford.com> Date: Wed, 05 Jun 2013 18:08:23 -0700 From: Douglas Crockford User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Tim Bray References: <20130605162246.GG3680@mercury.ccil.org> <51AF7988.6040009@crockford.com> <20130605184702.GB6999@mercury.ccil.org> <51AF8A09.50806@crockford.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Provags-ID: V02:K0:FylmLBTAq2Uk6xMjNcqy4MlF+4DqS0CZwHp/eNGmJ+9 p0ujblWKuG6ucJCv0jZwSH51rPRrpCITNBFIVOXhXgEElc97MH hLa6uCC1QQAoA/p73SN9/+R7KyaH1pk7N4jXLS1se2J7JxGFHU wJ9k+gXpnVqQwT8sIaBuckf7OCsUDBwieqYB/23KpVwounau1f lgyhMXHCRhlk4s77QnOhNOd7iyKQkz0ResWEkiq/j9eaS9lNqN voLINWZybOAiRdmfvvEFXDFnS9S+7p2Vr3p93Aw/u39hPGAAt3 u35FUxUzSHT1UvzjSkmSdMF57QcyPhe0MKBBJEMh0DWYtSaNfE wXlnePm/H2IFW4xpijYY= Cc: Paul Hoffman , "json@ietf.org" Subject: Re: [Json] Unpaired surrogates in JSON strings X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 06 Jun 2013 01:08:45 -0000 On 6/5/2013 5:18 PM, Tim Bray wrote: > In section 2.5 of 4627, a reasonable reading of the text clearly > disallows unpaired surrogates, because the discussion is exclusively > of characters, which surrogates aren’t; they are code points, but > there are no characters that have those code points. From the > introduction: “A string is a sequence of zero or more Unicode > charactersâ€. Case closed. > > A loose reading of the BNF probably allows naked surrogates if you > ignore what the text says. > > I think anyone who’s delivering those codepoints is already in > violation of 4627, and I don’t think we should retroactively forgive > those sins. > > -T > > > On Wed, Jun 5, 2013 at 4:55 PM, Paul Hoffman > wrote: > > On Jun 5, 2013, at 11:57 AM, Douglas Crockford > > wrote: > > > On 6/5/2013 11:47 AM, John Cowan wrote: > >> Douglas Crockford scripsit: > >> > >>> Such a requirement will be breaking. Breaking changes are out > of scope. > >> How is it a breaking change to limit what documents are allowed > to be > >> *generated*? > >> > > Because JSON is currently being used in applications that > deliver those codepoints. > > Can you say why an application would do that, given the JSON > specification? > The application that does that is JavaScript. Any 16-bit value can be put next to any other 16-bit value and then JSON encoded. The meaning of 'character' throughout the RFC is ECMAScript's, which is roughly the same as Unicode's code point. This can be seen in the BNF. When the RFC talks about Unicode Characters, it is in the sense of Unicode Characters and not EBCDIC Characters. JSON is just the pipe. It doesn't need to be enforcing Unicode over JavaScript. The sender and receiver can argue about what it means to be a character. JSON has always been agnostic about this. From cowan@ccil.org Wed Jun 5 18:09:51 2013 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 9988721F9648 for ; Wed, 5 Jun 2013 18:09:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1 X-Spam-Level: X-Spam-Status: No, score=-1 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BnyKnwYXiVkg for ; Wed, 5 Jun 2013 18:09:47 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id 48EEB21F9631 for ; Wed, 5 Jun 2013 18:09:47 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1UkOi1-0000b8-GR; Wed, 05 Jun 2013 21:09:45 -0400 Date: Wed, 5 Jun 2013 21:09:45 -0400 From: John Cowan To: Tim Bray Message-ID: <20130606010945.GA1362@mercury.ccil.org> References: <20130605162246.GG3680@mercury.ccil.org> <51AF7988.6040009@crockford.com> <20130605184702.GB6999@mercury.ccil.org> <51AF8A09.50806@crockford.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Cc: Paul Hoffman , Douglas Crockford , "json@ietf.org" Subject: Re: [Json] Unpaired surrogates in JSON strings X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 06 Jun 2013 01:09:51 -0000 Tim Bray scripsit: > In section 2.5 of 4627, a reasonable reading of the text clearly > disallows unpaired surrogates, because the discussion is exclusively > of characters, which surrogates aren’t; they are code points, > but there are no characters that have those code points. From the > introduction: “A string is a sequence of zero or more Unicode > charactersâ€. Case closed. Unfortunately it isn't. > A loose reading of the BNF probably allows naked surrogates if you > ignore what the text says. It's not about a loose reading. Section 4 says "A JSON parser MUST accept all texts that conform to the JSON grammar". That's a flat contradiction of the above. > I think anyone who’s delivering those codepoints is already in > violation of 4627, and I don’t think we should retroactively forgive > those sins. It's already been stated that ECMA can't swallow this change. -- John Cowan cowan@ccil.org http://ccil.org/~cowan Objective consideration of contemporary phenomena compel the conclusion that optimum or inadequate performance in the trend of competitive activities exhibits no tendency to be commensurate with innate capacity, but that a considerable element of the unpredictable must invariably be taken into account. --Ecclesiastes 9:11, Orwell/Brown version From paul.hoffman@vpnc.org Wed Jun 5 18:21:25 2013 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 59AD011E80D5 for ; Wed, 5 Jun 2013 18:21:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.7 X-Spam-Level: X-Spam-Status: No, score=-99.7 tagged_above=-999 required=5 tests=[AWL=0.300, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DwY1W2zyQlWC for ; Wed, 5 Jun 2013 18:21:24 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id C02C421F9944 for ; Wed, 5 Jun 2013 18:21:24 -0700 (PDT) Received: from [10.20.30.90] (50-0-66-165.dsl.dynamic.sonic.net [50.0.66.165]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r561LMWS002027 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 5 Jun 2013 18:21:23 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Paul Hoffman In-Reply-To: <51AF8575.5060706@crockford.com> Date: Wed, 5 Jun 2013 18:21:22 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <51AF8575.5060706@crockford.com> To: "json@ietf.org" X-Mailer: Apple Mail (2.1508) Subject: Re: [Json] Encoding X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 06 Jun 2013 01:21:25 -0000 On Jun 5, 2013, at 11:37 AM, Douglas Crockford = wrote: > I think the section on encoding is not saying anything useful and = should be completely removed. The section is not saying anything useful, and it actually disagrees = with the text from Section 6: JSON may be represented using UTF-8, UTF-16, or UTF-32. When JSON is written in UTF-8, JSON is 8bit compatible. When JSON is written in UTF-16 or UTF-32, the binary content-transfer-encoding must be used. Proposal: Change the title of Section 3 to "Encoding JSON on the Internet", and = make the contents of the section: JSON texts sent on the Internet MUST be encoded as UTF-8 unless there is = a definitive way for a recipient to definitively determine the encoding. --Paul Hoffman= From paul.hoffman@vpnc.org Wed Jun 5 18:22:51 2013 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 43F5021F8FEB for ; Wed, 5 Jun 2013 18:22:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.85 X-Spam-Level: X-Spam-Status: No, score=-99.85 tagged_above=-999 required=5 tests=[AWL=0.150, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZPF+dAFwmsMt for ; Wed, 5 Jun 2013 18:22:50 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id BB20421F8D16 for ; Wed, 5 Jun 2013 18:22:50 -0700 (PDT) Received: from [10.20.30.90] (50-0-66-165.dsl.dynamic.sonic.net [50.0.66.165]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r561Mndf002066 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 5 Jun 2013 18:22:50 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Paul Hoffman In-Reply-To: <255B9BB34FB7D647A506DC292726F6E1151B10582A@WSMSG3153V.srv.dir.telstra.com> Date: Wed, 5 Jun 2013 18:22:49 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <19943667-1EC6-427F-9122-EC037BDE47F1@vpnc.org> References: <51AF9D4C.5060403@crockford.com> <60563185-85A8-4696-8B8C-9282256CFA71@vpnc.org> <255B9BB34FB7D647A506DC292726F6E1151B10582A@WSMSG3153V.srv.dir.telstra.com> To: "Manger, James H" X-Mailer: Apple Mail (2.1508) Cc: "json@ietf.org" Subject: [Json] Update reference for ABNF X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 06 Jun 2013 01:22:51 -0000 On Jun 5, 2013, at 5:32 PM, "Manger, James H" = wrote: > P.S. Another little fix: update reference to ABNF from RFC4234 to = RFC5234. Sounds good to me, as long as a few people promise to do a careful = checking of that. --Paul Hoffman= From paul.hoffman@vpnc.org Wed Jun 5 18:23:37 2013 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 5CFB421F8FEB for ; Wed, 5 Jun 2013 18:23:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.9 X-Spam-Level: X-Spam-Status: No, score=-99.9 tagged_above=-999 required=5 tests=[AWL=0.100, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cUvE4AH+BmlG for ; Wed, 5 Jun 2013 18:23:37 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id EAFEA21F8D16 for ; Wed, 5 Jun 2013 18:23:36 -0700 (PDT) Received: from [10.20.30.90] (50-0-66-165.dsl.dynamic.sonic.net [50.0.66.165]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r561Mndg002066 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 5 Jun 2013 18:23:36 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Paul Hoffman In-Reply-To: <255B9BB34FB7D647A506DC292726F6E1151B10582A@WSMSG3153V.srv.dir.telstra.com> Date: Wed, 5 Jun 2013 18:23:36 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <3A694E90-D3CD-4EB2-92DF-2D0DA4CD4F04@vpnc.org> References: <51AF9D4C.5060403@crockford.com> <60563185-85A8-4696-8B8C-9282256CFA71@vpnc.org> <255B9BB34FB7D647A506DC292726F6E1151B10582A@WSMSG3153V.srv.dir.telstra.com> To: "Manger, James H" X-Mailer: Apple Mail (2.1508) Cc: "json@ietf.org" Subject: Re: [Json] Strings X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 06 Jun 2013 01:23:37 -0000 On Jun 5, 2013, at 5:32 PM, "Manger, James H" = wrote: >>> It should say explicitly that these three all produce exactly the >> same result: >>>=20 >>> "\u002F" >>> "\/" >>> "/" >>=20 >> Proposed wording: just before the ABNF at the end of section 2.5, = add: >>=20 >> When comparing strings, escaped characters SHOULD compare the same as >> their unescaped counterparts. For example, the following three = strings >> SHOULD be considered equivalent for comparisons: >>=20 >> "\u002F" >> "\/" >> "/" >=20 > Surely these MUST compare the same, not SHOULD. Not for a new requirement in this document, no. > They represent exactly the same string (sequence of code points). Yes. > Also include "\u002f" (lowercase hex) as another form that produces = exactly the same result. Good addition. --Paul Hoffman= From douglas@crockford.com Wed Jun 5 18:51:07 2013 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 DCA9E21F964C for ; Wed, 5 Jun 2013 18:51:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cYOZscJcyrNB for ; Wed, 5 Jun 2013 18:51:01 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id 31BD321F9690 for ; Wed, 5 Jun 2013 18:50:34 -0700 (PDT) Received: from [192.168.0.108] (173-228-7-202.dsl.static.sonic.net [173.228.7.202]) by mrelay.perfora.net (node=mrus2) with ESMTP (Nemesis) id 0M4o9F-1UTROc0RA5-00yvO6; Wed, 05 Jun 2013 21:50:33 -0400 Message-ID: <51AFEADD.1050705@crockford.com> Date: Wed, 05 Jun 2013 18:50:21 -0700 From: Douglas Crockford User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Paul Hoffman References: <51AF8575.5060706@crockford.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V02:K0:MpF51PHgbwczRxVD94kGTO95wWjKbBLg+FS/o5/8+OL 7irr1m3EZqw5QdMWpYSMAAiqZmsF8xyXy3j/NTVnCGYx4ACoEI LS746YU8ZVsqQaEOQwuk+EHnDSSXLcM/IGujYT9s/YzgYw8cC0 A1/FgBkQrbYUdKA/sIMlQdaXesBpAUohIPSmd9xo9SgUvQPQ4v p6fbJ6LzlfdTgLNXcbC9yjeuZDKk+keTDhdNUt8HkJ00gj/LX8 8RNhUXKexrfMmBXIicLmKKs1S324r2D4b9GaXcmH3XlZZNztHD vaYM/pkIfNqu3pUXJZdTpQIQIjE6YiefkaVuyjtokTiQ5em6Id +Ka3PyY0qmMmEykYe4Uc= Cc: "json@ietf.org" Subject: Re: [Json] Encoding X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 06 Jun 2013 01:51:08 -0000 On 6/5/2013 6:21 PM, Paul Hoffman wrote: > On Jun 5, 2013, at 11:37 AM, Douglas Crockford wrote: > >> I think the section on encoding is not saying anything useful and should be completely removed. > The section is not saying anything useful, and it actually disagrees with the text from Section 6: > JSON may be represented using UTF-8, UTF-16, or UTF-32. When JSON > is written in UTF-8, JSON is 8bit compatible. When JSON is > written in UTF-16 or UTF-32, the binary content-transfer-encoding > must be used. > > Proposal: > > Change the title of Section 3 to "Encoding JSON on the Internet", and make the contents of the section: > > JSON texts sent on the Internet MUST be encoded as UTF-8 unless there is a definitive way for a recipient to definitively determine the encoding. > > --Paul Hoffman I think this belongs in the best practices doc. From mmorley@mpcm.com Wed Jun 5 18:56:09 2013 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 2C79721F9711 for ; Wed, 5 Jun 2013 18:56:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.377 X-Spam-Level: X-Spam-Status: No, score=-0.377 tagged_above=-999 required=5 tests=[FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qt64l6PnsRd0 for ; Wed, 5 Jun 2013 18:56:04 -0700 (PDT) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by ietfa.amsl.com (Postfix) with ESMTP id ADD7C21F8793 for ; Wed, 5 Jun 2013 18:56:03 -0700 (PDT) Received: by mail-lb0-f182.google.com with SMTP id r11so1470850lbv.41 for ; Wed, 05 Jun 2013 18:56:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :x-gm-message-state; bh=G3Zlp7uvzOZvDFdh3VpjsVLYHyF5miGJ3U1bya4I1OA=; b=QkcVRLZs9DEnlCARTEytXM89tpiDLW3H41mwREK/N3XMg8JJraiUqBxtyPN7IQ0Huo igeNpzFd99zixjntFJZwLEONYOqbXdlQmWekOTzX9EBoPcZQ2FfrndpbZi1WnV4w8B73 +wAclWqYhRfks7cIwVpIGTisqsoFHducWsfDP9/7JplygMgsimfJkvfJhC61Z01Esemg EP51nUO4gp8VkA7ze7PTRaObmrsTFVYo8gij0XWDSLQEEa23x4HgfRHYisvfwDPZAb39 to4kHzu7GQITpVVAd+GF9aqU1lyJ16TJMBHGD3C67cHiH4M4Twmsra3CeC2vKkmx7BkK sa5Q== MIME-Version: 1.0 X-Received: by 10.112.173.230 with SMTP id bn6mr1759263lbc.14.1370483762450; Wed, 05 Jun 2013 18:56:02 -0700 (PDT) Sender: mmorley@mpcm.com Received: by 10.114.160.69 with HTTP; Wed, 5 Jun 2013 18:56:02 -0700 (PDT) In-Reply-To: References: <51AF8479.5080002@crockford.com> <51AF8A9B.1020900@crockford.com> <51af8f23.85f8420a.597e.0ccbSMTPIN_ADDED_BROKEN@mx.google.com> <51afa4ff.89e9420a.6d90.212fSMTPIN_ADDED_BROKEN@mx.google.com> Date: Wed, 5 Jun 2013 21:56:02 -0400 X-Google-Sender-Auth: 3lBogcaXTE2me0ozJjqhjFzJV8E Message-ID: From: Matthew Morley To: Nico Williams Content-Type: multipart/alternative; boundary=001a11c23a62d4e50d04de729db5 X-Gm-Message-State: ALoCoQl1AhqJ5vQjiC5kdc+Vopl6AmbNNfKG6MlyUn107veGjL+Fx9k2SZeTO8qOzYclZ1v2dJbW Cc: Stephan Beal , Markus Lanthaler , "json@ietf.org" Subject: Re: [Json] The names within an object SHOULD be unique. X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 06 Jun 2013 01:56:09 -0000 --001a11c23a62d4e50d04de729db5 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Jun 5, 2013 at 7:19 PM, Nico Williams wrote: > On Wed, Jun 5, 2013 at 3:52 PM, Markus Lanthaler > wrote: > > I've seen people using this for comments. People relied on the fact that > serializers ignored all but the last occurrence of a key. > > Oh, this might actually be important. Perhaps the best way to handle > comments is to have the "schema" (if there is one, stated or > otherwise) specify some keys as being comments, but that doesn't help > for free-form data. > The best way to handle 'comments' is to have them be first class citizens in the data. It is a topic that goes back a long way, and since they were removed with intention then, using ambiguity in the specification to re-add them seems like a poor approach now. > If I were doing this duplicate-keys-for-comments thing and wanted to > ensure interop I'd triplicate them instead, with the value I actually > want decoded sent first and last, and the comment sandwiched in > between. Painful. > Like a poorly structure compliment sandwich... best avoided. ;) -- Matthew P. C. Morley --001a11c23a62d4e50d04de729db5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Jun 5, 2013 at 7:19 PM, Nico Williams <nico@c= ryptonector.com> wrote:
On Wed, Jun 5, 2013 at 3:5= 2 PM, Markus Lanthaler
<markus.lanthaler@gmx.net> wrote:
> I've seen people using this for comments. People relied on the fac= t that serializers ignored all but the last occurrence of a key.

Oh, this might actually be important. =A0Perhaps the best way to hand= le
comments is to have the "schema" (if there is one, stated or
otherwise) specify some keys as being comments, but that doesn't help for free-form data.

=A0
If I were doing this duplicate= -keys-for-comments thing and wanted to
ensure interop I'd triplicate them instead, with the value I actually want decoded sent first and last, and the comment sandwiched in
between. =A0Painful.

Like a poorly structure compl= iment sandwich... best avoided. ;)

--
Matthew P. C. = Morley
--001a11c23a62d4e50d04de729db5-- From douglas@crockford.com Wed Jun 5 18:57:30 2013 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 C998921F9925 for ; Wed, 5 Jun 2013 18:57:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id acNo87FIPS3n for ; Wed, 5 Jun 2013 18:57:24 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id E663921F8FB6 for ; Wed, 5 Jun 2013 18:57:23 -0700 (PDT) Received: from [192.168.0.108] (173-228-7-202.dsl.static.sonic.net [173.228.7.202]) by mrelay.perfora.net (node=mrus2) with ESMTP (Nemesis) id 0Lmrky-1UCB9e0D1g-00h7FZ; Wed, 05 Jun 2013 21:57:21 -0400 Message-ID: <51AFEC73.1030904@crockford.com> Date: Wed, 05 Jun 2013 18:57:07 -0700 From: Douglas Crockford User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Paul Hoffman References: <51AF9D4C.5060403@crockford.com> <60563185-85A8-4696-8B8C-9282256CFA71@vpnc.org> <255B9BB34FB7D647A506DC292726F6E1151B10582A@WSMSG3153V.srv.dir.telstra.com> <19943667-1EC6-427F-9122-EC037BDE47F1@vpnc.org> In-Reply-To: <19943667-1EC6-427F-9122-EC037BDE47F1@vpnc.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V02:K0:tUYjzgToHBOvJ/i46wsyDnKcw/ppA/eSmBeSDU9SPjh SFF+iYMZwf5qs37oQ8uZImFqoB8Ffxvx39b3i6ENYiKiVVwfpL Khys8mS5PN6e9DmiXeeEvqzZxz8u1A2BrHL+nVodNucI+F1RAZ yUhfXnUx9khLghwK3z6yUWWTukz6XFmVANGCNhm8XakL9wTgSt eNS8HICgfeZkfTYB/tPf7ju68Isi9p5WAhewR4oidRfwFjCFRM bHoY0QtmcTMo9w3De6ZV92KaSXGM8vXPkBMWy2n5TxAYvDZlQY EIvvXyk6OdiCWND7fRqHHYXNjvTY7Ng6Ep4lUZrMBDAloVbixE 7vWM86qX+OfbwRpcJ9lw= Cc: "Manger, James H" , "json@ietf.org" Subject: Re: [Json] Update reference for ABNF X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 06 Jun 2013 01:57:30 -0000 On 6/5/2013 6:22 PM, Paul Hoffman wrote: > On Jun 5, 2013, at 5:32 PM, "Manger, James H" wrote: > >> P.S. Another little fix: update reference to ABNF from RFC4234 to RFC5234. > Sounds good to me, as long as a few people promise to do a careful checking of that. > > --Paul Hoffman Why does this matter? Does RFC5234 offer us any better precision? From paul.hoffman@vpnc.org Wed Jun 5 19:00:35 2013 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 6A77A21F9942 for ; Wed, 5 Jun 2013 19:00:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.925 X-Spam-Level: X-Spam-Status: No, score=-99.925 tagged_above=-999 required=5 tests=[AWL=0.075, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R7JK8e-8LAnX for ; Wed, 5 Jun 2013 19:00:35 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 112E811E80E0 for ; Wed, 5 Jun 2013 19:00:33 -0700 (PDT) Received: from [10.20.30.90] (50-0-66-165.dsl.dynamic.sonic.net [50.0.66.165]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r561xZHR002952 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 5 Jun 2013 19:00:29 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Paul Hoffman In-Reply-To: <51AFEC73.1030904@crockford.com> Date: Wed, 5 Jun 2013 19:00:28 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <2484862A-4DFF-44D7-9D9D-7E44520C5BED@vpnc.org> References: <51AF9D4C.5060403@crockford.com> <60563185-85A8-4696-8B8C-9282256CFA71@vpnc.org> <255B9BB34FB7D647A506DC292726F6E1151B10582A@WSMSG3153V.srv.dir.telstra.com> <19943667-1EC6-427F-9122-EC037BDE47F1@vpnc.org> <51AFEC73.1030904@crockford.com> To: Douglas Crockford X-Mailer: Apple Mail (2.1508) Cc: json@ietf.org Subject: Re: [Json] Update reference for ABNF X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 06 Jun 2013 02:00:35 -0000 On Jun 5, 2013, at 6:57 PM, Douglas Crockford = wrote: > On 6/5/2013 6:22 PM, Paul Hoffman wrote: >> On Jun 5, 2013, at 5:32 PM, "Manger, James H" = wrote: >>=20 >>> P.S. Another little fix: update reference to ABNF from RFC4234 to = RFC5234. >> Sounds good to me, as long as a few people promise to do a careful = checking of that. >>=20 >> --Paul Hoffman > Why does this matter? Does RFC5234 offer us any better precision? No, but in the IETF, when one RFC is updated by another, there is an = expectation that a new RFC will always refer to the latter. --Paul Hoffman= From tsaloranta@gmail.com Wed Jun 5 19:07:06 2013 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 7EA2421F8A68 for ; Wed, 5 Jun 2013 19:07:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.6 X-Spam-Level: X-Spam-Status: No, score=0.6 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O1QpiH-iheMs for ; Wed, 5 Jun 2013 19:07:06 -0700 (PDT) Received: from mail-ee0-x231.google.com (mail-ee0-x231.google.com [IPv6:2a00:1450:4013:c00::231]) by ietfa.amsl.com (Postfix) with ESMTP id B626E21F8A03 for ; Wed, 5 Jun 2013 19:07:05 -0700 (PDT) Received: by mail-ee0-f49.google.com with SMTP id b57so858161eek.36 for ; Wed, 05 Jun 2013 19:07:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ILJmnFGDMSvaVpiPdAAa6LBtc0H5xJqOaur6hzMVkDU=; b=jepAonl38UqT+l3gMRQjHhye41Hw+Tpi3hnOkRLh1ZOmSa0Nv96H/5cyTa9fj6VYce NOK2GEYx/RKs2lKy6mPa7v6640RiXoQbgX1TboVzWWN61ZXjbIqTfTnh4CHFrKHJRMCW MowK7dowuC2nhiBQ++h21K8e+nsOI3Kj+55+QWYI+EbvoJ+bUdxuLStG1SzfL7ZxdKEr IkQpjHJOu4JvWO9KlpLAHsvHjDGZYx7XZkb/60q+cm005QQg9U+gyKFItH1Ax77U3qs0 MgGysO8B/FmGalTYWmoDKH0hnBhs6JmZ3vlpa5oWzjNaf1QwM4P0wgMOHTeGThq1bGnn 6uhQ== MIME-Version: 1.0 X-Received: by 10.180.86.38 with SMTP id m6mr8652581wiz.25.1370484424584; Wed, 05 Jun 2013 19:07:04 -0700 (PDT) Received: by 10.227.97.6 with HTTP; Wed, 5 Jun 2013 19:07:04 -0700 (PDT) In-Reply-To: References: <51AF8479.5080002@crockford.com> <51AF9ACF.5020507@cisco.com> Date: Wed, 5 Jun 2013 19:07:04 -0700 Message-ID: From: Tatu Saloranta To: Vinny A Content-Type: multipart/alternative; boundary=f46d044306424c359804de72c5e2 Cc: Douglas Crockford , Eliot Lear , "json@ietf.org" Subject: Re: [Json] The names within an object SHOULD be unique. X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 06 Jun 2013 02:07:06 -0000 --f46d044306424c359804de72c5e2 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Jun 5, 2013 at 1:59 PM, Vinny A wrote: > > On Jun 5, 2013, at 2:30 PM, Stephan Beal wrote: > > It gives implementations leeway on what is essentially a corner case (who > actively generates non-unique keys?). Forcing a specific behaviour here > could potentially leave a lot of current 100% JSON-compliant parsers > suddenly non-compliant because of [what i perceive as] an unusual corner > case. > > > If parsers are accepting duplicate keys, they're already non-compliant. > RFC 4627 states that keys should be unique, and the org.json reference > parser throws an exception when it hits a duplicate key (line 1186 in > JSONObject). > > Doing this is fine, but requiring verification is quite another thing. It opens a new possibility for DoS attacks, if parser (tokenizer) has to verify this invariant, as it must keep all seen names for all open objects in memory. From user perspective this also seems like pure overhead; and non-trivial amount as well, for fast data-binding maintaining hash set may take as much time as data-binding. -+ Tatu +- --f46d044306424c359804de72c5e2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Jun 5, 2013 at 1:59 PM, Vinny A = <jsontest@yahoo.= com> wrote:

On Jun 5, 2013, at 2:30 = PM, Stephan Beal <sgbeal@googlemail.com> wrote:
It gives implementations leeway on = what is essentially a corner case (who actively generates non-unique keys?)= . Forcing a specific behaviour here could potentially leave a lot of curren= t 100% JSON-compliant parsers suddenly non-compliant because of [what i per= ceive as] an unusual corner case.

If parsers are accepting duplicat= e keys, they're already non-compliant. RFC 4627 states that keys should= be unique, and the org.json reference parser throws an exception when it h= its a duplicate key (line 1186 in JSONObject).


Doing t= his is fine, but requiring verification is quite another thing. It opens a = new possibility for DoS attacks, if parser (tokenizer) has to verify this i= nvariant, as it must keep all seen names for all open objects in memory. Fr= om user perspective this also seems like pure overhead; and non-trivial amo= unt as well, for fast data-binding maintaining hash set may take as much ti= me as data-binding.

-+ Tatu +-
=A0
<= /div> --f46d044306424c359804de72c5e2-- From jhildebr@cisco.com Wed Jun 5 20:35:50 2013 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 F038421F8FEC for ; Wed, 5 Jun 2013 20:35:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yCD4Sm0+LTtJ for ; Wed, 5 Jun 2013 20:35:44 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 638F121F8F83 for ; Wed, 5 Jun 2013 20:35:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=436; q=dns/txt; s=iport; t=1370489744; x=1371699344; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=uyXPEKThNRmMZQFJ5i8ABPunMjzsfDWOA6Z6era2EVM=; b=F/ivrogLetv5/ACWyOJTcYfbasLXk4nfQ3QQAZg2BQBTVL+uDQ6YKPY4 BNoBo53HuMv8g5jw/4R4xnn4IkoCYor0GZ+n2chJUnq+/0m0F1kxWVYdf cYxuWnyuzYY0iURL7HFWcDG8vx0KeuLvfreI2br9Q5pfzNu+A83G+isFi U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AocFAIICsFGtJV2Y/2dsb2JhbABZgwmDJbxLfhZ0giUBBDpRAQgiFEIlAgQBEgiIBbw6jno4gnphA6h/gw+CJw X-IronPort-AV: E=Sophos;i="4.87,811,1363132800"; d="scan'208";a="219364997" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-7.cisco.com with ESMTP; 06 Jun 2013 03:35:44 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r563Zh7G001582 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 6 Jun 2013 03:35:43 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.56]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.02.0318.004; Wed, 5 Jun 2013 22:35:43 -0500 From: "Joe Hildebrand (jhildebr)" To: Paul Hoffman , "json@ietf.org" Thread-Topic: [Json] Strings Thread-Index: AQHOYks3qXYMVZxHuUK8pIRm8dGJzZkn+HmA Date: Thu, 6 Jun 2013 03:35:43 +0000 Message-ID: In-Reply-To: <60563185-85A8-4696-8B8C-9282256CFA71@vpnc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [10.21.147.108] Content-Type: text/plain; charset="us-ascii" Content-ID: <04932E729D6BF742BF498FA6CC46DFE5@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Json] Strings X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 06 Jun 2013 03:35:50 -0000 On 6/5/13 6:14 PM, "Paul Hoffman" wrote: >Proposed wording: just before the ABNF at the end of section 2.5, add: > >When comparing strings, escaped characters SHOULD compare the same as >their unescaped counterparts. For example, the following three strings >SHOULD be considered equivalent for comparisons: Are you sure you want to open pandora's box of comparing strings? --=20 Joe Hildebrand From jhildebr@cisco.com Wed Jun 5 20:45:04 2013 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 E39E721F9485 for ; Wed, 5 Jun 2013 20:45:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UvObtJX-WikJ for ; Wed, 5 Jun 2013 20:44:59 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 39D5821F944F for ; Wed, 5 Jun 2013 20:44:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=467; q=dns/txt; s=iport; t=1370490299; x=1371699899; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=URK7ct46/2huPh+Bv6o+cDZzM+YFJHaMG4URwxPbqsE=; b=bL+eSKOPmEJ94IUg1rtFl5N0RcqSFUu+Qp5TkZSm5rm0JUUjCc518mW4 gUjXkzI5lcJYmprNaKvPLNPR3rtYUyX57H0n4HsteX9QLZRQwZonx0TzU 8funJLDhcRuFMKCJY0LEuv5uitHHHTOTRHEXCCk5hBflWk/0ckxt3fXd5 Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AogFAGYFsFGtJXHB/2dsb2JhbABZgwmDJbxLfhZ0giUBBDo/EgEIDhQUQiUCBAENBQiIBbw3jnoxB4J6YQOof4MPgic X-IronPort-AV: E=Sophos;i="4.87,811,1363132800"; d="scan'208";a="219381119" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-5.cisco.com with ESMTP; 06 Jun 2013 03:44:53 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r563irWH020273 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 6 Jun 2013 03:44:53 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.56]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.02.0318.004; Wed, 5 Jun 2013 22:44:53 -0500 From: "Joe Hildebrand (jhildebr)" To: Matthew Morley , Nico Williams Thread-Topic: [Json] The names within an object SHOULD be unique. Thread-Index: AQHOYlj/f+f4Zs3CA0O//LSHQrFFDJkn+vCA Date: Thu, 6 Jun 2013 03:44:53 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [10.21.147.108] Content-Type: text/plain; charset="us-ascii" Content-ID: <68B02348ECCED7458B0AFFB8336A2535@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Stephan Beal , Markus Lanthaler , "json@ietf.org" Subject: Re: [Json] The names within an object SHOULD be unique. X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 06 Jun 2013 03:45:05 -0000 On 6/5/13 7:56 PM, "Matthew Morley" wrote: >The best way to handle 'comments' is to have them be first class citizens >in the data. It is a topic that goes back a long way, and since they were >removed with intention then, using ambiguity in the specification to >re-add them seems like a poor approach > now. Do you have a backward-compatible proposal? I can't think of one, but that doesn't make it impossible. --=20 Joe Hildebrand From nico@cryptonector.com Wed Jun 5 20:51:43 2013 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 EBE0521F8ADC for ; Wed, 5 Jun 2013 20:51:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cm9i8Fr1IFkx for ; Wed, 5 Jun 2013 20:51:38 -0700 (PDT) Received: from homiemail-a73.g.dreamhost.com (caiajhbdcaib.dreamhost.com [208.97.132.81]) by ietfa.amsl.com (Postfix) with ESMTP id 8B7E121F856D for ; Wed, 5 Jun 2013 20:51:38 -0700 (PDT) Received: from homiemail-a73.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a73.g.dreamhost.com (Postfix) with ESMTP id 414491F0081 for ; Wed, 5 Jun 2013 20:51:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=RA92WPyl1o9IGklrDKf2 PJX5pG8=; b=qrxJTG72+cwRJujqN6eWZaCAqD0Gr6n5D4Xl01eoJR9WU1lfdJsN fHHdE2Qg2Wc1QPgSrRemhyZ6x0aMWTVhjCEBWPcWZVj78wyEmPKK/EQmORiEhSVo 9nE+F4OY6vHY1bYXhMKXeLeoN0XvEJHflTsnk/QAXNWYqDiPQcm7g8Y= Received: from mail-ea0-f171.google.com (mail-ea0-f171.google.com [209.85.215.171]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a73.g.dreamhost.com (Postfix) with ESMTPSA id DC0911F0078 for ; Wed, 5 Jun 2013 20:51:37 -0700 (PDT) Received: by mail-ea0-f171.google.com with SMTP id m14so2193205eaj.30 for ; Wed, 05 Jun 2013 20:51:36 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=1EGvDgl2bZqceAXWrVkmeAuZ+/tqku5UsHBjgmuUVK4=; b=i6e4ZIbUO/5NrzeZA7gZ/O8IACBUR/P5GiBaVZZ9yzrRpqk5oOJspycup0IvmfxqhP 1+8q97IoT7OidAKMHSBv2kewl45tyuEMQ+dAknTmUEeu7hGzw376xXyezqHK4Mn9Iquw HXEbAahHx80+OjLB8oKth8z9Lgb1Gs/aKNTitaaUHs0G+2PkBfcm1zrqneVz0RIXSu4D 63TdPGIeFNFq+qRmQNAM2HkqtIn+MBwlPvWcRs0ICSIfJSXgOi4886u/oOS2G71iggRb 9719lnryaq6W+Y7rF9/WlGL8rywBFvngCUPFQFecxdxu2MgADrXiLRcCoUFuucY63w22 9d2w== MIME-Version: 1.0 X-Received: by 10.180.183.139 with SMTP id em11mr8542108wic.16.1370490696243; Wed, 05 Jun 2013 20:51:36 -0700 (PDT) Received: by 10.216.63.136 with HTTP; Wed, 5 Jun 2013 20:51:36 -0700 (PDT) In-Reply-To: References: <60563185-85A8-4696-8B8C-9282256CFA71@vpnc.org> Date: Wed, 5 Jun 2013 22:51:36 -0500 Message-ID: From: Nico Williams To: "Joe Hildebrand (jhildebr)" Content-Type: text/plain; charset=UTF-8 Cc: Paul Hoffman , "json@ietf.org" Subject: Re: [Json] Strings X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 06 Jun 2013 03:51:43 -0000 On Wed, Jun 5, 2013 at 10:35 PM, Joe Hildebrand (jhildebr) wrote: > On 6/5/13 6:14 PM, "Paul Hoffman" wrote: > >>Proposed wording: just before the ABNF at the end of section 2.5, add: >> >>When comparing strings, escaped characters SHOULD compare the same as >>their unescaped counterparts. For example, the following three strings >>SHOULD be considered equivalent for comparisons: > > > Are you sure you want to open pandora's box of comparing strings? Object key lookup is of comparable complexity to string comparison, and rather fundamental to any use of JSON. So, yes, we may have to say something. Like that all-ASCII, all-printable, non-backslash keys have a single canonical form, and then leave the rest unspecified. I wish Unicode normalization were cheap and code for it plentiful. The latter is only just starting to be the case. Well, normalization-insensitive comparison/hashing of mostly-ASCII strings can actually be quite fast. BTW, stedolan.github.io/jq is a really nifty JSON *filter* language (a bit of XPath and XSLT, but for JSON, so highly simplified). Unsurprisingly jq lets users do JSON value comparisons, including string comparisons. Also unsurprisingly, it has no concept of Unicode normalization. Nico -- From cowan@ccil.org Wed Jun 5 20:58:58 2013 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 6EA3521F8F9E for ; Wed, 5 Jun 2013 20:58:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UHsZ2ycHhq+U for ; Wed, 5 Jun 2013 20:58:54 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id 212EA21F8D79 for ; Wed, 5 Jun 2013 20:58:54 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1UkRLf-0000Rv-HX; Wed, 05 Jun 2013 23:58:51 -0400 Date: Wed, 5 Jun 2013 23:58:51 -0400 From: John Cowan To: Douglas Crockford Message-ID: <20130606035851.GB1362@mercury.ccil.org> References: <20130605162246.GG3680@mercury.ccil.org> <51AF7988.6040009@crockford.com> <20130605184702.GB6999@mercury.ccil.org> <51AF8A09.50806@crockford.com> <51AFE107.7020301@crockford.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <51AFE107.7020301@crockford.com> User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Cc: Tim Bray , Paul Hoffman , "json@ietf.org" Subject: Re: [Json] Unpaired surrogates in JSON strings X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 06 Jun 2013 03:58:58 -0000 Douglas Crockford scripsit: > When the RFC talks about Unicode Characters, it is in the sense > of Unicode Characters and not EBCDIC Characters. That's just confusing. "Unicode character" means something quite definite in Unicode. If you mean "character in the Unicode repertoire", that's fine -- but all EBCDIC characters, in all variants of EBCDIC, are just a subset of that. There seems to me no reason why JSON couldn't be encoded in EBCDIC, with appropriate escapes. -- John Cowan cowan@ccil.org http://ccil.org/~cowan In computer science, we stand on each other's feet. --Brian K. Reid From sayrer@gmail.com Wed Jun 5 21:06:18 2013 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 1353121F84D8 for ; Wed, 5 Jun 2013 21:06:18 -0700 (PDT) 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=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZNMuqAOYAn+4 for ; Wed, 5 Jun 2013 21:06:17 -0700 (PDT) Received: from mail-ee0-x229.google.com (mail-ee0-x229.google.com [IPv6:2a00:1450:4013:c00::229]) by ietfa.amsl.com (Postfix) with ESMTP id 3E29321F84D4 for ; Wed, 5 Jun 2013 21:06:17 -0700 (PDT) Received: by mail-ee0-f41.google.com with SMTP id d4so950758eek.0 for ; Wed, 05 Jun 2013 21:06:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=smQJuINsTs7s+YMNBLAh+hblwYJY0zbRtUKs/HwxWTE=; b=fdpXqW3OWAi/7ORdiRm7zqNsAjgoqjLsT2JKNGcpQfd9RqgLf1yz02HAS1UPYcKxAv svCTH/mtBIh5N1csVAJMdsUwmZ32ViYcVIPdEtqiu2kuqVA6KsCjM2jFh8hsfS0DF+hk kkJvmA0ivgNuCiDio54GsbZojAZX0rjWvBD/1lUFLQ98ga4vSNNUGMdZK1xgrpr3fZgk 1Ujhocri55vt4RaB0gPqAKOv5E2i4e3mcAXXJ2Fobg1b8mnguiAoT3SeAS9uyKv+to73 t5bEdh+/qltRQZgb3QYqGiaj72kVCECaDO16qjjVhx7Xrs1i3q/LYvFrCpvDZ1kl0nhx VMqQ== MIME-Version: 1.0 X-Received: by 10.194.249.231 with SMTP id yx7mr20477893wjc.13.1370491576346; Wed, 05 Jun 2013 21:06:16 -0700 (PDT) Received: by 10.194.83.35 with HTTP; Wed, 5 Jun 2013 21:06:16 -0700 (PDT) In-Reply-To: <20130606035851.GB1362@mercury.ccil.org> References: <20130605162246.GG3680@mercury.ccil.org> <51AF7988.6040009@crockford.com> <20130605184702.GB6999@mercury.ccil.org> <51AF8A09.50806@crockford.com> <51AFE107.7020301@crockford.com> <20130606035851.GB1362@mercury.ccil.org> Date: Wed, 5 Jun 2013 21:06:16 -0700 Message-ID: From: R S To: John Cowan Content-Type: multipart/alternative; boundary=001a11c29cc4936f1d04de746fe8 Cc: Tim Bray , Paul Hoffman , Douglas Crockford , "json@ietf.org" Subject: Re: [Json] Unpaired surrogates in JSON strings X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 06 Jun 2013 04:06:18 -0000 --001a11c29cc4936f1d04de746fe8 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Jun 5, 2013 at 8:58 PM, John Cowan wrote: > Douglas Crockford scripsit: > > > When the RFC talks about Unicode Characters, it is in the sense > > of Unicode Characters and not EBCDIC Characters. > > That's just confusing. Maybe, but I think we want to specify whatever it is browsers do with JSON in this case. That amounts to billions of daily active C++ client users. - Rob --001a11c29cc4936f1d04de746fe8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Wed, Jun 5, 2013 at 8:58 PM, John Cowan <cowan@mercury.cci= l.org> wrote:
Douglas Crockford scripsit:

> When the RFC talks about Unicode Characters, it is in the sense
> of Unicode Characters =A0and not EBCDIC Characters.

That's just confusing. =A0

Maybe, but I think we want= to specify whatever it is browsers do with JSON in this case. That amounts= to billions of daily active C++ client users.

<= span style=3D"font-family:arial,sans-serif;font-size:13px">- Rob=A0<= /div>
--001a11c29cc4936f1d04de746fe8-- From cabo@tzi.org Wed Jun 5 21:17:42 2013 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 6F8A111E80D3 for ; Wed, 5 Jun 2013 21:17:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x-eOL+rzwE-u for ; Wed, 5 Jun 2013 21:17:36 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 56CF111E80E4 for ; Wed, 5 Jun 2013 21:17:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r564HSQs009111; Thu, 6 Jun 2013 06:17:28 +0200 (CEST) Received: from [10.139.14.114] (unknown [88.128.80.12]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 04870390E; Thu, 6 Jun 2013 06:17:27 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <83728898-9A2D-4758-9C06-1157E2954CCB@vpnc.org> Date: Thu, 6 Jun 2013 06:17:27 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <1A39ACCF-4B4D-4F69-9D97-ECEF1BB41D47@tzi.org> References: <83728898-9A2D-4758-9C06-1157E2954CCB@vpnc.org> To: Paul Hoffman X-Mailer: Apple Mail (2.1503) Cc: "json@ietf.org" Subject: Re: [Json] Unpaired surrogates in JSON strings X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 06 Jun 2013 04:17:42 -0000 On Jun 6, 2013, at 02:58, Paul Hoffman wrote: > Code points That is a confusing term here, and I have a hard time understanding what = people are trying to say. Code points can refer to those of the characters or those of the code = units (byte for UTF-8, etc.). Please be specific which of the ones you mean. RFC 4627 normatively references RFC 4234, which makes very clear that it = is about characters. This is further reinforced by the grammar in RFC 4627, which addresses = code points up to %x10FFFF -- clearly it is about the Unicode characters = (an assessment that also agrees with the rest of the text). 1) Surrogates are not characters, so they can't appear in the source = character set. 2) Within strings, escape sequences can be used to construct surrogates = from ASCII characters. This contradicts the definition of strings in = section 1. However, the usage of this escape sequences to represent = arbitrary binary data appears to be common enough (JavaScript only = recently grew support for binary data, and this support will not be = retrofit into JSON) that a clarification in the specification is = required. Please separate these two items clearly. Thanks. Gr=FC=DFe, Carsten From cowan@ccil.org Wed Jun 5 21:29:28 2013 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 2B18C21F8CF4 for ; Wed, 5 Jun 2013 21:29:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.949 X-Spam-Level: X-Spam-Status: No, score=-2.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M-irxcco9jy1 for ; Wed, 5 Jun 2013 21:29:23 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id CF52521F8613 for ; Wed, 5 Jun 2013 21:29:23 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1UkRpB-0003cS-QZ; Thu, 06 Jun 2013 00:29:22 -0400 Date: Thu, 6 Jun 2013 00:29:21 -0400 From: John Cowan To: Carsten Bormann Message-ID: <20130606042921.GC1362@mercury.ccil.org> References: <83728898-9A2D-4758-9C06-1157E2954CCB@vpnc.org> <1A39ACCF-4B4D-4F69-9D97-ECEF1BB41D47@tzi.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1A39ACCF-4B4D-4F69-9D97-ECEF1BB41D47@tzi.org> User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Cc: Paul Hoffman , "json@ietf.org" Subject: Re: [Json] Unpaired surrogates in JSON strings X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 06 Jun 2013 04:29:28 -0000 Carsten Bormann scripsit: > Code points can refer to those of the characters or those of the code > units (byte for UTF-8, etc.). Code points are (mathematical) integers corresponding to Unicode characters, though not all of them are assigned to characters. Code *units* are 8-bit, 16-bit, or 32-bit values corresponding to the components of a particular encoding. A single code point is represented by one or more code units. -- Go, and never darken my towels again! John Cowan --Rufus T. Firefly http://ccil.org/~cowan From duerst@it.aoyama.ac.jp Wed Jun 5 21:30:26 2013 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 CCBD511E80D3 for ; Wed, 5 Jun 2013 21:30:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.79 X-Spam-Level: X-Spam-Status: No, score=-103.79 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id au0KbIMGwGcN for ; Wed, 5 Jun 2013 21:30:20 -0700 (PDT) Received: from scintmta02.scbb.aoyama.ac.jp (scintmta02.scbb.aoyama.ac.jp [133.2.253.34]) by ietfa.amsl.com (Postfix) with ESMTP id 0DD3321F8613 for ; Wed, 5 Jun 2013 21:30:19 -0700 (PDT) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id r564UAIs009987; Thu, 6 Jun 2013 13:30:10 +0900 Received: from (unknown [133.2.206.134]) by scmse02.scbb.aoyama.ac.jp with smtp id 3a18_0186_c62f93d0_ce61_11e2_aaec_001e6722eec2; Thu, 06 Jun 2013 13:30:10 +0900 Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id E2142C0234; Thu, 6 Jun 2013 13:29:03 +0900 (JST) Message-ID: <51B01042.5020101@it.aoyama.ac.jp> Date: Thu, 06 Jun 2013 13:29:54 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: Douglas Crockford References: <51AF8575.5060706@crockford.com> <51AF9E06.7040208@crockford.com> In-Reply-To: <51AF9E06.7040208@crockford.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Jacob Davies , Tatu Saloranta , "json@ietf.org" Subject: Re: [Json] Encoding X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 06 Jun 2013 04:30:26 -0000 Hello Douglas, others, On 2013/06/06 5:22, Douglas Crockford wrote: > On 6/5/2013 1:18 PM, Tatu Saloranta wrote: >> I thought it is among more useful parts, as it points out that >> auto-detection is easy to do. It is similar to XML spec's >> (non-authoritative) part in how XML encoding is to be detected. >> > I am not aware of any implementation that does that detection. Everyone > uses UTF-8, at least on the wire. That is a practice that is so well > established now that I don't think the format needs to mention it. I'm not exactly a JSON expert, but think about how you would react if somebody said something like: "In JSON, everybody uses '[' and ']' for arrays, and '{' and '}' for objects. This is a practice that is so well established now that I don't think the format needs to mention it." As I hope this example shows, even if something is extremely well established, if it is part of interoperability, it better be clearly documented. I agree with the assessment that character encoding is less of a mess these days than it was when the first RFC was written, but I'd rather have one nail too many in the coffin of that mess than one nail too few! Regards, Martin. From tsaloranta@gmail.com Wed Jun 5 21:35:54 2013 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 AEB0811E80F6 for ; Wed, 5 Jun 2013 21:35:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.465 X-Spam-Level: X-Spam-Status: No, score=-0.465 tagged_above=-999 required=5 tests=[AWL=1.065, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_SXLIFE=1.07] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 64657beY5jn7 for ; Wed, 5 Jun 2013 21:35:54 -0700 (PDT) Received: from mail-ea0-x235.google.com (mail-ea0-x235.google.com [IPv6:2a00:1450:4013:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id 83B7B11E80E7 for ; Wed, 5 Jun 2013 21:35:53 -0700 (PDT) Received: by mail-ea0-f181.google.com with SMTP id a11so2201900eae.26 for ; Wed, 05 Jun 2013 21:35:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=XPcHCHk+77oO3PLM97MzK/AiDayomPlSE//YG7IXOo4=; b=oGXQrS1b37Np1CGDzqRpxyA8mMwxFhoGmVcxNQDlekQcLotEwSfBS91jOs7MB+pDS9 8CUkVzTvVoLC+IJUir7VbL2BpRaaEXMo5IyK8SRL2zVDme188ABt+y8k6A5HkSEyfDnK O4BxvJRITpdVm8DVsjUpqosKsT8KRFtmojXNmiGlkRX5xhy/Gg8NnC+k8tJh284WdYI4 0LG2m1kFfzswMS7E+qBHKXzP68jpu8bAwVz93QCigdcP7lhpYdXxfkpH7p3IZxtv7hpK 07sqzcHDLOouxkq2+Ic9HrLLBZzOEtmTDOEnf1E7PJNHK7syrXoywhyBnmRoef3NteWB AwlA== MIME-Version: 1.0 X-Received: by 10.180.185.225 with SMTP id ff1mr8532706wic.36.1370493352628; Wed, 05 Jun 2013 21:35:52 -0700 (PDT) Received: by 10.227.97.6 with HTTP; Wed, 5 Jun 2013 21:35:52 -0700 (PDT) In-Reply-To: References: <51AF8575.5060706@crockford.com> Date: Wed, 5 Jun 2013 21:35:52 -0700 Message-ID: From: Tatu Saloranta To: Jacob Davies Content-Type: multipart/alternative; boundary=001a11c34ed273579a04de74d984 Cc: "json@ietf.org" Subject: Re: [Json] Encoding X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 06 Jun 2013 04:35:54 -0000 --001a11c34ed273579a04de74d984 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Jun 5, 2013 at 2:16 PM, Jacob Davies wrote: > On Wed, Jun 5, 2013 at 1:18 PM, Tatu Saloranta > wrote: > > Allowing character encodings other than existing ones (UTF-8/16/32) > would be a breaking change -- compliant libraries currently can count on > simple and reliable auto-detection -- and I can not see how use of other > encodings (except for special case of ASCII, as that simply falls within > UTF-8 umbrella) would be considered compliant currently. > > The point is that the entire discussion of encoding is irrelevant other > than assuming UTF-8 if no encoding is specified. The language should not be > concerned with the binary representation of the characters it is written. I > can write a perfectly valid JSON text on paper with a pen, including > non-ASCII Unicode characters in a string. Am I a non-compliant > implementation? > > If starting from scratch, I would agree. But we are not. Existing JSON specification explicitly mandates that any byte sequence serialization of JSON MUST be in one of sanctioned unicode encodings. Your pen and paper case is not covered by JSON specification; I don't care how you'd do it. But when that JSON goes on the wire, or stored on file system, it better use one of legal Unicode encodings and nothing else. This simplifies handling a lot, based on my work on writing tools (parser, generators, databinding) and on supporting developers who do. Amount of encoding issues with JSON is remarkably low, all things considered. > I think you can simply talk about JSON as a language consisting of a > series of characters drawn from the basic JSON alphabet, except inside > quoted string values that may not contain a small set of whitespace and > control characters, but may contain other literal characters. Reading a > JSON text produces a model containing nulls, booleans, numbers (of > unspecified representation), Unicode strings, arrays, and objects. Worrying > about whether the input text contained the literal bytes f09f98bf instead > of d83dde3f or a hand-drawn crying cat face on paper isn't necessary (and > irrelevant in those environments where the encoding is interpreted at a > level below that of JSON parsing). > > You could, but this is a big backwards-incompatible change that affects _existing_ libraries and use cases. If one can not assume simple and reliable encoding detection, encoding must now be provided as external metadata. Decoding characters from byte stream is not necessarily below parser (for performance reasons one often wants to bundle things); but more importantly something has to handle it. And with redefinition that task becomes bigger issue. > I do not believe it has any effect on compliance or interoperability since > there is no existing requirement that all encodings or all possible > documents be accepted. (I doubt many implementations handle UTF-32 in the > absence of an external encoding specification, for instance.) All that the > current wording on encoding winds up saying is that a bunch of potentially > useful things that unambiguously work are not compliant (e.g. two parties > agreeing to put JSON in EBCDIC text columns in DB2 as long as they escape > everything outside the basic JSON alphabet). > > The requirement that you assume UTF-8 unless you have agreed on another > encoding by some external channel should be enough to unambiguously > interpret any series of bytes that claims to be JSON without an encoding > specified. If you agree on some other binary encoding with your partner, > that's not the business of the specification. > I think assumption that the default encoding (in absence of other information) is UTF-8 would be sensible, regardless of other questions. -+ Tatu +- --001a11c34ed273579a04de74d984 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Jun 5, 2013 at 2:16 PM, Jacob Davies <jacob@well.com= > wrote:
On Wed, Jun 5, 2013 at 1:18 PM, Tatu Sal= oranta <tsalor= anta@gmail.com> wrote:
> Allowing character encodings other th= an existing ones (UTF-8/16/32) would be a breaking change -- compliant libr= aries currently can count on simple and reliable auto-detection -- and I ca= n not see how use of other encodings (except for special case of ASCII, as = that simply falls within UTF-8 umbrella) would be considered compliant curr= ently.

The point is that the entire discussion of encoding is irrelevant= other than assuming UTF-8 if no encoding is specified. The language should= not be concerned with the binary representation of the characters it is wr= itten. I can write a perfectly valid JSON text on paper with a pen, includi= ng non-ASCII Unicode characters in a string. Am I a non-compliant implement= ation?


If starting from scratch, = I would agree. But we are not.

Existin= g JSON specification explicitly mandates that any byte sequence serializati= on of JSON MUST be in one of sanctioned unicode encodings. Your pen and pap= er case is not covered by JSON specification; I don't care how you'= d do it. But when that JSON goes on the wire, or stored on file system, it = better use one of legal Unicode encodings and nothing else.
This simplifies handling a lot, based on my work on writing tool= s (parser, generators, databinding) and on supporting developers who do. Am= ount of encoding issues with JSON is remarkably low, all things considered.=

=A0
I think you can simply talk about JSON as a language consisting of= a series of characters drawn from the basic JSON alphabet, except inside q= uoted string values that may not contain a small set of whitespace and cont= rol characters, but may contain other literal characters. Reading a JSON te= xt produces a model containing nulls, booleans, numbers (of unspecified rep= resentation), Unicode strings, arrays, and objects. Worrying about whether = the input text contained the literal bytes f09f98bf instead of d83dde3f or = a hand-drawn crying cat face on paper isn't necessary (and irrelevant i= n those environments where the encoding is interpreted at a level below tha= t of JSON parsing).


You could, but = this is a big backwards-incompatible change that affects _existing_ librari= es and use cases. If one can not assume simple and reliable encoding detect= ion, encoding must now be provided as external metadata.

Decoding characters from byte stream is not= necessarily below parser (for performance reasons one often wants to bundl= e things); but more importantly something has to handle it.
And with redefinition that task becomes bigger issue.

<= div>=A0
I do not believe it has any effect on compliance or interoperability sinc= e there is no existing requirement that all encodings or all possible docum= ents be accepted. (I doubt many implementations handle UTF-32 in the absenc= e of an external encoding specification, for instance.) All that the curren= t wording on encoding winds up saying is that a bunch of potentially useful= things that unambiguously work are not compliant (e.g. two parties agreein= g to put JSON in EBCDIC text columns in DB2 as long as they escape everythi= ng outside the basic JSON alphabet).
The requirement that you assume UTF-8 unless you have agreed on= another encoding by some external channel should be enough to unambiguousl= y interpret any series of bytes that claims to be JSON without an encoding = specified. If you agree on some other binary encoding with your partner, th= at's not the business of the specification.

I think assumption that the de= fault encoding (in absence of other information) is UTF-8 would be sensible= , regardless of other questions.

-+ Tatu +-<= /div>
=A0
--001a11c34ed273579a04de74d984-- From tbray@textuality.com Wed Jun 5 21:41:20 2013 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 0016421F961B for ; Wed, 5 Jun 2013 21:41:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.79 X-Spam-Level: X-Spam-Status: No, score=0.79 tagged_above=-999 required=5 tests=[AWL=-0.567, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hl5wmfgKhgZx for ; Wed, 5 Jun 2013 21:41:15 -0700 (PDT) Received: from mail-vb0-x22e.google.com (mail-vb0-x22e.google.com [IPv6:2607:f8b0:400c:c02::22e]) by ietfa.amsl.com (Postfix) with ESMTP id BB64121F9600 for ; Wed, 5 Jun 2013 21:41:15 -0700 (PDT) Received: by mail-vb0-f46.google.com with SMTP id 10so1622203vbe.19 for ; Wed, 05 Jun 2013 21:41:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=4jfzkE6Tw+i7xm/v0MLqA0HglODZ5bLi1NnDyJsby+E=; b=aUhNLMEO5Ogmo0FNeJ1/iuZqY5ECQQ4LvcplLBXkIsGXaSj3r38ZrfraBXKdxGJgX2 WJ4o4GIEBQ6BJjlFOhRWtp9D+yuOlYCg3szfpKapL4sD9Jp/T2o6YeHeE+IZ+BUyv+UP 5uADf113Ual7ASXJkhkXfz6xpN+lJBHRFKuLRCFzO4JMfhYD1P3dxLcHjzBEyJFE5hi9 RXBaegxOctneSvP/fXdnQCckVipMWDPIcNcPdqMnvuCZ6X+tVbf5LBa/RAIoGwhZ87Er LgwwPy+E2AIVwDCNQ6Vyv404hhjqxBy08/zKJc5q2HffbqWa4V6tXkzD6jIB4Q3iI18e cZTA== MIME-Version: 1.0 X-Received: by 10.59.3.198 with SMTP id by6mr21754923ved.39.1370493674937; Wed, 05 Jun 2013 21:41:14 -0700 (PDT) Received: by 10.220.48.14 with HTTP; Wed, 5 Jun 2013 21:41:14 -0700 (PDT) X-Originating-IP: [24.84.235.32] In-Reply-To: References: <60563185-85A8-4696-8B8C-9282256CFA71@vpnc.org> Date: Wed, 5 Jun 2013 21:41:14 -0700 Message-ID: From: Tim Bray To: "Joe Hildebrand (jhildebr)" Content-Type: multipart/alternative; boundary=089e0122ac60a9733b04de74ecc6 X-Gm-Message-State: ALoCoQms55n5XRQUXI8FGURdbHmz5W5ulMQ7KSw8AeHUApfk8nyQV1ZmzQZQHdGMY1kAmM1u6wYN Cc: Paul Hoffman , "json@ietf.org" Subject: Re: [Json] Strings X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 06 Jun 2013 04:41:20 -0000 --089e0122ac60a9733b04de74ecc6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Jun 5, 2013 at 8:35 PM, Joe Hildebrand (jhildebr) < jhildebr@cisco.com> wrote: > Are you sure you want to open pandora's box of comparing strings? > +1. I don=E2=80=99t think we need go there. -T > > -- > Joe Hildebrand > > > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > --089e0122ac60a9733b04de74ecc6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Jun 5, 2013 at 8:35 PM, Joe Hildebrand (jhildebr) = <jhildebr@cisco.com> wrote:
<= div class=3D"gmail_quote">
Are you sure you want to open pandora's = box of comparing strings?

+1. I don=E2= =80=99t think we need go there. -T
=C2=A0

--
Joe Hildebrand



_______________________________________________
json mailing list
json@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/json

--089e0122ac60a9733b04de74ecc6-- From tbray@textuality.com Wed Jun 5 21:48:40 2013 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 A0E9921F961F for ; Wed, 5 Jun 2013 21:48:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.073 X-Spam-Level: * X-Spam-Status: No, score=1.073 tagged_above=-999 required=5 tests=[AWL=-0.283, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rdo577MOdfac for ; Wed, 5 Jun 2013 21:48:36 -0700 (PDT) Received: from mail-ve0-x234.google.com (mail-ve0-x234.google.com [IPv6:2607:f8b0:400c:c01::234]) by ietfa.amsl.com (Postfix) with ESMTP id 3682821F961B for ; Wed, 5 Jun 2013 21:48:36 -0700 (PDT) Received: by mail-ve0-f180.google.com with SMTP id pa12so1843315veb.39 for ; Wed, 05 Jun 2013 21:48:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=s1wjAq4Z5EIhZbThj39tmAdHITrDRuciPzNEZ/z+yzY=; b=k7E6aa3RD+y59RSguoz4cWZPm1F1QE7Uwu799iGCUxQhccYJ3iE9Yli9juCNZbJC1D mnkix9oP4rekzjy9TlEYxW70G4pu9Gg1y4HaWyUQ3Bm1L3HCH2fGCGy8qAqEX60yEAN0 8EsWe8NP32ywL8G+QAkF7YV1rJyNmbD0wz5mqgBGhHLE3QGI3yD4WWtlWYEHTejZ6zbc L0KXKMTdVnuYIM/GGE4oWmaL0b+qA9Dd/vOoIzPjU3Pg2B67kCMs1NRbkYZkXOGUPudo hBGS1nygNgOzWrJhdCnwATnvCZFFUc2AQwGp/1fD0N4kTHwBMv1IBj3d2+ZeWnPUpSqw VtbA== MIME-Version: 1.0 X-Received: by 10.52.112.5 with SMTP id im5mr2883959vdb.4.1370494115603; Wed, 05 Jun 2013 21:48:35 -0700 (PDT) Received: by 10.220.48.14 with HTTP; Wed, 5 Jun 2013 21:48:35 -0700 (PDT) X-Originating-IP: [24.84.235.32] In-Reply-To: <20130606010945.GA1362@mercury.ccil.org> References: <20130605162246.GG3680@mercury.ccil.org> <51AF7988.6040009@crockford.com> <20130605184702.GB6999@mercury.ccil.org> <51AF8A09.50806@crockford.com> <20130606010945.GA1362@mercury.ccil.org> Date: Wed, 5 Jun 2013 21:48:35 -0700 Message-ID: From: Tim Bray To: John Cowan Content-Type: multipart/alternative; boundary=bcaec54857e8ed7d1804de750617 X-Gm-Message-State: ALoCoQnG9f2hk0PibCFj//e+RGnB/T27kYnGUwvlrX1HSs3JBALnaIFlfVrRTR0hk8CQ9KgABWk/ Cc: Paul Hoffman , Douglas Crockford , "json@ietf.org" Subject: Re: [Json] Unpaired surrogates in JSON strings X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 06 Jun 2013 04:48:40 -0000 --bcaec54857e8ed7d1804de750617 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Jun 5, 2013 at 6:09 PM, John Cowan wrote: > > I think anyone who=E2=80=99s delivering those codepoints is already in > > violation of 4627, and I don=E2=80=99t think we should retroactively fo= rgive > > those sins. > > It's already been stated that ECMA can't swallow this change. > I thought ECMA=E2=80=99s indigestion was over dupe keys. It seems to me that if unpaired surrogates are to be allowed, it=E2=80=99s = not OK for the spec to assert that strings are made of Unicode characters, because both of these things can=E2=80=99t be correct. -T > > -- > John Cowan cowan@ccil.org http://ccil.org/~cowan > Objective consideration of contemporary phenomena compel the conclusion > that optimum or inadequate performance in the trend of competitive > activities exhibits no tendency to be commensurate with innate capacity, > but that a considerable element of the unpredictable must invariably be > taken into account. --Ecclesiastes 9:11, Orwell/Brown version > --bcaec54857e8ed7d1804de750617 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Jun 5, 2013 at 6:09 PM, John Cowan <cowan@me= rcury.ccil.org> wrote:
> I think anyone who=E2=80=99s delivering= those codepoints is already in
> violation of 4627, and I don=E2=80=99t think we should retroactively f= orgive
> those sins.

It's already been stated that ECMA can't swallow this change.=

I thought ECMA=E2=80=99s indigestion w= as over dupe keys.=C2=A0

It seems to me that if unpaired= surrogates are to be allowed, it=E2=80=99s not OK for the spec to assert t= hat strings are made of Unicode characters, because both of these things ca= n=E2=80=99t be correct.=C2=A0 -T

--
John Cowan =C2=A0 =C2=A0cowan@ccil.org =C2=A0 =C2=A0http://= ccil.org/~cowan
Objective consideration of contemporary phenomena compel the conclusion
that optimum or inadequate performance in the trend of competitive
activities exhibits no tendency to be commensurate with innate capacity, but that a considerable element of the unpredictable must invariably be
taken into account. --Ecclesiastes 9:11, Orwell/Brown version

--bcaec54857e8ed7d1804de750617-- From cowan@ccil.org Wed Jun 5 22:11:50 2013 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 7610D21F88AC for ; Wed, 5 Jun 2013 22:11:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.166 X-Spam-Level: X-Spam-Status: No, score=-3.166 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tR7qE-Ih7r0k for ; Wed, 5 Jun 2013 22:11:46 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id ECD4921F888F for ; Wed, 5 Jun 2013 22:11:45 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1UkSUB-0007vv-F9; Thu, 06 Jun 2013 01:11:43 -0400 Date: Thu, 6 Jun 2013 01:11:43 -0400 From: John Cowan To: Tim Bray Message-ID: <20130606051142.GD1362@mercury.ccil.org> References: <20130605162246.GG3680@mercury.ccil.org> <51AF7988.6040009@crockford.com> <20130605184702.GB6999@mercury.ccil.org> <51AF8A09.50806@crockford.com> <20130606010945.GA1362@mercury.ccil.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Cc: Paul Hoffman , Douglas Crockford , "json@ietf.org" Subject: Re: [Json] Unpaired surrogates in JSON strings X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 06 Jun 2013 05:11:51 -0000 Tim Bray scripsit: > It seems to me that if unpaired surrogates are to be allowed, it’s not OK > for the spec to assert that strings are made of Unicode characters, because > both of these things can’t be correct. -T The author has said that "Unicode character" doesn't mean what the rest of us thinks it means, though no definition I can understand has been forthcoming. However, standards (like other kinds of legal codes) are basically interpreted by their users, not their authors: what the author says has a peculiar interest, but not a peculiar authority. -- John Cowan http://www.ccil.org/~cowan Charles li reis, nostre emperesdre magnes, Set anz totz pleinz ad ested in Espagnes. From peter.h.m.brooks@gmail.com Wed Jun 5 22:13:21 2013 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 8CF6F21F96C6 for ; Wed, 5 Jun 2013 22:13:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QmtCJsSH0+cy for ; Wed, 5 Jun 2013 22:13:20 -0700 (PDT) Received: from mail-qa0-x234.google.com (mail-qa0-x234.google.com [IPv6:2607:f8b0:400d:c00::234]) by ietfa.amsl.com (Postfix) with ESMTP id 9B3E521F96A9 for ; Wed, 5 Jun 2013 22:13:20 -0700 (PDT) Received: by mail-qa0-f52.google.com with SMTP id bv4so61033qab.11 for ; Wed, 05 Jun 2013 22:13:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=tmKi5FFIIOnbC5TOygsnXRxJ+UWNMYjoS15V5ApoKEg=; b=HjreZsVTwdgRupu0BQ7b9WkA6F/No+kEpomH1rEsrTd2lQNnO9Hvrw8HPtok8P1GQK 80hcvb4yfybHRzi6LiPkrog5g8MmfOpjG2dnVPFBXKHSJqGCYBEIEM1zd+sPI2UQhrdG N8Mbjh49R95dWN5uLjZXP5EcuyTsBPTg3FqIMmXCDMurc1BKTq/BaOv5QelCy79veJOa xCcv67xMajrQeJUm4cwY8WtPs5ECfWVSkBjkMe+/ji2uTHL00Ec5Lu0R5p5pPiK/qaY0 KcEnmeInw50zn525yhZT1vgaqke5trLgVdQ31yidcgQ2B8Y2EPYOA5k2A2kxXtqcwt60 nbug== X-Received: by 10.49.96.104 with SMTP id dr8mr37904573qeb.43.1370495600102; Wed, 05 Jun 2013 22:13:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.118.68 with HTTP; Wed, 5 Jun 2013 22:12:40 -0700 (PDT) In-Reply-To: <2E4D08E5-3AF2-42F5-874A-9CD872800717@vpnc.org> References: <51AF7C55.3070606@crockford.com> <2E4D08E5-3AF2-42F5-874A-9CD872800717@vpnc.org> From: Peter Brooks Date: Thu, 6 Jun 2013 07:12:40 +0200 Message-ID: To: Paul Hoffman Content-Type: text/plain; charset=UTF-8 Cc: "json@ietf.org" Subject: Re: [Json] Security Considerations X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 06 Jun 2013 05:13:21 -0000 On 6 June 2013 02:20, Paul Hoffman wrote: > On Jun 5, 2013, at 10:58 AM, Douglas Crockford wrote: > >> The section on security considerations is completely inadequate. It is describing a use of JavaScript eval that is now considered to be a very bad practice, and it provides no advice for other languages. >> >> It should instead be advising care when constructing JSON texts, insisting on proper encoding practices and avoidance of concatenation. > > Who wants to take a stab at proposed Security Considerations wording? This should probably go in Section 7, not Section 6, so that allows a bit more formatting such as headers and such. > How far can this go before it becomes completely new stuff that should be excluded from the scope? For security to work, each object ought to be able to specify the roles that have read or modify access - with a well defined policy (echoing the current position for backwards compatibility) to describe what happens when there are no access rights defined for an object. It is good practice for the actual security requirements for each object to be documented in the object - if they are not, and application logic is relied upon to provide access control, then it is difficult, if not impossible, to have proper governance of access control. There is no better documentation than that that provides the actual control. From stefan@drees.name Wed Jun 5 22:21:26 2013 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 2AE5A21F96F7 for ; Wed, 5 Jun 2013 22:21:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.649 X-Spam-Level: X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_35=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mr+N0hw3VEGq for ; Wed, 5 Jun 2013 22:21:20 -0700 (PDT) Received: from mout.web.de (mout.web.de [212.227.17.11]) by ietfa.amsl.com (Postfix) with ESMTP id 1A02421F96ED for ; Wed, 5 Jun 2013 22:21:19 -0700 (PDT) Received: from newyork.local.box ([77.13.209.10]) by smtp.web.de (mrweb101) with ESMTPSA (Nemesis) id 0MYf78-1UpUyK011m-00VayH; Thu, 06 Jun 2013 07:21:18 +0200 Message-ID: <51B01C4D.4020309@drees.name> Date: Thu, 06 Jun 2013 07:21:17 +0200 From: Stefan Drees User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "Joe Hildebrand (jhildebr)" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V02:K0:dATIjIga4qni4OXL/e83ZxQlNF0Vdub0JohgHwScTxI yRmQ2/PTSWrejHww8WOfxzEPzhIgWbJ7RvaunMZ7Df/9helEM6 V+SDC2Dpz3hfvZj8ZGFZLA3Kgkm35hkCBP3NfG7o49iE6t+YuK 4C6JfZChhpaH9E7uDiN4hVBdDVApZXVcr2BitkjtTzuuv3HXZq gNcdgVi1DvRqgRmAFI0zg== Cc: Vinny A , Eliot Lear , Douglas Crockford , "json@ietf.org" Subject: Re: [Json] The names within an object SHOULD be unique. X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stefan@drees.name List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 05:21:26 -0000 On 2013-06-06 01:40, Joe Hildebrand wrote: > On 6/5/13 5:26 PM, "Douglas Crockford" wrote: > >> It think it should be added to the draft. If duplicate names are >> encountered, the parse MAY fail (because some implementations correctly >> do that), or it MAY succeed by accepting the last duplicated key:value >> pair. > > +1 > +1 also from me. > do we have a preference for new software? > (somehow side stepping the "overridden keys as comment usage" fork) all know that the sequence of keys should not matter when talking JSON, but then if you know who you are talking to ... I guess we have streaming "interpretations" in the wild, where the producer and consumer relation is based on the (out-of-band) assumption, that regardless of JSON type the interchange medium behaves like a queue (and not like a stack or a shuffle) and also that the ordering of keys at best is optimally (top level) application defined, or at least is dependably ordered. So I think gently pushing new implementations to not duplicate names as keys in an object would also help these JSON "extenders" to base their "private" orderings upon (As these are formulated in terms of names). Thus I propose append a """Implementations are strongly urged to not duplicate names as keys in an object.""" (or the like) after the above proposed statement with the two MAYs. Stefan. From cabo@tzi.org Wed Jun 5 23:33:40 2013 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 B074C21F96E7 for ; Wed, 5 Jun 2013 23:33:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JMhoITJUanjz for ; Wed, 5 Jun 2013 23:33:36 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id BEC9421F9651 for ; Wed, 5 Jun 2013 23:33:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r566XTCK001631; Thu, 6 Jun 2013 08:33:29 +0200 (CEST) Received: from [10.53.212.32] (unknown [88.128.80.2]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 83533394F; Thu, 6 Jun 2013 08:33:28 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <51AFEC73.1030904@crockford.com> Date: Thu, 6 Jun 2013 08:33:28 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <51AF9D4C.5060403@crockford.com> <60563185-85A8-4696-8B8C-9282256CFA71@vpnc.org> <255B9BB34FB7D647A506DC292726F6E1151B10582A@WSMSG3153V.srv.dir.telstra.com> <19943667-1EC6-427F-9122-EC037BDE47F1@vpnc.org> <51AFEC73.1030904@crockford.com> To: Douglas Crockford X-Mailer: Apple Mail (2.1503) Cc: json@ietf.org Subject: Re: [Json] Update reference for ABNF X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 06 Jun 2013 06:33:40 -0000 On Jun 6, 2013, at 03:57, Douglas Crockford = wrote: > Why does this matter? Does RFC5234 offer us any better precision? Minor bugfixes in the way things have been written up, no technical = changes: http://tools.ietf.org/rfcdiff?url2=3Drfc5234&url1=3Drfc4234 (Updating is good spec hygiene, and the RFC editor will make you update = it anyway. Or the IESG before it.) Gr=FC=DFe, Carsten From cabo@tzi.org Wed Jun 5 23:41:28 2013 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 1042321F96FC for ; Wed, 5 Jun 2013 23:41:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r1wuEosiaJHg for ; Wed, 5 Jun 2013 23:41:20 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 742D621F9636 for ; Wed, 5 Jun 2013 23:41:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r566f8Aj015629; Thu, 6 Jun 2013 08:41:08 +0200 (CEST) Received: from [10.53.212.32] (unknown [88.128.80.2]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id C57083959; Thu, 6 Jun 2013 08:41:07 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <51AFE107.7020301@crockford.com> Date: Thu, 6 Jun 2013 08:41:07 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <81EF29EC-BFEB-4AE0-AFCF-6359BC31D354@tzi.org> References: <20130605162246.GG3680@mercury.ccil.org> <51AF7988.6040009@crockford.com> <20130605184702.GB6999@mercury.ccil.org> <51AF8A09.50806@crockford.com> <51AFE107.7020301@crockford.com> To: Douglas Crockford X-Mailer: Apple Mail (2.1503) Cc: json@ietf.org Subject: Re: [Json] Unpaired surrogates in JSON strings X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 06 Jun 2013 06:41:28 -0000 On Jun 6, 2013, at 03:08, Douglas Crockford = wrote: > JSON is just the pipe. It doesn't need to be enforcing Unicode over = JavaScript. The sender and receiver can argue about what it means to be = a character. JSON has always been agnostic about this. JSON-the-format is about sequences of characters and can and probably = should be character-encoding-scheme agnostic (as long as that character = encoding scheme represents Unicode characters, because that's what the = ABNF is about). JSON-the-media-type (application/json) can't. Media types describe the = semantics of a sequence of bytes. No characters in sight without defining how to get there. So either we = stick with auto-detecting one of the seven UTFs (with some implied or = explicit semantics about BOMs, which is incompletely specified in RFC = 4627) or we describe reality (UTF-8). Gr=FC=DFe, Carsten From jhildebr@cisco.com Wed Jun 5 23:47:39 2013 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 181B321F973A for ; Wed, 5 Jun 2013 23:47:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5+xL-md1aG5j for ; Wed, 5 Jun 2013 23:47:32 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id C7B2521F8E12 for ; Wed, 5 Jun 2013 23:47:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=328; q=dns/txt; s=iport; t=1370501252; x=1371710852; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=Mj5KrWQzMOTAgC6YnBCcXZ1JxNTkbXUCc+4VHHB1aYw=; b=PQTF/CPERoJKNQW+YzL3gJmYJSPuuWBjK46dNmexgnv9Q1LI+S3sehQs CRQ6C4oFkYq2TJpMP7yaOz+C5o6JEPUmcYmpvSpOyRoewZ+rMc4FjZ3uW VnwfnIiOedwZWZbzxIyltdMtUQXne8L7VOGnYnw9BefMNN7MsdaijaDBr Q=; X-IronPort-AV: E=Sophos;i="4.87,813,1363132800"; d="scan'208";a="216442801" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-9.cisco.com with ESMTP; 06 Jun 2013 06:47:32 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r566lWdp022404 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 6 Jun 2013 06:47:32 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.56]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.02.0318.004; Thu, 6 Jun 2013 01:47:32 -0500 From: "Joe Hildebrand (jhildebr)" To: "stefan@drees.name" Thread-Topic: [Json] The names within an object SHOULD be unique. Thread-Index: AQHOYhtyf+f4Zs3CA0O//LSHQrFFDJknuj6hgABdkQD//59RgIAAw9GA//+zgYA= Date: Thu, 6 Jun 2013 06:47:31 +0000 Message-ID: In-Reply-To: <51B01C4D.4020309@drees.name> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [10.21.86.44] Content-Type: text/plain; charset="us-ascii" Content-ID: <4DD8877FDD178A4FA158A5FECB7B3D1E@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Vinny A , Eliot Lear , Douglas Crockford , "json@ietf.org" Subject: Re: [Json] The names within an object SHOULD be unique. X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 06 Jun 2013 06:47:39 -0000 On 6/5/13 11:21 PM, "Stefan Drees" wrote: >Thus I propose append a > >"""Implementations are strongly urged to not duplicate names as keys in >an object.""" > >(or the like) after the above proposed statement with the two MAYs. RFC 6919 has "REALLY SHOULD NOT" for this. --=20 Joe Hildebrand From jhildebr@cisco.com Wed Jun 5 23:59:19 2013 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 DE4C521F96A9 for ; Wed, 5 Jun 2013 23:59:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mg0uZYOKSEQI for ; Wed, 5 Jun 2013 23:59:14 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id B22B321F9636 for ; Wed, 5 Jun 2013 23:59:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=834; q=dns/txt; s=iport; t=1370501953; x=1371711553; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=EkX+iTpMWUC2Ket8GOqTvhIfHMBb1dTAEmySR6N8qQ8=; b=CgPUf8MHKGJJxj013w9CTdgpxN8dMh8wAKXyzTgrHNrIrQ1AB2AMo8aq FkLfYz0f8tYoRStwVkqT4Wnj4YZJcynR0E/2eAgAoOcoTohUz+jtGx+6D KoIYvj5ru6AWwvzEts7PYDEio0YazEJtQ4an/QFf4Wa6gWo9d7dguG8pY o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AokFAN0xsFGtJV2c/2dsb2JhbABZgwkwgnW8THkWdIIlAQICOj8SAQgiFEIlAgQBDQUIAYgEDLwajnoxB4J6YQOof4MPgic X-IronPort-AV: E=Sophos;i="4.87,813,1363132800"; d="scan'208";a="219222107" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-1.cisco.com with ESMTP; 06 Jun 2013 06:59:13 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r566xDbj032144 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 6 Jun 2013 06:59:13 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.56]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.02.0318.004; Thu, 6 Jun 2013 01:59:12 -0500 From: "Joe Hildebrand (jhildebr)" To: John Cowan , Carsten Bormann Thread-Topic: [Json] Unpaired surrogates in JSON strings Thread-Index: AQHOYgjwaH+sWe/75UqTmsr195d0xpknuQ0AgAAQ1ACAAALZgP//6RgAgAB73ICAADeTgIAAA1OA///FRgA= Date: Thu, 6 Jun 2013 06:59:12 +0000 Message-ID: In-Reply-To: <20130606042921.GC1362@mercury.ccil.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [10.21.86.44] Content-Type: text/plain; charset="us-ascii" Content-ID: <3726485FCBD630429C618AA175F9EDE8@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Paul Hoffman , "json@ietf.org" Subject: Re: [Json] Unpaired surrogates in JSON strings X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 06 Jun 2013 06:59:19 -0000 On 6/5/13 10:29 PM, "John Cowan" wrote: >Carsten Bormann scripsit: > >> Code points can refer to those of the characters or those of the code >> units (byte for UTF-8, etc.). > >Code points are (mathematical) integers corresponding to Unicode >characters, though not all of them are assigned to characters. The intro to the Unicode standard makes this pretty clear: http://www.unicode.org/versions/Unicode6.2.0/ch01.pdf This is why I wanted to decouple from a particular version of Unicode. If the reference remained at version 4, for example, the word "character" means that any code point not in that version of Unicode is not technically legal JSON (although we know it will interop just fine in practice, which is why it's pretty safe to do the update). --=20 Joe Hildebrand From cowan@ccil.org Thu Jun 6 00:03:20 2013 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 3117421F96E1 for ; Thu, 6 Jun 2013 00:03:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.904 X-Spam-Level: * X-Spam-Status: No, score=1.904 tagged_above=-999 required=5 tests=[AWL=-4.854, BAYES_00=-2.599, FB_NO_MORE_HTTP=10.357, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0bjJZtn4PIVE for ; Thu, 6 Jun 2013 00:03:14 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id 4BF8021F96DF for ; Thu, 6 Jun 2013 00:03:12 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1UkUDz-0002Eo-Rm; Thu, 06 Jun 2013 03:03:07 -0400 Date: Thu, 6 Jun 2013 03:03:07 -0400 From: John Cowan To: "Joe Hildebrand (jhildebr)" Message-ID: <20130606070307.GG1362@mercury.ccil.org> References: <20130606042921.GC1362@mercury.ccil.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Cc: Carsten Bormann , Paul Hoffman , "json@ietf.org" Subject: Re: [Json] Unpaired surrogates in JSON strings X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 06 Jun 2013 07:03:20 -0000 Joe Hildebrand (jhildebr) scripsit: > This is why I wanted to decouple from a particular version of Unicode. If > the reference remained at version 4, for example, the word "character" > means that any code point not in that version of Unicode is not > technically legal JSON (although we know it will interop just fine in > practice, which is why it's pretty safe to do the update). +1 -- One art / There is John Cowan No less / No more http://www.ccil.org/~cowan All things / To do With sparks / Galore --Douglas Hofstadter From jhildebr@cisco.com Thu Jun 6 00:05:00 2013 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 93FEE21F96E9 for ; Thu, 6 Jun 2013 00:05:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id csuhAnXgBtnV for ; Thu, 6 Jun 2013 00:04:55 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id C114621F96E8 for ; Thu, 6 Jun 2013 00:04:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=717; q=dns/txt; s=iport; t=1370502295; x=1371711895; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=CrHBSsDP5V1zh40Q614TcZBVvwZlzHrEaYgF6e+r0vU=; b=ZXZOoK7xfci0NcpJb0qTrq3OGEsIK7sjQI8YNYNdNab9uQC13PG+7NCJ BYUz5iWbVPH3p1XKbidYp/y6s9sIrxe5ReGhzIKHmmKFvMxvKY3/G4Qfv rufxMi3f3hPo3tWY4u4/GS919EsC7F0NOqk5ppj4q3Amrv9FcTyEd2FZw U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AocFAN0zsFGtJXG9/2dsb2JhbABZgwmDJbxNdhZ0giUBBDpRAQgiFEIlAgQBEgiIBbwmjno4gnphA6h/gw+CJw X-IronPort-AV: E=Sophos;i="4.87,813,1363132800"; d="scan'208";a="219431606" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-6.cisco.com with ESMTP; 06 Jun 2013 07:04:54 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r5674rHg026447 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 6 Jun 2013 07:04:53 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.56]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.02.0318.004; Thu, 6 Jun 2013 02:04:53 -0500 From: "Joe Hildebrand (jhildebr)" To: Paul Hoffman , "json@ietf.org" Thread-Topic: [Json] Unpaired surrogates in JSON strings Thread-Index: AQHOYgjwaH+sWe/75UqTmsr195d0xpknuQ0AgAAQ1ACAAALZgP//6RgAgAB73ICAAAHDgA== Date: Thu, 6 Jun 2013 07:04:52 +0000 Message-ID: In-Reply-To: <83728898-9A2D-4758-9C06-1157E2954CCB@vpnc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [10.21.86.44] Content-Type: text/plain; charset="us-ascii" Content-ID: <916F53C043A4B345944A52D762937867@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Json] Unpaired surrogates in JSON strings X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 06 Jun 2013 07:05:00 -0000 On 6/5/13 6:58 PM, "Paul Hoffman" wrote: >This could be resolved by a warning similar to what Joe proposed, but it >should be stronger. Also, Joe's wording assumes that these code points >are always represented as escape sequences, but the ABNF allows them to >be in a string as raw, unescaped code points. When in non-encoded land, none of the half surrogate pairs will ever be legal characters. Those code points are forever reserved -- even though many wish UTF16 would die a fire. Now if we're talking about characters with code points outside the BMP, then I agree. The style guide could suggest which of the several ways to encode them is best. --=20 Joe Hildebrand From jhildebr@cisco.com Thu Jun 6 00:17:04 2013 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 5320121F8233 for ; Thu, 6 Jun 2013 00:17:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2IvnmnNjo+4Q for ; Thu, 6 Jun 2013 00:16:58 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id ACC3A21F8168 for ; Thu, 6 Jun 2013 00:16:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=704; q=dns/txt; s=iport; t=1370503018; x=1371712618; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=CFXhnYq1+9TYMnBknn+IGiH3n2c9udWQ8YhZmieKB8Q=; b=j389BDydraGYv+x7bVD/NXJczWlgDoZbok3/5HRxoT8LgZnqsQMyqEbk 8g3nYXe3l/bFohgStwk5JFpkRXgG1N8YB+RGkq9wMgOAjiwTQRzrArt6n RoYBq9Ns/j7o90PwOelKPMq9EyZDVkQ4PsDjSVtb6u196yRrEVVSoP0g1 c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AogFAOA1sFGtJV2c/2dsb2JhbABZgwmDJbxOdhZ0giUBBDo/EgEIIhRCJQIEAQ0FCIgFvBmOejEHgnphA6h/gw+CJw X-IronPort-AV: E=Sophos;i="4.87,813,1363132800"; d="scan'208";a="219416315" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-7.cisco.com with ESMTP; 06 Jun 2013 07:16:58 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r567GvjD022955 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 6 Jun 2013 07:16:57 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.56]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.02.0318.004; Thu, 6 Jun 2013 02:16:57 -0500 From: "Joe Hildebrand (jhildebr)" To: Douglas Crockford , Tim Bray Thread-Topic: [Json] Unpaired surrogates in JSON strings Thread-Index: AQHOYkg5aH+sWe/75UqTmsr195d0xpkoJhcAgAAN2ICAAAJhAA== Date: Thu, 6 Jun 2013 07:16:56 +0000 Message-ID: In-Reply-To: <51AFE107.7020301@crockford.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [10.21.86.44] Content-Type: text/plain; charset="us-ascii" Content-ID: <2D479DB771E5D746800E209FA6AF63D9@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Paul Hoffman , "json@ietf.org" Subject: Re: [Json] Unpaired surrogates in JSON strings X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 06 Jun 2013 07:17:04 -0000 On 6/5/13 7:08 PM, "Douglas Crockford" wrote: >The application that does that is JavaScript. Any 16-bit value can be >put next to any other 16-bit value and then JSON encoded. Agree. This is a relatively-outdated worldview that we're stuck with, and is why I didn't say MUST in my suggested language. >The meaning of=20 >'character' throughout the RFC is ECMAScript's, which is roughly the >same as Unicode's code point. I'm not convinced yet. "\uD834\uDD1E".charCodeAt(0).toString(16); Yields: 'd834' That's not a code point. That's half a surrogate pair for a code point encoded in UTF16. It's only the same in the BMP. --=20 Joe Hildebrand From derhoermi@gmx.net Thu Jun 6 02:55:59 2013 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 B9F8721F973A for ; Thu, 6 Jun 2013 02:55:59 -0700 (PDT) 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=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TpCkczEX2iIz for ; Thu, 6 Jun 2013 02:55:55 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by ietfa.amsl.com (Postfix) with ESMTP id 140AD21F96ED for ; Thu, 6 Jun 2013 02:55:49 -0700 (PDT) Received: from mailout-de.gmx.net ([10.1.76.31]) by mrigmx.server.lan (mrigmx002) with ESMTP (Nemesis) id 0M7WSv-1UQVT13xfL-00xJ6C for ; Thu, 06 Jun 2013 11:55:48 +0200 Received: (qmail invoked by alias); 06 Jun 2013 09:55:48 -0000 Received: from p5B2318C1.dip0.t-ipconnect.de (EHLO netb.Speedport_W_700V) [91.35.24.193] by mail.gmx.net (mp031) with SMTP; 06 Jun 2013 11:55:48 +0200 X-Authenticated: #723575 X-Provags-ID: V01U2FsdGVkX1/S0JJy0xfSKBQY7hXv3R1t2GE2eyKvP81zE0t0K+ svufzsWxBM27v/ From: Bjoern Hoehrmann To: Douglas Crockford Date: Thu, 06 Jun 2013 11:55:50 +0200 Message-ID: References: <51AF8575.5060706@crockford.com> In-Reply-To: <51AF8575.5060706@crockford.com> X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 Cc: "json@ietf.org" Subject: Re: [Json] Encoding X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 06 Jun 2013 09:55:59 -0000 * Douglas Crockford wrote: >I think the section on encoding is not saying anything useful and should >be completely removed. The specification has to define how to handle resources such as which RFC 4627 defines to be a properly formed application/json resource consisting of an array with the number `1` as only element and there are quite a number of implementations that treat it as such. Same goes for which RFC 4627 defines to be malformed junk, but many implementations do treat it as an array with the number `1` as only element. Removing the whole Encoding section without replacement would make it a lot less clear how to handle cases like the two above, so that is not an option. -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ From derhoermi@gmx.net Thu Jun 6 03:09:30 2013 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 B434B21F972C for ; Thu, 6 Jun 2013 03:09:30 -0700 (PDT) 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=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d-FJ5uZhEsjA for ; Thu, 6 Jun 2013 03:09:26 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) by ietfa.amsl.com (Postfix) with ESMTP id D4A0D21F990D for ; Thu, 6 Jun 2013 03:09:25 -0700 (PDT) Received: from mailout-de.gmx.net ([10.1.76.12]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0LbOHk-1U5RlO32JW-00kvqP for ; Thu, 06 Jun 2013 12:09:24 +0200 Received: (qmail invoked by alias); 06 Jun 2013 10:09:24 -0000 Received: from p5B2318C1.dip0.t-ipconnect.de (EHLO netb.Speedport_W_700V) [91.35.24.193] by mail.gmx.net (mp012) with SMTP; 06 Jun 2013 12:09:24 +0200 X-Authenticated: #723575 X-Provags-ID: V01U2FsdGVkX1+bATx0w5ibuWji334F0WWv905UHLuWOoFBjlFmcG U/ifbIklk+tq4o From: Bjoern Hoehrmann To: Douglas Crockford Date: Thu, 06 Jun 2013 12:09:25 +0200 Message-ID: References: <51AF8479.5080002@crockford.com> In-Reply-To: <51AF8479.5080002@crockford.com> X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 Cc: "json@ietf.org" Subject: Re: [Json] The names within an object SHOULD be unique. X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 06 Jun 2013 10:09:30 -0000 * Douglas Crockford wrote: >This was the biggest blunder in the RFC. SHOULD should have been MUST. > >It is, sadly, too late to repair this. Instead, we must specify what >happens when you do the thing you SHOULD NOT do. We need to provide >implementations some slack here because some implementations do the >right thing and reject. Some implementations do the lazy thing and take >that last use of the name. I have seen no evidence that the world is going to standardise around rejecting JSON content with repeated object keys, and consequently do not support any suggestion in the specification that taking the last value is worse than rejecting the whole content. Saying that parsers "MUST either or" is fine though. -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ From douglas@crockford.com Thu Jun 6 03:54:19 2013 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 1FB6D21F9704 for ; Thu, 6 Jun 2013 03:54:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dl5rGDEL9on2 for ; Thu, 6 Jun 2013 03:54:13 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id 8E24D21F971F for ; Thu, 6 Jun 2013 03:54:12 -0700 (PDT) Received: from [192.168.0.108] (173-228-7-202.dsl.static.sonic.net [173.228.7.202]) by mrelay.perfora.net (node=mrus3) with ESMTP (Nemesis) id 0Lwrjc-1UHzR11f1U-017HNg; Thu, 06 Jun 2013 06:54:09 -0400 Message-ID: <51B06A44.1070008@crockford.com> Date: Thu, 06 Jun 2013 03:53:56 -0700 From: Douglas Crockford User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Paul Hoffman References: <51AF9D4C.5060403@crockford.com> <60563185-85A8-4696-8B8C-9282256CFA71@vpnc.org> <255B9BB34FB7D647A506DC292726F6E1151B10582A@WSMSG3153V.srv.dir.telstra.com> <19943667-1EC6-427F-9122-EC037BDE47F1@vpnc.org> <51AFEC73.1030904@crockford.com> <2484862A-4DFF-44D7-9D9D-7E44520C5BED@vpnc.org> In-Reply-To: <2484862A-4DFF-44D7-9D9D-7E44520C5BED@vpnc.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V02:K0:2V/p4danpqGVMFMx2ZOPDw0NnYJlTLH9m29r1JwfM4M +Ph2vwoFgmBYnX8iQG/tj06RPkrzpuexd5AaXR1gZ1utR8irb7 bnLcyxzbCGgBAXi5v2YorPcAvENsYkJ0NeibaMXQu3UP7FiLZ5 0sRSURTjAftEmVFo9G45MTsdbpOzY2jdCWuEcUy8nqymTFkHWH FCKAG+YeX9ynjWhKyHpMtVEDGP6ClsbxCvjH4e22mIH/9pF/j4 6IyilD6lpl5qoPRalX63N+ArE59agTONaEPsXG93dA7sIkL2IK win1qJTJi+8fXJDogY+2geB1bc3iz5/f34m4CJIzTm2pbXhoKB O5qIO8IReFxVpPGFd9j0= Cc: json@ietf.org Subject: Re: [Json] Update reference for ABNF X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 06 Jun 2013 10:54:19 -0000 On 6/5/2013 7:00 PM, Paul Hoffman wrote: > On Jun 5, 2013, at 6:57 PM, Douglas Crockford wrote: > >> On 6/5/2013 6:22 PM, Paul Hoffman wrote: >>> On Jun 5, 2013, at 5:32 PM, "Manger, James H" wrote: >>> >>>> P.S. Another little fix: update reference to ABNF from RFC4234 to RFC5234. >>> Sounds good to me, as long as a few people promise to do a careful checking of that. >>> >>> --Paul Hoffman >> Why does this matter? Does RFC5234 offer us any better precision? > No, but in the IETF, when one RFC is updated by another, there is an expectation that a new RFC will always refer to the latter. > > --Paul Hoffman Who will assure that no problems will be introduce if we do this? From douglas@crockford.com Thu Jun 6 03:57:43 2013 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 939FF21F9633 for ; Thu, 6 Jun 2013 03:57:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.624 X-Spam-Level: X-Spam-Status: No, score=-1.624 tagged_above=-999 required=5 tests=[AWL=0.975, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ePIu50mhZT8i for ; Thu, 6 Jun 2013 03:57:37 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id B099B21F96E9 for ; Thu, 6 Jun 2013 03:57:37 -0700 (PDT) Received: from [192.168.0.108] (173-228-7-202.dsl.static.sonic.net [173.228.7.202]) by mrelay.perfora.net (node=mrus2) with ESMTP (Nemesis) id 0MNIR7-1Uid063AfR-006xGT; Thu, 06 Jun 2013 06:57:36 -0400 Message-ID: <51B06B10.8050308@crockford.com> Date: Thu, 06 Jun 2013 03:57:20 -0700 From: Douglas Crockford User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: John Cowan References: <20130605162246.GG3680@mercury.ccil.org> <51AF7988.6040009@crockford.com> <20130605184702.GB6999@mercury.ccil.org> <51AF8A09.50806@crockford.com> <51AFE107.7020301@crockford.com> <20130606035851.GB1362@mercury.ccil.org> In-Reply-To: <20130606035851.GB1362@mercury.ccil.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V02:K0:SgbUkIn8w/BU7L7raLou6WtQxVQ9OuRLF7bcgSSLcq4 G8Bo2zAUd4aAzSdQ+gU4YhzAfjVJH2U3LW17AEfuVMO63Zinwn R4PLNPlEZXrIRytxIPZCY3sYUUpm1v8mRDJsej2/p4SBzZCH/Q 4AwyaFw1SJXH52rz/Qj7qjCOOAo3V7EfYWzlXltHjKzW4qvBjZ 4CiE3Xhnali8EPSi51PvlPUYUxh7HjOHKQ3yh2opN8rhr6Nep/ 8Ms32qJ+L6SIx2vZg1p6BI8I5I7oL2MaEfFG5SfPAnNA20Cmq8 412Nl2OsJQ+7yl9lzCUlCmu6PesWXzwXO9PlgPWtuJB68oN1hs GYs6EHEo90BFiEj5dXEA= Cc: Tim Bray , Paul Hoffman , "json@ietf.org" Subject: Re: [Json] Unpaired surrogates in JSON strings X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 06 Jun 2013 10:57:43 -0000 On 6/5/2013 8:58 PM, John Cowan wrote: > Douglas Crockford scripsit: > >> When the RFC talks about Unicode Characters, it is in the sense >> of Unicode Characters and not EBCDIC Characters. > That's just confusing. "Unicode character" means something quite > definite in Unicode. If you mean "character in the Unicode repertoire", > that's fine -- but all EBCDIC characters, in all variants of EBCDIC, > are just a subset of that. There seems to me no reason why JSON > couldn't be encoded in EBCDIC, with appropriate escapes. > Of course it is confusing. The text must be clarified to talk about codepoints. From douglas@crockford.com Thu Jun 6 04:03:51 2013 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 9D98821F9399 for ; Thu, 6 Jun 2013 04:03:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.819 X-Spam-Level: X-Spam-Status: No, score=-1.819 tagged_above=-999 required=5 tests=[AWL=0.780, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Is21cJR-asPs for ; Thu, 6 Jun 2013 04:03:45 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id A11A821F939E for ; Thu, 6 Jun 2013 04:03:45 -0700 (PDT) Received: from [192.168.0.108] (173-228-7-202.dsl.static.sonic.net [173.228.7.202]) by mrelay.perfora.net (node=mrus3) with ESMTP (Nemesis) id 0MQzYs-1Ux5C12jS2-00U5Jf; Thu, 06 Jun 2013 07:03:44 -0400 Message-ID: <51B06C80.50708@crockford.com> Date: Thu, 06 Jun 2013 04:03:28 -0700 From: Douglas Crockford User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Tim Bray References: <20130605162246.GG3680@mercury.ccil.org> <51AF7988.6040009@crockford.com> <20130605184702.GB6999@mercury.ccil.org> <51AF8A09.50806@crockford.com> <20130606010945.GA1362@mercury.ccil.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Provags-ID: V02:K0:8gxmyy+OKAy5wNKFdJKDExewsOBsbcilm282WVIfuFk GJaY+cMMWOB7cIMwcZNnLzVidHZvB5cNcyaTbzcwr2txL38Y7Q ZJnnkUPd8xjs2h1KGRzSdHjsueRbYOuV6NgEoKUCAnMWKt3ShD JOhwg8L5kH30qX5qYqRCWdZIW1loyxjOvSkPtH5F0iMEWEKlCp 8rQwWJI96bf6V3za2tXNnU64ZPdlCSaAlnvIPv7XEm1N4D7VEn L3jGN4y2YrjyZ+uYd5+GCXjMTYKwPi8AQRq1CzPR+1cZPkwUCZ +TtY55JDktr0Iat9/+0r3pS+ctexBK5gJCe2heK6jvMXddvqBy 63Dtx5VH88RKgYdv+YXg= Cc: John Cowan , Paul Hoffman , "json@ietf.org" Subject: Re: [Json] Unpaired surrogates in JSON strings X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 06 Jun 2013 11:03:51 -0000 On 6/5/2013 9:48 PM, Tim Bray wrote: > On Wed, Jun 5, 2013 at 6:09 PM, John Cowan > wrote: > > > I think anyone who’s delivering those codepoints is already in > > violation of 4627, and I don’t think we should retroactively forgive > > those sins. > > It's already been stated that ECMA can't swallow this change. > > > I thought ECMA’s indigestion was over dupe keys. > > It seems to me that if unpaired surrogates are to be allowed, it’s not > OK for the spec to assert that strings are made of Unicode characters, > because both of these things can’t be correct. -T I agree. The critical thing that Unicode contributes to JSON is the numbers used in \u forms. It is unfortunate that ECMAScript and Unicode use the word character so differently. So I think JSON should talk exclusively about Unicode Codepoints, because that provides the least ambiguity, and not use the word characters at all. From douglas@crockford.com Thu Jun 6 04:15:27 2013 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 4243A21F938E for ; Thu, 6 Jun 2013 04:15:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pZ5fpTEG7BvZ for ; Thu, 6 Jun 2013 04:15:21 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id 5BFD921F96E9 for ; Thu, 6 Jun 2013 04:15:21 -0700 (PDT) Received: from [192.168.0.108] (173-228-7-202.dsl.static.sonic.net [173.228.7.202]) by mrelay.perfora.net (node=mrus3) with ESMTP (Nemesis) id 0LgpxO-1Tzux235JW-00nxcD; Thu, 06 Jun 2013 07:15:19 -0400 Message-ID: <51B06F38.8050707@crockford.com> Date: Thu, 06 Jun 2013 04:15:04 -0700 From: Douglas Crockford User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "Joe Hildebrand (jhildebr)" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V02:K0:set3iYguOBprk2en17ABSwfYT4JuKAewMrS6Dma/yT+ DyP/eIlHBeYyiuQmZE6QFEmH4P0YZg2MlBEic07VJdXBwuic/X z5VxVO0c6rL/9hS3cau0dRrPEAdsscMnA/hst0TqufEwDEhXVZ 1r4Scxuy2epu1HQmTpqJz+JiV+764vsFDwzCTW47I4f98BHRYI is4wTmq1qqbXyQStTATWgj9wZ2uu0oYTR8+BpaI3kIm9VUOriW gEEfKL4K3cgZsjvwp8Uo8MSuJO0JejXIYuKMeiHhBrBgweuj6o t8CJA81Vv4czGfMoOgdVEpWdTEqU5i7CjA1AzsaGHRN/0v55b9 aEJ0mwwI4dFb3YEXme1w= Cc: Tim Bray , Paul Hoffman , "json@ietf.org" Subject: Re: [Json] Unpaired surrogates in JSON strings X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 06 Jun 2013 11:15:27 -0000 On 6/6/2013 12:16 AM, Joe Hildebrand (jhildebr) wrote: > On 6/5/13 7:08 PM, "Douglas Crockford" wrote: > >> The application that does that is JavaScript. Any 16-bit value can be >> put next to any other 16-bit value and then JSON encoded. > Agree. This is a relatively-outdated worldview that we're stuck with, and > is why I didn't say MUST in my suggested language. > >> The meaning of >> 'character' throughout the RFC is ECMAScript's, which is roughly the >> same as Unicode's code point. > I'm not convinced yet. > > "\uD834\uDD1E".charCodeAt(0).toString(16); > > Yields: > > 'd834' > > That's not a code point. That's half a surrogate pair for a code point > encoded in UTF16. It's only the same in the BMP. > What then is the standard name for a 16-bit element of text? When JavaScript was created, that word was character. What is the word now? From douglas@crockford.com Thu Jun 6 04:18:24 2013 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 7D26721F9951 for ; Thu, 6 Jun 2013 04:18:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.042 X-Spam-Level: X-Spam-Status: No, score=-2.042 tagged_above=-999 required=5 tests=[AWL=0.557, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9minPU7uhSEc for ; Thu, 6 Jun 2013 04:18:18 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id 8E5DA21F994F for ; Thu, 6 Jun 2013 04:18:18 -0700 (PDT) Received: from [192.168.0.108] (173-228-7-202.dsl.static.sonic.net [173.228.7.202]) by mrelay.perfora.net (node=mrus4) with ESMTP (Nemesis) id 0Lon23-1UA7WY3aCx-00gBSs; Thu, 06 Jun 2013 07:18:16 -0400 Message-ID: <51B06FEB.5060203@crockford.com> Date: Thu, 06 Jun 2013 04:18:03 -0700 From: Douglas Crockford User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Bjoern Hoehrmann References: <51AF8479.5080002@crockford.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V02:K0:8RquXo5ulv6G7jqt3gREv06EZQXqwaR9D1cU4fizZl1 uGzQNddNa5Cn/ZESdEnzwKOMkrIawxe/nUh8BqJH70r+S3HvT4 LBOm8GZOWVgZohXqJSYIfJD1ynLF8/X1A20Bf/Mrv40z2ouWuL 48bKfcBEu2G9XzLH/1liC0OWls3aIFncuh+d+IECVBVhLaA/jD 1IAON3T0kV/bmNum0UYwhz1M2BBF9kVknh+XV49Kv5hTFrcMzF //0ulIzJh8WffDj40d/yNWfENrSP80TtIsdgxA01mApnuemkNo RCGIK4+58Cs/tkQsGq18A/MmomEefB5R2krWokYs3T5cQWK7XX CiuPcWxVGQQo3du//x34= Cc: "json@ietf.org" Subject: Re: [Json] The names within an object SHOULD be unique. X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 06 Jun 2013 11:18:24 -0000 On 6/6/2013 3:09 AM, Bjoern Hoehrmann wrote: > * Douglas Crockford wrote: >> This was the biggest blunder in the RFC. SHOULD should have been MUST. >> >> It is, sadly, too late to repair this. Instead, we must specify what >> happens when you do the thing you SHOULD NOT do. We need to provide >> implementations some slack here because some implementations do the >> right thing and reject. Some implementations do the lazy thing and take >> that last use of the name. > I have seen no evidence that the world is going to standardise around > rejecting JSON content with repeated object keys, and consequently do > not support any suggestion in the specification that taking the last > value is worse than rejecting the whole content. Saying that parsers > "MUST either or" is fine though. Taking the last is clearly worse, as will be explained in the new Security Considerations. From cowan@ccil.org Thu Jun 6 05:23:42 2013 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 6F9E621F95D7 for ; Thu, 6 Jun 2013 05:23:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.303 X-Spam-Level: X-Spam-Status: No, score=-2.303 tagged_above=-999 required=5 tests=[AWL=1.296, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bGw336RdrtoI for ; Thu, 6 Jun 2013 05:23:37 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id 44EFB21F94E1 for ; Thu, 6 Jun 2013 05:23:37 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1UkZE6-0000ex-4j; Thu, 06 Jun 2013 08:23:34 -0400 Date: Thu, 6 Jun 2013 08:23:34 -0400 From: John Cowan To: Douglas Crockford Message-ID: <20130606122334.GH1362@mercury.ccil.org> References: <20130605162246.GG3680@mercury.ccil.org> <51AF7988.6040009@crockford.com> <20130605184702.GB6999@mercury.ccil.org> <51AF8A09.50806@crockford.com> <51AFE107.7020301@crockford.com> <20130606035851.GB1362@mercury.ccil.org> <51B06B10.8050308@crockford.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <51B06B10.8050308@crockford.com> User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Cc: Tim Bray , Paul Hoffman , "json@ietf.org" Subject: Re: [Json] Unpaired surrogates in JSON strings X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 06 Jun 2013 12:23:42 -0000 Douglas Crockford scripsit: > Of course it is confusing. The text must be clarified to talk about > codepoints. Code *units*, specifically 16-bit ones, not code points (which are mathematical integers). -- And through this revolting graveyard of the universe the muffled, maddening beating of drums, and thin, monotonous whine of blasphemous flutes from inconceivable, unlighted chambers beyond Time; the detestable pounding and piping whereunto dance slowly, awkwardly, and absurdly the gigantic tenebrous ultimate gods --the blind, voiceless, mindless gargoyles whose soul is Nyarlathotep. (Lovecraft) John Cowan cowan@ccil.org From tony@att.com Thu Jun 6 05:36:08 2013 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 3114221F963F for ; Thu, 6 Jun 2013 05:36:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.307 X-Spam-Level: X-Spam-Status: No, score=-105.307 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MISSING_HEADERS=1.292, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Scl36euvrk3h for ; Thu, 6 Jun 2013 05:36:01 -0700 (PDT) Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) by ietfa.amsl.com (Postfix) with ESMTP id C037821F96A9 for ; Thu, 6 Jun 2013 05:36:00 -0700 (PDT) Received: from unknown [144.160.20.145] (EHLO mlpd192.enaf.sfdc.sbc.com) by nbfkord-smmo06.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id 03280b15.0.124710.00-421.314744.nbfkord-smmo06.seg.att.com (envelope-from ); Thu, 06 Jun 2013 12:36:00 +0000 (UTC) X-MXL-Hash: 51b082305dd0ac47-6d01d3c2d5b41f9e45cc956858362afcc1eb5ead Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r56Ca0Kd003883 for ; Thu, 6 Jun 2013 08:36:00 -0400 Received: from alpi131.aldc.att.com (alpi131.aldc.att.com [130.8.218.69]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r56CZtwt003839 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 6 Jun 2013 08:35:55 -0400 Received: from alpi153.aldc.att.com (alpi153.aldc.att.com [130.8.42.31]) by alpi131.aldc.att.com (RSA Interceptor) for ; Thu, 6 Jun 2013 12:35:38 GMT Received: from aldc.att.com (localhost [127.0.0.1]) by alpi153.aldc.att.com (8.14.5/8.14.5) with ESMTP id r56CZbMD030581 for ; Thu, 6 Jun 2013 08:35:38 -0400 Received: from dns.maillennium.att.com (maillennium.att.com [135.25.114.99]) by alpi153.aldc.att.com (8.14.5/8.14.5) with ESMTP id r56CZZ7F030552 for ; Thu, 6 Jun 2013 08:35:35 -0400 Received: from [135.70.157.211] (vpn-135-70-157-211.vpn.mwst.att.com[135.70.157.211]) by maillennium.att.com (mailgw1) with ESMTP id <20130606123535gw100bhh38e> (Authid: tony); Thu, 6 Jun 2013 12:35:35 +0000 X-Originating-IP: [135.70.157.211] Message-ID: <51B08219.8090204@att.com> Date: Thu, 06 Jun 2013 08:35:37 -0400 From: Tony Hansen User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 CC: "json@ietf.org" References: <51AF8479.5080002@crockford.com> <51AF9ACF.5020507@cisco.com> In-Reply-To: <51AF9ACF.5020507@cisco.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.145] X-AnalysisOut: [v=2.0 cv=EcF/toaC c=1 sm=0 a=ZRNLZ4dFUbCvG8UMqPvVAA==:17 a] X-AnalysisOut: [=z_w9iVmaqBwA:10 a=bfzWQn4VrGAA:10 a=ROTfHnZC7MAA:10 a=ofM] X-AnalysisOut: [gfj31e3cA:10 a=BLceEmwcHowA:10 a=8nJEP1OIZ-IA:10 a=zQP7CpK] X-AnalysisOut: [OAAAA:8 a=So8vTL0ZrKIA:10 a=jq5s4RAdnkBb3hsVTRAA:9 a=wPNLv] X-AnalysisOut: [fGTeEIA:10] Subject: Re: [Json] The names within an object SHOULD be unique. X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 06 Jun 2013 12:36:08 -0000 Of all the wordings that have been proposed so far, I like Eliot's best. Tony Hansen On 6/5/2013 4:08 PM, Eliot Lear wrote: > Hi, > > On 6/5/13 8:33 PM, Douglas Crockford wrote: >> This was the biggest blunder in the RFC. SHOULD should have been MUST. >> >> It is, sadly, too late to repair this. Instead, we must specify what >> happens when you do the thing you SHOULD NOT do. We need to provide >> implementations some slack here because some implementations do the >> right thing and reject. Some implementations do the lazy thing and >> take that last use of the name. > Demonstrating my age, an old trick we've done that goes back to RFC-1123 > is to say MUST NOT send, and then implementations MAY NOT process, and > if they do MUST process thusly... > > That gives you the possibility of potentially getting rid of something > at a later date. I don't know if you want to use it here. It only > sometimes works. > > Eliot From sgbeal@googlemail.com Thu Jun 6 07:55:36 2013 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 A271521F9923 for ; Thu, 6 Jun 2013 07:55:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fY8ToynHOucC for ; Thu, 6 Jun 2013 07:55:35 -0700 (PDT) Received: from mail-wg0-x236.google.com (mail-wg0-x236.google.com [IPv6:2a00:1450:400c:c00::236]) by ietfa.amsl.com (Postfix) with ESMTP id 4BAFB21F9815 for ; Thu, 6 Jun 2013 07:55:35 -0700 (PDT) Received: by mail-wg0-f54.google.com with SMTP id j13so2165140wgh.33 for ; Thu, 06 Jun 2013 07:55:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=i5YonO5GeczVFNPJqucTqT3D9DatPjBWtq5yNRTzI9w=; b=G2OiTk4+0qMbk1yhIizEpfJ1CVEJwXk+2S4RIEOCPUwRaC3thtju+FmT33V3Qs5Rbv /0oWkd1yXXOfMK/k0vDZ6w6RP/fSOw/N5jHKfczacCSpzVh9t6AwxZsMA9wHvM0j/Una QhC3jGXnWY6kDln5u0FrlTcCXxWXZoJylVyVUtzeJumLVK8eyH3WPUVkl3fbMWfw6TvT 0i9SwQYIzh0ko3g0uib/LyVcGMGXk6g0t5RvHwcHeP4YAnBz6znfb91uWxv5eAuTItK8 d/W7rCKgQi147s2UZsGk42javax1bgQzTz4RuOqFUDQriLw4Fc80Cbdfy6bxJTPb/bFg tSww== MIME-Version: 1.0 X-Received: by 10.194.179.102 with SMTP id df6mr32635854wjc.42.1370530534372; Thu, 06 Jun 2013 07:55:34 -0700 (PDT) Received: by 10.194.42.230 with HTTP; Thu, 6 Jun 2013 07:55:34 -0700 (PDT) In-Reply-To: References: <51AF8479.5080002@crockford.com> <51AF8A9B.1020900@crockford.com> <51af8f23.85f8420a.597e.0ccbSMTPIN_ADDED_BROKEN@mx.google.com> <51afa4ff.89e9420a.6d90.212fSMTPIN_ADDED_BROKEN@mx.google.com> Date: Thu, 6 Jun 2013 16:55:34 +0200 Message-ID: From: Stephan Beal To: "json@ietf.org" Content-Type: multipart/alternative; boundary=089e01493c34a7c13e04de7d8122 Subject: Re: [Json] The names within an object SHOULD be unique. X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 06 Jun 2013 14:55:36 -0000 --089e01493c34a7c13e04de7d8122 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Jun 6, 2013 at 1:19 AM, Nico Williams wrote: > Oh, this might actually be important. Perhaps the best way to handle > comments is to have the "schema" (if there is one, stated or > otherwise) specify some keys as being comments, but that doesn't help > for free-form data. > This brings with it a performance penalty because all keys being slurped up now have to be checked against a whitelist/blacklist of keys. -- ----- stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal --089e01493c34a7c13e04de7d8122 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable --089e01493c34a7c13e04de7d8122-- From tbray@textuality.com Thu Jun 6 07:57:53 2013 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 E804821F9640 for ; Thu, 6 Jun 2013 07:57:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.168 X-Spam-Level: * X-Spam-Status: No, score=1.168 tagged_above=-999 required=5 tests=[AWL=-0.189, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zXzFo7-vepDz for ; Thu, 6 Jun 2013 07:57:48 -0700 (PDT) Received: from mail-vb0-x22b.google.com (mail-vb0-x22b.google.com [IPv6:2607:f8b0:400c:c02::22b]) by ietfa.amsl.com (Postfix) with ESMTP id BFFA921F90A5 for ; Thu, 6 Jun 2013 07:57:48 -0700 (PDT) Received: by mail-vb0-f43.google.com with SMTP id e15so2037202vbg.30 for ; Thu, 06 Jun 2013 07:57:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=zuDP0ATOAeP/d/I2KxXsRmYrNzeBsSt+mzxl7ioWRpo=; b=FcuFdrYkDA1XKLuMXaXGG83k7HvL7NUd/JICbLd8UIXNigy+i1+gn/wwKvaNbRgSyT yPP78hzHRz5J2wNH+K4GrbpC5JRz9rfOCqgkjYdQzyzJ03R01/sh6OMRownh/QK3AUMd sb+4SYYzSjHDdyMQrDGmLWt7+TxA1bFRzRI7fano86D+lRkiFEsVqaOxSDxEtXD8br4c 58+byiLsUqfv91ySJCTE6CMfJi9CZgAx1Ks7HlkLrE1MDdtpAdpL+lghgdhpvQGbizOa iZXv6lKSczj9OTcgbkkp6TsuKIq93GdQ6E4GZP2GNE5LY+fPs0Dg0Rm+balu4083V9nG KTPQ== MIME-Version: 1.0 X-Received: by 10.52.112.5 with SMTP id im5mr3482818vdb.4.1370530668098; Thu, 06 Jun 2013 07:57:48 -0700 (PDT) Received: by 10.220.48.14 with HTTP; Thu, 6 Jun 2013 07:57:47 -0700 (PDT) X-Originating-IP: [24.84.235.32] In-Reply-To: <51B06F38.8050707@crockford.com> References: <51B06F38.8050707@crockford.com> Date: Thu, 6 Jun 2013 07:57:47 -0700 Message-ID: From: Tim Bray To: Douglas Crockford Content-Type: multipart/alternative; boundary=bcaec54857e8a0484904de7d89c8 X-Gm-Message-State: ALoCoQkLXGkV+/dxHl7eHE+qqvijeNQAXLuPhbb1dyiu4nnk+5a1rPc6N2vdzlZw1VEeLlhr2RGN Cc: Paul Hoffman , "Joe Hildebrand \(jhildebr\)" , "json@ietf.org" Subject: Re: [Json] Unpaired surrogates in JSON strings X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 06 Jun 2013 14:57:54 -0000 --bcaec54857e8a0484904de7d89c8 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable F0, 90, 8D, 86 On Thu, Jun 6, 2013 at 4:15 AM, Douglas Crockford wr= ote: > What then is the standard name for a 16-bit element of text? When > JavaScript was created, that word was character. What is the word now? > The only somewhat-standardized term would be =E2=80=9CUTF-16 codepoint=E2= =80=9D. But that=E2=80=99s not really a =E2=80=9Cunit of text=E2=80=9D any more than th= e 2nd byte of a character encoded in 3 bytes with UTF-8 is. I=E2=80=99m fairly shocked. I have always believed that JSON encodes what = its introduction (and section 2.5 "Strings") say it encodes, Unicode characters. If it is a requirement to accommodate the class of bug where languages that use UTF-16 (Java, JavaScript, C#) can emit unpaired UTF-16 surrogates, the spec needs to be clear that the INTENT is actually to support Unicode characters, and that unpaired surrogates are always evidence of a bug, and there can be no expectation that any software receiving such buggy data will be able to do anything useful with it, or even avoid crashing in a hard-to-debug way down in the bowels of a library routine. -T --bcaec54857e8a0484904de7d89c8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
F0, 90, 8D, 86
On Thu, Jun 6, 2013 at 4:15 AM, Douglas Crockford <douglas@c= rockford.com> wrote:
What =C2=A0then is the st= andard name for a 16-bit element of text? When JavaScript was created, that= word was character. What is the word now?

The only somewhat-standardized term would = be =E2=80=9CUTF-16 codepoint=E2=80=9D.=C2=A0 But that=E2=80=99s not really = a =E2=80=9Cunit of text=E2=80=9D any more than the 2nd byte of a character = encoded in 3 bytes with UTF-8 is.

I=E2=80=99m fairly shocked.=C2=A0 I have always believed that JS= ON encodes what its introduction (and section 2.5 "Strings") say = it encodes, Unicode characters.=C2=A0

If it is a requirement to acc= ommodate the class of bug where languages that use UTF-16 (Java, JavaScript= , C#) can emit unpaired UTF-16 surrogates, the spec needs to be clear that = the INTENT is actually to support Unicode characters, and that unpaired sur= rogates are always evidence of a bug, and there can be no expectation that = any software receiving such buggy data will be able to do anything useful w= ith it, or even avoid crashing in a hard-to-debug way down in the bowels of= a library routine.=C2=A0 -T


--bcaec54857e8a0484904de7d89c8-- From paul.hoffman@vpnc.org Thu Jun 6 07:59:24 2013 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 8E6A521F990D for ; Thu, 6 Jun 2013 07:59:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.24 X-Spam-Level: X-Spam-Status: No, score=-101.24 tagged_above=-999 required=5 tests=[AWL=1.360, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZFNyp6VUWuXr for ; Thu, 6 Jun 2013 07:59:24 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 01E6221F9640 for ; Thu, 6 Jun 2013 07:59:23 -0700 (PDT) Received: from [10.20.30.90] (50-0-66-165.dsl.dynamic.sonic.net [50.0.66.165]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r56ExLGv028669 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 6 Jun 2013 07:59:22 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Paul Hoffman In-Reply-To: Date: Thu, 6 Jun 2013 07:59:20 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <38C1C408-3AF4-4CF2-96E1-9544C54B0531@vpnc.org> References: To: Joe Hildebrand (jhildebr) X-Mailer: Apple Mail (2.1508) Cc: "json@ietf.org" Subject: Re: [Json] Strings X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 06 Jun 2013 14:59:24 -0000 On Jun 5, 2013, at 8:35 PM, Joe Hildebrand (jhildebr) = wrote: > On 6/5/13 6:14 PM, "Paul Hoffman" wrote: >=20 >> Proposed wording: just before the ABNF at the end of section 2.5, = add: >>=20 >> When comparing strings, escaped characters SHOULD compare the same as >> their unescaped counterparts. For example, the following three = strings >> SHOULD be considered equivalent for comparisons: >=20 >=20 > Are you sure you want to open pandora's box of comparing strings? Yes. String comparison is used for object keys, which is a hot topic in = another thread. { "a": 1, "\u0061": 2 } --Paul Hoffman= From cowan@ccil.org Thu Jun 6 08:08:37 2013 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 27E3C21F965B for ; Thu, 6 Jun 2013 08:08:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.519 X-Spam-Level: X-Spam-Status: No, score=-2.519 tagged_above=-999 required=5 tests=[AWL=1.080, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T9AeE8XQJIvE for ; Thu, 6 Jun 2013 08:08:32 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id BCB8E21F944F for ; Thu, 6 Jun 2013 08:08:32 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1Ukbnh-0001zc-DA; Thu, 06 Jun 2013 11:08:29 -0400 Date: Thu, 6 Jun 2013 11:08:29 -0400 From: John Cowan To: Tim Bray Message-ID: <20130606150829.GC3090@mercury.ccil.org> References: <51B06F38.8050707@crockford.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Cc: "json@ietf.org" , Paul Hoffman , Douglas Crockford , "Joe Hildebrand \(jhildebr\)" Subject: Re: [Json] Unpaired surrogates in JSON strings X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 06 Jun 2013 15:08:37 -0000 Tim Bray scripsit: > I’m fairly shocked. I have always believed that JSON encodes what its > introduction (and section 2.5 "Strings") say it encodes, Unicode > characters. > > If it is a requirement to accommodate the class of bug where languages that > use UTF-16 (Java, JavaScript, C#) can emit unpaired UTF-16 surrogates, the > spec needs to be clear that the INTENT is actually to support Unicode > characters, and that unpaired surrogates are always evidence of a bug, and > there can be no expectation that any software receiving such buggy data > will be able to do anything useful with it, or even avoid crashing in a > hard-to-debug way down in the bowels of a library routine. -T +1 "If Parliament does not mean what it says, it must say so." -- [W]hen I wrote it I was more than a little John Cowan febrile with foodpoisoning from an antique carrot cowan@ccil.org that I foolishly ate out of an illjudged faith http://ccil.org/~cowan in the benignancy of vegetables. --And Rosta From paul.hoffman@vpnc.org Thu Jun 6 08:24:15 2013 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 E00F721F9931 for ; Thu, 6 Jun 2013 08:24:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.166 X-Spam-Level: X-Spam-Status: No, score=-101.166 tagged_above=-999 required=5 tests=[AWL=0.833, BAYES_00=-2.599, J_CHICKENPOX_35=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id whzD2nWDY8Fc for ; Thu, 6 Jun 2013 08:24:15 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 784BC21F9928 for ; Thu, 6 Jun 2013 08:24:15 -0700 (PDT) Received: from [10.20.30.90] (50-0-66-165.dsl.dynamic.sonic.net [50.0.66.165]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r56FOEg6029624 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 6 Jun 2013 08:24:15 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Paul Hoffman In-Reply-To: <51AFC924.2030805@crockford.com> Date: Thu, 6 Jun 2013 08:24:14 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <51AF8479.5080002@crockford.com> <51AF9ACF.5020507@cisco.com> <51AFB3F8.8060708@crockford.com> <8F32953C-C788-4DC9-888E-920E2BEB7FDD@yahoo.com> <831B8E46-F239-4353-8F95-8DF3F9BD2E78@yahoo.com> <51AFC924.2030805@crockford.com> To: "json@ietf.org" X-Mailer: Apple Mail (2.1508) Subject: Re: [Json] The names within an object SHOULD be unique. X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 06 Jun 2013 15:24:16 -0000 On Jun 5, 2013, at 4:26 PM, Douglas Crockford = wrote: > If duplicate names are encountered, the parse MAY fail (because some = implementations correctly do that), or it MAY succeed by accepting the = last duplicated key:value pair. The new text should use language that is already in RFC 4627; "key" is = not such a word. To be fair to implementers, the new document also needs = to deal with both emitters and parsers. Proposal: In Section 2.2: Current: The names within an object SHOULD be unique. Proposed: If the names within an object are not unique, the result of parsing = the=20 object is unpredictable, and the parse may even fail completely. = Thus, the names within an object SHOULD be unique. In Section 4, add a new paragraph: If a parser encounters an object with duplicate names, the parser MAY fail to parse the JSON text; if the parser accepts objects with = duplicate names, it SHOULD accept only the last name/value pair that has the duplicate name.=20 --Paul Hoffman= From paul.hoffman@vpnc.org Thu Jun 6 08:27:42 2013 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 1BEBD21F99B1 for ; Thu, 6 Jun 2013 08:27:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.585 X-Spam-Level: X-Spam-Status: No, score=-101.585 tagged_above=-999 required=5 tests=[AWL=1.014, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JSNyDwQOUUoN for ; Thu, 6 Jun 2013 08:27:41 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 76A6F21F99AC for ; Thu, 6 Jun 2013 08:27:41 -0700 (PDT) Received: from [10.20.30.90] (50-0-66-165.dsl.dynamic.sonic.net [50.0.66.165]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r56FRdBc029726 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 6 Jun 2013 08:27:40 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Paul Hoffman In-Reply-To: Date: Thu, 6 Jun 2013 08:27:39 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <559B518A-7738-4379-8C86-CE28CC14AB09@vpnc.org> References: To: Joe Hildebrand (jhildebr) X-Mailer: Apple Mail (2.1508) Cc: json@ietf.org Subject: Re: [Json] Unpaired surrogates in JSON strings X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 06 Jun 2013 15:27:42 -0000 On Jun 5, 2013, at 11:59 PM, Joe Hildebrand (jhildebr) = wrote: > On 6/5/13 10:29 PM, "John Cowan" wrote: >=20 >> Carsten Bormann scripsit: >>=20 >>> Code points can refer to those of the characters or those of the = code >>> units (byte for UTF-8, etc.). >>=20 >> Code points are (mathematical) integers corresponding to Unicode >> characters, though not all of them are assigned to characters. >=20 > The intro to the Unicode standard makes this pretty clear: >=20 > http://www.unicode.org/versions/Unicode6.2.0/ch01.pdf >=20 >=20 > This is why I wanted to decouple from a particular version of Unicode. = If > the reference remained at version 4, for example, the word "character" > means that any code point not in that version of Unicode is not > technically legal JSON (although we know it will interop just fine in > practice, which is why it's pretty safe to do the update). This is an *extremely* good point. The definition of "character" changes = from version to version of Unicode, and it is now clear we need to deal = with that in this document. --Paul Hoffman= From paul.hoffman@vpnc.org Thu Jun 6 08:32:09 2013 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 A016321F941F for ; Thu, 6 Jun 2013 08:32:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.712 X-Spam-Level: X-Spam-Status: No, score=-101.712 tagged_above=-999 required=5 tests=[AWL=0.887, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5xhW2ixLa3jD for ; Thu, 6 Jun 2013 08:32:09 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 2CB1C21F90EF for ; Thu, 6 Jun 2013 08:32:09 -0700 (PDT) Received: from [10.20.30.90] (50-0-66-165.dsl.dynamic.sonic.net [50.0.66.165]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r56FW38s029887 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 6 Jun 2013 08:32:04 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Paul Hoffman In-Reply-To: <51B06A44.1070008@crockford.com> Date: Thu, 6 Jun 2013 08:32:03 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <2E0B8DF9-BF9F-485E-B011-D9864C4DB875@vpnc.org> References: <51AF9D4C.5060403@crockford.com> <60563185-85A8-4696-8B8C-9282256CFA71@vpnc.org> <255B9BB34FB7D647A506DC292726F6E1151B10582A@WSMSG3153V.srv.dir.telstra.com> <19943667-1EC6-427F-9122-EC037BDE47F1@vpnc.org> <51AFEC73.1030904@crockford.com> <2484862A-4DFF-44D7-9D9D-7E44520C5BED@vpnc.org> <51B06A44.1070008@crockford.com> To: Douglas Crockford X-Mailer: Apple Mail (2.1508) Cc: json@ietf.org Subject: Re: [Json] Update reference for ABNF X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 06 Jun 2013 15:32:09 -0000 On Jun 6, 2013, at 3:53 AM, Douglas Crockford = wrote: > On 6/5/2013 7:00 PM, Paul Hoffman wrote: >> On Jun 5, 2013, at 6:57 PM, Douglas Crockford = wrote: >>=20 >>> On 6/5/2013 6:22 PM, Paul Hoffman wrote: >>>> On Jun 5, 2013, at 5:32 PM, "Manger, James H" = wrote: >>>>=20 >>>>> P.S. Another little fix: update reference to ABNF from RFC4234 to = RFC5234. >>>> Sounds good to me, as long as a few people promise to do a careful = checking of that. >>>>=20 >>>> --Paul Hoffman >>> Why does this matter? Does RFC5234 offer us any better precision? >> No, but in the IETF, when one RFC is updated by another, there is an = expectation that a new RFC will always refer to the latter. >>=20 >> --Paul Hoffman > Who will assure that no problems will be introduce if we do this? Many people on the mailing list, hopefully. Will one or more of you who care about good ABNF volunteer to do careful = checks against RFC 5234? --Paul Hoffman From cowan@ccil.org Thu Jun 6 08:33:09 2013 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 3A62B21F99C5 for ; Thu, 6 Jun 2013 08:33:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.674 X-Spam-Level: X-Spam-Status: No, score=-2.674 tagged_above=-999 required=5 tests=[AWL=0.925, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CVyGvDppJ7Md for ; Thu, 6 Jun 2013 08:33:03 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id 268F321F99C2 for ; Thu, 6 Jun 2013 08:33:02 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1UkcBR-0004Tc-6q; Thu, 06 Jun 2013 11:33:01 -0400 Date: Thu, 6 Jun 2013 11:33:01 -0400 From: John Cowan To: Paul Hoffman Message-ID: <20130606153300.GE3090@mercury.ccil.org> References: <559B518A-7738-4379-8C86-CE28CC14AB09@vpnc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <559B518A-7738-4379-8C86-CE28CC14AB09@vpnc.org> User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Cc: Joe Hildebrand , json@ietf.org Subject: Re: [Json] Unpaired surrogates in JSON strings X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 06 Jun 2013 15:33:09 -0000 Paul Hoffman scripsit: > This is an *extremely* good point. The definition of "character" Rather, the enumeration of characters. > changes from version to version of Unicode, and it is now clear we > need to deal with that in this document. Do you mean "not clear"? -- All Norstrilians knew that humor was John Cowan "pleasurable corrigible malfunction". cowan@ccil.org --Cordwainer Smith, Norstrilia From paul.hoffman@vpnc.org Thu Jun 6 08:37:59 2013 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 8F71B21F88D8 for ; Thu, 6 Jun 2013 08:37:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.81 X-Spam-Level: X-Spam-Status: No, score=-101.81 tagged_above=-999 required=5 tests=[AWL=0.789, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QtK+0AQYhFNe for ; Thu, 6 Jun 2013 08:37:57 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 4669621F8900 for ; Thu, 6 Jun 2013 08:37:55 -0700 (PDT) Received: from [10.20.30.90] (50-0-66-165.dsl.dynamic.sonic.net [50.0.66.165]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r56FbpA3030085 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 6 Jun 2013 08:37:51 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Paul Hoffman In-Reply-To: Date: Thu, 6 Jun 2013 08:37:50 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <51AF7C55.3070606@crockford.com> <2E4D08E5-3AF2-42F5-874A-9CD872800717@vpnc.org> To: "json@ietf.org" X-Mailer: Apple Mail (2.1508) Subject: Re: [Json] Security Considerations X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 06 Jun 2013 15:37:59 -0000 On Jun 5, 2013, at 10:12 PM, Peter Brooks = wrote: > On 6 June 2013 02:20, Paul Hoffman wrote: >> On Jun 5, 2013, at 10:58 AM, Douglas Crockford = wrote: >>=20 >>> The section on security considerations is completely inadequate. It = is describing a use of JavaScript eval that is now considered to be a = very bad practice, and it provides no advice for other languages. >>>=20 >>> It should instead be advising care when constructing JSON texts, = insisting on proper encoding practices and avoidance of concatenation. >>=20 >> Who wants to take a stab at proposed Security Considerations wording? = This should probably go in Section 7, not Section 6, so that allows a = bit more formatting such as headers and such. >>=20 > How far can this go before it becomes completely new stuff that should > be excluded from the scope? That is a WG call. > For security to work, each object ought to be able to specify the > roles that have read or modify access - with a well defined policy > (echoing the current position for backwards compatibility) to describe > what happens when there are no access rights defined for an object. >=20 > It is good practice for the actual security requirements for each > object to be documented in the object - if they are not, and > application logic is relied upon to provide access control, then it is > difficult, if not impossible, to have proper governance of access > control. There is no better documentation than that that provides the > actual control. Useful security considerations for a format include "Emitting X might be = dangerous" and "Parsing Y might be dangerous". There are probably = others. --Paul Hoffman= From internet-drafts@ietf.org Thu Jun 6 09:02:19 2013 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 89D6021F99F3; Thu, 6 Jun 2013 09:02:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.298 X-Spam-Level: X-Spam-Status: No, score=-102.298 tagged_above=-999 required=5 tests=[AWL=0.302, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UPi7ZuXBKWOy; Thu, 6 Jun 2013 09:02:18 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C1E421F99D3; Thu, 6 Jun 2013 09:02:18 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.50 Message-ID: <20130606160218.28403.23956.idtracker@ietfa.amsl.com> Date: Thu, 06 Jun 2013 09:02:18 -0700 Cc: json@ietf.org Subject: [Json] I-D Action: draft-ietf-json-rfc4627bis-01.txt X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 06 Jun 2013 16:02:20 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the JavaScript Object Notation Working Group = of the IETF. Title : The JSON Data Interchange Format Author(s) : Douglas Crockford Filename : draft-ietf-json-rfc4627bis-01.txt Pages : 9 Date : 2013-06-06 Abstract: JSON is a lightweight, text-based, language-independent data interchange format. It was derived from the ECMAScript Programming Language Standard. JSON defines a small set of formatting rules for the portable representation of structured data. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-json-rfc4627bis There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-json-rfc4627bis-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-json-rfc4627bis-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From sgbeal@googlemail.com Thu Jun 6 09:03:24 2013 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 0938121F9A11 for ; Thu, 6 Jun 2013 09:03:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.331 X-Spam-Level: X-Spam-Status: No, score=-1.331 tagged_above=-999 required=5 tests=[AWL=-0.646, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MISSING_HEADERS=1.292, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zB5VWT+Khjqs for ; Thu, 6 Jun 2013 09:03:23 -0700 (PDT) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) by ietfa.amsl.com (Postfix) with ESMTP id A5F5121F9A0D for ; Thu, 6 Jun 2013 09:03:22 -0700 (PDT) Received: by mail-wi0-f175.google.com with SMTP id hn14so511065wib.2 for ; Thu, 06 Jun 2013 09:03:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:cc :content-type; bh=pvQzJt/1/WrPmXjCyG2g/+tvAVEsXiDvE1rJsE1xEuA=; b=HUwNUmoGgXX3nYB93cr+Wqoao60L57wjBQ/vbKa6oyEpexcUJOKD6156wOXEOv10M8 Uc5doHzyThzwr7TnT1OC/0c4jPyuf1euekTM4D1vYrK3rUBm8lmssVOiw3x07N9XvOej 6J9IMZhhCG15C5Bd+wUfypmIEplj5kpUbuF5VO/c9V/eor5EFt9Uwn0aRFw0BBcFNsRa 4d7GKpltbDvDX845uGuA9PzEce6UHlhF+6U037ssUJJX3gULAY7IVsIvmG1vST638wH8 UgK3xpIRPjEMzp7XUec0U0XSsbDT6ZNfOXIiTnELTh+ZFW7VbpZuU/QZtmMOrxHJvCF1 7N6w== MIME-Version: 1.0 X-Received: by 10.194.83.5 with SMTP id m5mr32851615wjy.20.1370534601307; Thu, 06 Jun 2013 09:03:21 -0700 (PDT) Received: by 10.194.42.230 with HTTP; Thu, 6 Jun 2013 09:03:21 -0700 (PDT) In-Reply-To: References: <51AF8479.5080002@crockford.com> <51AF9ACF.5020507@cisco.com> <51AFB3F8.8060708@crockford.com> <8F32953C-C788-4DC9-888E-920E2BEB7FDD@yahoo.com> <831B8E46-F239-4353-8F95-8DF3F9BD2E78@yahoo.com> <51AFC924.2030805@crockford.com> Date: Thu, 6 Jun 2013 18:03:21 +0200 Message-ID: From: Stephan Beal Cc: "json@ietf.org" Content-Type: multipart/alternative; boundary=047d7b5d8bd510475104de7e74a2 Subject: Re: [Json] The names within an object SHOULD be unique. X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 06 Jun 2013 16:03:24 -0000 --047d7b5d8bd510475104de7e74a2 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Jun 6, 2013 at 5:24 PM, Paul Hoffman wrote: > In Section 2.2: > Current: > The names within an object SHOULD be unique. > Proposed: > If the names within an object are not unique, the result of parsing the > object is unpredictable, and the parse may even fail completely. Thus, > the names within an object SHOULD be unique. > +1 for anything along those lines. > In Section 4, add a new paragraph: > If a parser encounters an object with duplicate names, the parser MAY > fail to parse the JSON text; if the parser accepts objects with > duplicate > names, it SHOULD accept only the last name/value pair that has the > duplicate name. > +1. That keeps (i think) any current implementation behaviours compliant while making the intended/best-practice behaviour clear. -- ----- stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal --047d7b5d8bd510475104de7e74a2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Jun 6, 2013 at 5:24 PM, Paul Hoffman <paul.ho= ffman@vpnc.org> wrote:
In Section 2.2:
Current:
=A0 =A0The names within an object SHOULD be unique.
Proposed:
=A0 =A0If the names within an object are not unique, the result of parsing = the
=A0 =A0object is unpredictable, and the parse may even fail completely. Thu= s,
=A0 =A0the names within an object SHOULD be unique.

+1 for anything along those line= s.
=A0
In Section 4, add a n= ew paragraph:
=A0 =A0If a parser encounters an object with duplicate names, the parser MA= Y
=A0 =A0fail to parse the JSON text; if the parser accepts objects with dupl= icate
=A0 =A0names, it SHOULD accept only the last name/value pair that has the =A0 =A0duplicate name.

+1. That k= eeps (i think) any current implementation behaviours compliant while making= the intended/best-practice behaviour clear.

-- <= br> ----- stephan beal
http://wanderinghorse.net/home/stephan/
--047d7b5d8bd510475104de7e74a2-- From paul.hoffman@vpnc.org Thu Jun 6 09:14:13 2013 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 7FB0421F9936 for ; Thu, 6 Jun 2013 09:14:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.889 X-Spam-Level: X-Spam-Status: No, score=-101.889 tagged_above=-999 required=5 tests=[AWL=0.710, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Z3VepwPC-ay for ; Thu, 6 Jun 2013 09:14:13 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id E824021F8FF3 for ; Thu, 6 Jun 2013 09:14:12 -0700 (PDT) Received: from [10.20.30.90] (50-0-66-165.dsl.dynamic.sonic.net [50.0.66.165]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r56GE1rn031271 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 6 Jun 2013 09:14:02 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) From: Paul Hoffman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 6 Jun 2013 09:14:01 -0700 Message-Id: <57273D15-22B0-485D-81D2-715B9945028D@vpnc.org> To: "json@ietf.org" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) Cc: Douglas Crockford Subject: [Json] Please ignore that -01 draft X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 06 Jun 2013 16:14:13 -0000 This is difficult to say, but the -01 draft that Douglas Crockford just = published should be ignored. Matt and I will ask him to pubish -02 that = looks like -00. In our earlier message, Matt and I said that new drafts would come after = consensus calls, and there have clearly been no consensus calls on any = of the topics in the -01 draft. In fact, the wording is still very much = in flux. Matt and I do *not* want the WG to feel that discussion on any = of these topics has been cut off, or even attenuated. So, please immediately ignore the -01 draft and continue the discussions = as if it was never published. --Paul Hoffman= From jsontest@yahoo.com Thu Jun 6 09:40:50 2013 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 33FB121F99E7 for ; Thu, 6 Jun 2013 09:40:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.287 X-Spam-Level: X-Spam-Status: No, score=0.287 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OiXKn1DVWV4O for ; Thu, 6 Jun 2013 09:40:43 -0700 (PDT) Received: from nm10-vm2.bullet.mail.gq1.yahoo.com (nm10-vm2.bullet.mail.gq1.yahoo.com [98.136.218.93]) by ietfa.amsl.com (Postfix) with ESMTP id AB81321F99CF for ; Thu, 6 Jun 2013 09:40:43 -0700 (PDT) Received: from [98.137.12.61] by nm10.bullet.mail.gq1.yahoo.com with NNFMP; 06 Jun 2013 16:40:42 -0000 Received: from [208.71.42.192] by tm6.bullet.mail.gq1.yahoo.com with NNFMP; 06 Jun 2013 16:40:42 -0000 Received: from [127.0.0.1] by smtp203.mail.gq1.yahoo.com with NNFMP; 06 Jun 2013 16:40:42 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1370536842; bh=wp1EtBZdm5ShYTsd8FOmMKgYPKgQuSwDQoZCNDNpPBM=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:References:In-Reply-To:Mime-Version:Content-Type:Received:Content-Transfer-Encoding:Message-Id:Cc:X-Mailer:From:Subject:Content-Length:Date:To; b=oQeFn+m3i106xpJXZiGR6IEdNsVrclbFo8SIpqzJ9eVVX3qhwTeNQ+71MhAfQyEzpPTSGa0H4XvKM2qVaoR59ssxaxl9nqwCK97o1bN+F5cSMmDEOeuK8Zw+X4gNWmdz7IJaAWqSOuHr3fpr6I1GpcFDgs6njN0Xc8IbFK9SUno= X-Yahoo-Newman-Id: 573516.54438.bm@smtp203.mail.gq1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: Qnq1C9MVM1kaOqNS0QjJeNvFEwxrN1TitO9zgT3h2TFLUZp r1KD.2EWQtJhMY.9QvAQfsXtxXRZYk7JbZt9Biz79bCZy01Sm4mslWGQyKse zxiZvf_UrjRTXoilkvlEDgevTiCLyg9iGt7bSQ3GEybCa2JT2LzGFgSywOXo 6EKjlRUm79Di.RuGReYAtSER9fpUlDEHHRcpQmz_JljNNpjtCEy7UxOzjDAS Yty4HAwgnEhrcKx5QwaVydLuFb9MsiZYLQieLW1KmLwHSWEyB1CPOJur_K30 h.MPL6ttLmBs5VFTlQuEKft6XQGrVU34vwHOrLlvi604GTd7h007Pu9KO4wV 2Xrwn3ycQ3mmwUaGCEoEJG4DWi7ObrMCwZUvhVHH0vrh6HKcRBFG_M6_ZIzf KShCSaZ6OAJ7wcv5uS2IHsZA4thVfSJQsI7S4kzfQ0tleeuUiZ5zYVUsilIF ZFZq_Xf6w5XOgLqQXqbb9CWb5a34FZIy5TnlVgtkc6SwH0h1QIGy8kDxkJLd HgukE1ozGxxkXYZpwNZ9GUPT_Dno97w-- X-Yahoo-SMTP: indQcmSswBC8IKsm6t4aCAPskK3T X-Rocket-Received: from [192.168.0.102] (jsontest@76.29.100.42 with ) by smtp203.mail.gq1.yahoo.com with SMTP; 06 Jun 2013 09:40:42 -0700 PDT References: <51AF8479.5080002@crockford.com> <51AF9ACF.5020507@cisco.com> <51AFB3F8.8060708@crockford.com> <8F32953C-C788-4DC9-888E-920E2BEB7FDD@yahoo.com> <831B8E46-F239-4353-8F95-8DF3F9BD2E78@yahoo.com> <51AFC924.2030805@crockford.com> In-Reply-To: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=Apple-Mail-D687AAD0-EDC7-4594-9A93-77D6EA212433 Received: from [76.29.100.42] by web125606.mail.ne1.yahoo.com via HTTP; Thu, 06 Jun 2013 09:33:37 PDT Content-Transfer-Encoding: 7bit Message-Id: <386096B1-A43E-43E1-AD03-90424958D9B3@yahoo.com> X-Mailer: iPod Mail (9B206) From: Vinny A Date: Thu, 6 Jun 2013 11:40:40 -0500 To: Paul Hoffman Cc: "json@ietf.org" Subject: Re: [Json] The names within an object SHOULD be unique. X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 06 Jun 2013 16:40:50 -0000 --Apple-Mail-D687AAD0-EDC7-4594-9A93-77D6EA212433 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jun 6, 2013, at 10:24 AM, Paul Hoffman wrote: > The new text should use language that is already in RFC 4627; "key" is not= such a word. To be fair to implementers, the new document also needs to dea= l with both emitters and parsers. >=20 > Proposal: >=20 > In Section 2.2: > Current: > The names within an object SHOULD be unique. > Proposed: > If the names within an object are not unique, the result of parsing the=20= > object is unpredictable, and the parse may even fail completely. Thus, > the names within an object SHOULD be unique. >=20 > In Section 4, add a new paragraph: > If a parser encounters an object with duplicate names, the parser MAY > fail to parse the JSON text; if the parser accepts objects with duplicat= e > names, it SHOULD accept only the last name/value pair that has the > duplicate name.=20 If we have to recommend to both parsers and emitters, I'd like to make a sli= ght change to your wording: In Section 2.2: Current: The names within an object SHOULD be unique. Proposed: The names within an object SHOULD be unique. Non-unique keys have unpredi= ctable effects (refer to sections 4 & 5). In Section 4 (Parsers) add a new paragraph: If a parser encounters an object with duplicate names, the parser MAY fail= to parse the JSON text; if the parser accepts objects with duplicate names,= it MUST accept only the last name/value pair that has the duplicate name.=20= In Section 5 (Generators) add a new paragraph: A JSON generator SHOULD not duplicate names. If duplicate names are gener= ated, the authoritative name/value pair MUST be listed last. ----------------- Vinny www.jsontest.com --Apple-Mail-D687AAD0-EDC7-4594-9A93-77D6EA212433 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Jun 6, 2= 013, at 10:24 AM, Paul Hoffman <= paul.hoffman@vpnc.org> wrote:
The new text should use language that is already in RFC 4627; "key" i= s not such a word. To be fair to implementers, the new document also needs t= o deal with both emitters and parsers.

Prop= osal:

In Section 2.2:
Curre= nt:
  The names within an object SHOULD be unique.=
Proposed:
  If the names within a= n object are not unique, the result of parsing the 
&nb= sp; object is unpredictable, and the parse may even fail completely. Th= us,
  the names within an object SHOULD be unique.=

In Section 4, add a new paragraph:<= br>  If a parser encounters an object with duplicate names, t= he parser MAY
  fail to parse the JSON text; if th= e parser accepts objects with duplicate
  names, i= t SHOULD accept only the last name/value pair that has the
&= nbsp; duplicate name. 

If we have to recommend to both parsers and emitters, I'd like t= o make a slight change to your wording:

In S= ection 2.2:
Current:
    The n= ames within an object SHOULD be unique.
Proposed:
=    The names within an object SHOULD be unique. Non-= unique keys have unpredictable effects (refer to sections 4 & 5).

In Section 4 (Parsers) add a new paragraph:
  If a parser encounters an object with duplicate nam= es, the parser MAY fail to parse the JSON text; if the parser accepts o= bjects with duplicate names, it MUST accept only the last name/value pa= ir that has the duplicate name. 

I= n Section 5 (Generators) add a new paragraph:
  &nbs= p;A JSON generator SHOULD not duplicate names. If duplicate names are genera= ted, the authoritative name/value pair MUST be listed last.

-----------------
Vinny
www.jsontest.com

= --Apple-Mail-D687AAD0-EDC7-4594-9A93-77D6EA212433-- From mamille2@cisco.com Thu Jun 6 09:43:08 2013 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 193C021F99BB for ; Thu, 6 Jun 2013 09:43:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id itvmBLKOF4Bp for ; Thu, 6 Jun 2013 09:43:01 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id B6FE821F9A06 for ; Thu, 6 Jun 2013 09:43:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7026; q=dns/txt; s=iport; t=1370536981; x=1371746581; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Xqy4bEWU1yMh5T52+jvZH0Xl2bEvurcnrdKxTvos1sc=; b=jAyNET8z2U/bRv6UbWQiEGfqav+pJZdpChk6y67ukQnAXaJEKaRDo87j rP7a2AesPXvuByrb2bSx28B9Y8Ssq89PjGxIboeM6d+/BpTywnXqa9NQt bF0CDEhRe5EqpN3j4/MfopoufQDhiZAB+VcxYYGAGL6ORibbpRNJw/fuL M=; X-Files: smime.p7s : 4136 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AggFAIG7sFGtJXHB/2dsb2JhbABZgwm/d3gWdIIjAQEBAwF5BQsCAQgYCiQCMCUCBA4FCAaHeQa7eY8BMQeCemEDkACBLJdTgw+CJw X-IronPort-AV: E=Sophos;i="4.87,816,1363132800"; d="p7s'?scan'208";a="219652919" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-5.cisco.com with ESMTP; 06 Jun 2013 16:43:01 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r56Gh1JT009607 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 6 Jun 2013 16:43:01 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.24]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.02.0318.004; Thu, 6 Jun 2013 11:43:00 -0500 From: "Matt Miller (mamille2)" To: Paul Hoffman Thread-Topic: [Json] Strings Thread-Index: AQHOYioMjGU3VEWBZE6l/bagJTIFaZkoJROAgAA4Q4CAAL8AAIAAHPWA Date: Thu, 6 Jun 2013 16:43:00 +0000 Message-ID: References: <38C1C408-3AF4-4CF2-96E1-9544C54B0531@vpnc.org> In-Reply-To: <38C1C408-3AF4-4CF2-96E1-9544C54B0531@vpnc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.129.24.59] Content-Type: multipart/signed; boundary="Apple-Mail=_1CB9FEC3-A2FA-460E-9A05-AE2DFE5835C4"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Cc: "Joe Hildebrand \(jhildebr\)" , "json@ietf.org" Subject: Re: [Json] Strings X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 06 Jun 2013 16:43:08 -0000 --Apple-Mail=_1CB9FEC3-A2FA-460E-9A05-AE2DFE5835C4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jun 6, 2013, at 8:59 AM, Paul Hoffman wrote: > On Jun 5, 2013, at 8:35 PM, Joe Hildebrand (jhildebr) = wrote: >=20 >> On 6/5/13 6:14 PM, "Paul Hoffman" wrote: >>=20 >>> Proposed wording: just before the ABNF at the end of section 2.5, = add: >>>=20 >>> When comparing strings, escaped characters SHOULD compare the same = as >>> their unescaped counterparts. For example, the following three = strings >>> SHOULD be considered equivalent for comparisons: >>=20 >>=20 >> Are you sure you want to open pandora's box of comparing strings? >=20 > Yes. String comparison is used for object keys, which is a hot topic = in another thread. >=20 > { "a": 1, "\u0061": 2 } >=20 To (probably vainly) help keep a lid on the box, do we need to note = there is no expectation of normalization? - m&m Matt Miller < mamille2@cisco.com > Cisco Systems, Inc. --Apple-Mail=_1CB9FEC3-A2FA-460E-9A05-AE2DFE5835C4 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMezCCBjQw ggQcoAMCAQICAR4wDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDE1NVoX DTE3MTAyNDIxMDE1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMcJg8zOLdgasSmkLhOrlr6KMoOMpohBllVHrdRvEg/q6r8jR+EK 75xCGhR8ToREoqe7zM9/UnC6TS2y9UKTpT1v7RSMzR0t6ndl0TWBuUr/UXBhPk+Kmy7bI4yW4urC +y7P3/1/X7U8ocb8VpH/Clt+4iq7nirMcNh6qJR+xjOhV+VHzQMALuGYn5KZmc1NbJQYclsGkDxD z2UbFqE2+6vIZoL+jb9x4Pa5gNf1TwSDkOkikZB1xtB4ZqtXThaABSONdfmv/Z1pua3FYxnCFmdr /+N2JLKutIxMYqQOJebr/f/h5t95m4JgrM3Y/w7YX9d7YAL9jvN4SydHsU6n65cCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRTcu2SnODaywFc fH6WNU7y1LhRgjAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBAAqDCH14qywG XLhjjF6uHLkjd02hcdh9hrw+VUsv+q1eeQWB21jWj3kJ96AUlPCoEGZ/ynJNScWy6QMVQjbbMXlt UfO4n4bGGdKo3awPWp61tjAFgraLJgDk+DsSvUD6EowjMTNx25GQgyYJ5RPIzKKR9tQW8gGK+2+R HxkUCTbYFnL6kl8Ch507rUdPPipJ9CgJFws3kDS3gOS5WFMxcjO5DwKfKSETEPrHh7p5shuuNktv sv6hxHTLhiMKX893gxdT3XLS9OKmCv87vkINQcNEcIIoFWbP9HORz9v3vQwR4e3ksLc2JZOAFK+s sS5XMEoznzpihEP0PLc4dCBYjbvSD7kxgDwZ+Aj8Q9PkbvE9sIPP7ON0fz095HdThKjiVJe6vofq +n6b1NBc8XdrQvBmunwxD5nvtTW4vtN6VY7mUCmxsCieuoBJ9OlqmsVWQvifIYf40dJPZkk9YgGT zWLpXDSfLSplbY2LL9C9U0ptvjcDjefLTvqSFc7tw1sEhF0n/qpA2r0GpvkLRDmcSwVyPvmjFBGq Up/pNy8ZuPGQmHwFi2/14+xeSUDG2bwnsYJQG2EdJCB6luQ57GEnTA/yKZSTKI8dDQa8Sd3zfXb1 9mOgSF0bBdXbuKhEpuP9wirslFe6fQ1t5j5R0xi72MZ8ikMu1RQZKCyDbMwazlHiMIIGPzCCBSeg AwIBAgIDBoRIMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcN MTMwNDMwMjE1NDQyWhcNMTQwNTAyMDUzOTA0WjBbMRkwFwYDVQQNExBiN2F6NndOY0t0R3JtMEpF MRswGQYDVQQDDBJtYW1pbGxlMkBjaXNjby5jb20xITAfBgkqhkiG9w0BCQEWEm1hbWlsbGUyQGNp c2NvLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJbKBMsG+9UFTx9uq/bhhXgu vJvO8z7cwKaqqwZhVf5z/kHFyCNijtmTOE+YXjA8mWR4aoBwB5SvGypI/cJUofJ+AlBTC4g+RMx/ K0Ab4/jQqTQz9CDzMOB+Wm+rt8ZJ7A8ZzOJmNDAsf/VvB8l2A1SQz1UsAixgH16NTr8SlblAXEKk 4hwpCudUiNjjQokqJ0H686UBKVorcZSgXaza8XMqGtJF/8mNhR9GQYi7Xht1ky+9LFOrto2daZto KJRwMeVusVdHUeKEQSu7jztw8HchH3KEb7Q+r5X+hhDZoddfKE8d5eyPuhiZdrzv7OlNZ0fSLdx7 3AE3nx9/R5YlXucCAwEAAaOCAtgwggLUMAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQW MBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQUxGd+/qrdVudHrIKkw5xOMY7eaLUwHwYD VR0jBBgwFoAUU3Ltkpzg2ssBXHx+ljVO8tS4UYIwHQYDVR0RBBYwFIESbWFtaWxsZTJAY2lzY28u Y29tMIIBTAYDVR0gBIIBQzCCAT8wggE7BgsrBgEEAYG1NwECAzCCASowLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0 Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBp c3N1ZWQgYWNjb3JkaW5nIHRvIHRoZSBDbGFzcyAxIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9m IHRoZSBTdGFydENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBw dXJwb3NlIGluIGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMDYG A1UdHwQvMC0wK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUxLWNybC5jcmwwgY4G CCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIv Y2xhc3MxL2NsaWVudC9jYTBCBggrBgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2Vy dHMvc3ViLmNsYXNzMS5jbGllbnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRz c2wuY29tLzANBgkqhkiG9w0BAQUFAAOCAQEAlDhXbGEI7lbqUcu5r2JHZaMsbRZda/99ZqODzWGX 0llou9jGccsAWDPPwRRe2+ROpXfH4cuJZElTcLDeZSp/qpXKhjYieFSX8+Ml9sKEj5UOSqQLyoLk PtrIJV12Jk3nuG2Jc0UeEnGwK/aqtzy7+bfEVI0ziyVM2gChHh0RH74KyiwYWknbOTRIkZcz/ulE DVFQp63uj6wfmDNvAUHBAdhKVqA1S/rfP1KcDZpf1NfvwXJibiqTRA6K1EOxTJOP41n/XdvHqHXL RWL2xrOUI9/URANr/ok3OrsuZEMFnAAGefS1bWS/hFtUGVkHGiKEBbyDW7da2ULXbuC7umrQnzGC A28wggNrAgEBMIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkG A1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwaESDAJBgUrDgMCGgUA oIIBrzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMzA2MDYxNjQy NjBaMCMGCSqGSIb3DQEJBDEWBBTxquWypQyYjlbPVpoIBhdC/vWUIzCBpQYJKwYBBAGCNxAEMYGX MIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3Mg MSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwaESDCBpwYLKoZIhvcNAQkQAgsxgZeg gZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1 cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAx IFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDBoRIMA0GCSqGSIb3DQEBAQUABIIBADQD DXzv4yTGAwFtTnGm0vjDYELf9JLR1tvNBFLZQcHHoXjy4+2JNoBCGZ8nJh5XT88g4kqVTYnMWGSw ZQpMerW/MeGYsxt+YDVBe4HAAk4QQaq23HgSOVaLDlYA4NfjGdiza1FLWh0LupRLM3++haFBWgAb 5XCq9G88tobwxabM5Ac27CWWDUgOwaZCzHIk1hrQ4hVq1HB/lYbkS4RHA2Soh0tzwIZ3L6LrHsjs yfe6aK/kgleP68IGBDJpBBquDqa6/mp9lfYV8Qgqnx83f0obdd0BmATy4B/2JaYKhLR3XpdxjnU1 Uyg4IpXsJuyz/4fGUBvMcMemWlIC7ILvtREAAAAAAAA= --Apple-Mail=_1CB9FEC3-A2FA-460E-9A05-AE2DFE5835C4-- From cabo@tzi.org Thu Jun 6 09:46:02 2013 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 16F5F21F99F0 for ; Thu, 6 Jun 2013 09:46:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pVqyWUGCTgRl for ; Thu, 6 Jun 2013 09:45:43 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id D88F221F99C3 for ; Thu, 6 Jun 2013 09:45:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r56GjXuR028490; Thu, 6 Jun 2013 18:45:33 +0200 (CEST) Received: from 216.xarxa-10-83-85.eduroam.upc.edu (cisne-cn09.upc.es [147.83.182.9]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 62D393EBC; Thu, 6 Jun 2013 18:45:33 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: Date: Thu, 6 Jun 2013 18:45:32 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <484B0E59-69C9-460B-811C-AB89F048B2B2@tzi.org> References: <51AF7C55.3070606@crockford.com> <2E4D08E5-3AF2-42F5-874A-9CD872800717@vpnc.org> To: Paul Hoffman X-Mailer: Apple Mail (2.1503) Cc: "json@ietf.org" Subject: Re: [Json] Security Considerations X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 06 Jun 2013 16:46:02 -0000 On Jun 6, 2013, at 17:37, Paul Hoffman wrote: > security considerations I might be stating the obvious here, but: 3552 Guidelines for Writing RFC Text on Security Considerations. E. Rescorla, B. Korver. July 2003. (Format: TXT=3D110393 bytes) (Also BCP0072) (Status: BEST CURRENT PRACTICE) (Clearly, a large part of that doesn't apply here, but that exactly may = be the most important input from that document.) Gr=FC=DFe, Carsten From cabo@tzi.org Thu Jun 6 09:47:24 2013 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 AA4FD21F971F for ; Thu, 6 Jun 2013 09:47:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ivh4-JXMpxLi for ; Thu, 6 Jun 2013 09:47:18 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 2B75521F9A0D for ; Thu, 6 Jun 2013 09:47:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r56Gkuw4000863; Thu, 6 Jun 2013 18:46:56 +0200 (CEST) Received: from 216.xarxa-10-83-85.eduroam.upc.edu (cisne-cn09.upc.es [147.83.182.9]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 61CA03EBD; Thu, 6 Jun 2013 18:46:56 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <2E0B8DF9-BF9F-485E-B011-D9864C4DB875@vpnc.org> Date: Thu, 6 Jun 2013 18:46:55 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <51AF9D4C.5060403@crockford.com> <60563185-85A8-4696-8B8C-9282256CFA71@vpnc.org> <255B9BB34FB7D647A506DC292726F6E1151B10582A@WSMSG3153V.srv.dir.telstra.com> <19943667-1EC6-427F-9122-EC037BDE47F1@vpnc.org> <51AFEC73.1030904@crockford.com> <2484862A-4DFF-44D7-9D9D-7E44520C5BED@vpnc.org> <51B06A44.1070008@crockford.com> <2E0B8DF9-BF9F-485E-B011-D9864C4DB875@vpnc.org> To: Paul Hoffman X-Mailer: Apple Mail (2.1503) Cc: Douglas Crockford , json@ietf.org Subject: Re: [Json] Update reference for ABNF X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 06 Jun 2013 16:47:24 -0000 On Jun 6, 2013, at 17:32, Paul Hoffman wrote: > Will one or more of you who care about good ABNF volunteer to do = careful checks against RFC 5234? Well, so far I only checked that 5234 is not worse for 4627bis than = 4234. But I can also volunteer to torture-test the ABNF itself. Gr=FC=DFe, Carsten From tbray@textuality.com Thu Jun 6 09:49:07 2013 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 628CE21F9A0D for ; Thu, 6 Jun 2013 09:49:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.037 X-Spam-Level: X-Spam-Status: No, score=0.037 tagged_above=-999 required=5 tests=[AWL=-0.414, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_SORBS_DUL=0.877, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y6gWiko4KNEy for ; Thu, 6 Jun 2013 09:49:03 -0700 (PDT) Received: from mail-vb0-x232.google.com (mail-vb0-x232.google.com [IPv6:2607:f8b0:400c:c02::232]) by ietfa.amsl.com (Postfix) with ESMTP id 7941E21F9A0C for ; Thu, 6 Jun 2013 09:48:50 -0700 (PDT) Received: by mail-vb0-f50.google.com with SMTP id w16so2081257vbb.23 for ; Thu, 06 Jun 2013 09:48:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=gBDWuWtUU3PPRbm+BDAYe9d5YQqPmxv+1osvRclE1ns=; b=nyZUp83RmHFFyoO3AQAs4i5dCnjpotDFftw2oaChh80qAWsftBkCVXvDv/8AQ6Uj2F Xfqc5HZfYxvJ8/qXB7t+o6rjxjCfIfMmKEfofSH6HvlJA2ZGgrFZ2aCsfhACIKJ5Bjod 0Cz7h9Xuwry+y7wLdlbPf370Q+yZ5FWP6ciNYSkm3YsIPeJFyxrOXerjInR1ArAxD+iN fDcK2P+Gjcwov7SzZDxgcCVfaDvytMhXVC83/IfhOVwcpPntwkZ8Cbr9F5FsChoOHNtA osmk5Ywjta7Gcn4Jr4OoJLU1YLKTBYT3o9yPtdlggedTbyAcf8WDhZlQRWB/WVXuDlz/ GPDw== MIME-Version: 1.0 X-Received: by 10.52.93.8 with SMTP id cq8mr5143478vdb.77.1370537329623; Thu, 06 Jun 2013 09:48:49 -0700 (PDT) Received: by 10.220.48.14 with HTTP; Thu, 6 Jun 2013 09:48:49 -0700 (PDT) X-Originating-IP: [96.49.81.176] In-Reply-To: References: <38C1C408-3AF4-4CF2-96E1-9544C54B0531@vpnc.org> Date: Thu, 6 Jun 2013 09:48:49 -0700 Message-ID: From: Tim Bray To: "Matt Miller (mamille2)" Content-Type: multipart/alternative; boundary=20cf307f3ad8af1be504de7f16df X-Gm-Message-State: ALoCoQmwpybrYiU8ZVcYI5IdQ14xW4ycvp5oH91CcoYfWKO8+2p4eY+Z+8V8NBGoAmF3ZXCyCEvC Cc: Paul Hoffman , "Joe Hildebrand \(jhildebr\)" , "json@ietf.org" Subject: Re: [Json] Strings X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 06 Jun 2013 16:49:07 -0000 --20cf307f3ad8af1be504de7f16df Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable If keys are unicode strings, the proper languagee is: =E2=80=9CFor purpose of establishing key equality, comparisons MUST be cond= ucted, after all escaping is done, on a character-by-character basis by comparing numeric character codepoints. There is to be no modification of any kind to the characters in keys, including case-changing or combining-form normalization.=E2=80=9D On Thu, Jun 6, 2013 at 9:43 AM, Matt Miller (mamille2) wrote: > > On Jun 6, 2013, at 8:59 AM, Paul Hoffman wrote: > > > On Jun 5, 2013, at 8:35 PM, Joe Hildebrand (jhildebr) < > jhildebr@cisco.com> wrote: > > > >> On 6/5/13 6:14 PM, "Paul Hoffman" wrote: > >> > >>> Proposed wording: just before the ABNF at the end of section 2.5, add= : > >>> > >>> When comparing strings, escaped characters SHOULD compare the same as > >>> their unescaped counterparts. For example, the following three string= s > >>> SHOULD be considered equivalent for comparisons: > >> > >> > >> Are you sure you want to open pandora's box of comparing strings? > > > > Yes. String comparison is used for object keys, which is a hot topic in > another thread. > > > > { "a": 1, "\u0061": 2 } > > > > To (probably vainly) help keep a lid on the box, do we need to note there > is no expectation of normalization? > > > - m&m > > Matt Miller < mamille2@cisco.com > > Cisco Systems, Inc. > > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > > --20cf307f3ad8af1be504de7f16df Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
If keys are unicode strings, the proper languagee is:=

=E2=80=9CFor purpose of establishing key equality, comparison= s MUST be conducted, after all escaping is done, on a character-by-characte= r basis by comparing numeric character codepoints. There is to be no modifi= cation of any kind to the characters in keys, including case-changing or co= mbining-form normalization.=E2=80=9D


On Thu,= Jun 6, 2013 at 9:43 AM, Matt Miller (mamille2) <mamille2@cisco.com&g= t; wrote:

On Jun 6, 2013, at 8:59 AM, Paul Hoffman <paul.hoffman@vpnc.org> wrote:

> On Jun 5, 2013, at 8:35 PM, Joe Hildebrand (jhildebr) <jhildebr@cisco.com> wrote:
>
>> On 6/5/13 6:14 PM, "Paul Hoffman" <paul.hoffman@vpnc.org> wrote:
>>
>>> Proposed wording: just before the ABNF at the end of section 2= .5, add:
>>>
>>> When comparing strings, escaped characters SHOULD compare the = same as
>>> their unescaped counterparts. For example, the following three= strings
>>> SHOULD be considered equivalent for comparisons:
>>
>>
>> Are you sure you want to open pandora's box of comparing strin= gs?
>
> Yes. String comparison is used for object keys, which is a hot topic i= n another thread.
>
> { "a": 1, "\u0061": 2 }
>

To (probably vainly) help keep a lid on the box, do we need to note t= here is no expectation of normalization?


- m&m

Matt Miller < mamille2@cisco.com >
Cisco Systems, Inc.


_______________________________________________
json mailing list
json@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/json


--20cf307f3ad8af1be504de7f16df-- From paul.hoffman@vpnc.org Thu Jun 6 09:52:14 2013 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 4E17A21F99C5 for ; Thu, 6 Jun 2013 09:52:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.954 X-Spam-Level: X-Spam-Status: No, score=-101.954 tagged_above=-999 required=5 tests=[AWL=0.645, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id noP1KPULHqn8 for ; Thu, 6 Jun 2013 09:52:14 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id DFB9121F99C7 for ; Thu, 6 Jun 2013 09:52:11 -0700 (PDT) Received: from [10.20.30.90] (50-0-66-165.dsl.dynamic.sonic.net [50.0.66.165]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r56Gq85n032675 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 6 Jun 2013 09:52:09 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Paul Hoffman In-Reply-To: Date: Thu, 6 Jun 2013 09:52:08 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <5317EF10-6424-4F4C-A9FA-8709D917C848@vpnc.org> References: <38C1C408-3AF4-4CF2-96E1-9544C54B0531@vpnc.org> To: "json@ietf.org" X-Mailer: Apple Mail (2.1508) Subject: Re: [Json] Strings X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 06 Jun 2013 16:52:14 -0000 On Jun 6, 2013, at 9:43 AM, Matt Miller (mamille2) = wrote: >>> Are you sure you want to open pandora's box of comparing strings? >>=20 >> Yes. String comparison is used for object keys, which is a hot topic = in another thread. >>=20 >> { "a": 1, "\u0061": 2 } >>=20 >=20 > To (probably vainly) help keep a lid on the box, do we need to note = there is no expectation of normalization? We do *not* need to note that, because we can't define it in under a = page of text. --Paul Hoffman= From paul.hoffman@vpnc.org Thu Jun 6 09:54:41 2013 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 37CEB21F9A31 for ; Thu, 6 Jun 2013 09:54:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.008 X-Spam-Level: X-Spam-Status: No, score=-102.008 tagged_above=-999 required=5 tests=[AWL=0.591, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pQJVWGJjJcpX for ; Thu, 6 Jun 2013 09:54:30 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 1C99821F9A2E for ; Thu, 6 Jun 2013 09:54:17 -0700 (PDT) Received: from [10.20.30.90] (50-0-66-165.dsl.dynamic.sonic.net [50.0.66.165]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r56GsAsI032745 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 6 Jun 2013 09:54:11 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Paul Hoffman In-Reply-To: Date: Thu, 6 Jun 2013 09:54:10 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <67FC4D12-AE76-45AC-A9B1-18FA33D030B4@vpnc.org> References: <51AF9D4C.5060403@crockford.com> <60563185-85A8-4696-8B8C-9282256CFA71@vpnc.org> <255B9BB34FB7D647A506DC292726F6E1151B10582A@WSMSG3153V.srv.dir.telstra.com> <19943667-1EC6-427F-9122-EC037BDE47F1@vpnc.org> <51AFEC73.1030904@crockford.com> <2484862A-4DFF-44D7-9D9D-7E44520C5BED@vpnc.org> <51B06A44.1070008@crockford.com> <2E0B8DF9-BF9F-485E-B011-D9864C4DB875@vpnc.org> To: Carsten Bormann X-Mailer: Apple Mail (2.1508) Cc: json@ietf.org Subject: Re: [Json] Update reference for ABNF X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 06 Jun 2013 16:54:41 -0000 On Jun 6, 2013, at 9:46 AM, Carsten Bormann wrote: > On Jun 6, 2013, at 17:32, Paul Hoffman wrote: >=20 >> Will one or more of you who care about good ABNF volunteer to do = careful checks against RFC 5234? >=20 > Well, so far I only checked that 5234 is not worse for 4627bis than = 4234. > But I can also volunteer to torture-test the ABNF itself. Thank you, we have a volunteer! Who will be the second? That's a serious = question: some WGs have passed non-ABNF-compliant documents due to = having too few checkers. Fortunately, there is little ABNF in this = document, so that should cause others to want to gain this new and = valuable skill. --Paul Hoffman= From mmorley@mpcm.com Thu Jun 6 09:56:19 2013 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 672EE21F9A35 for ; Thu, 6 Jun 2013 09:56:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MFyyuqMcn7cc for ; Thu, 6 Jun 2013 09:56:18 -0700 (PDT) Received: from mail-la0-x236.google.com (mail-la0-x236.google.com [IPv6:2a00:1450:4010:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id 5ED2E21F9A2F for ; Thu, 6 Jun 2013 09:56:18 -0700 (PDT) Received: by mail-la0-f54.google.com with SMTP id ec20so2815125lab.13 for ; Thu, 06 Jun 2013 09:56:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :x-gm-message-state; bh=Ehp6tJM4DkgZbT640jchRasT8/NijlbAGe9gpUvg0C4=; b=F8Hl/e6NDkWzqHHLKUbFnHNnyH3eLYVpJ3nrBdQjLnpTrac+HE4D0Qk3VJRKMMzfO4 1V9RISqROarU2QTeNJ1gbBdMEsPpLF09IDXOMaR77Fb4kS+RWD0TNI3ZcvryBD2a6zkb T7whlYkm8WgvqgqOkFLbMQLKK1ejgAeQIvSgw5ExoSa5lmDYVYaS4rJPQ8zEyAF9xL8e i5p54OjJ4Bo5ceCXUtRlLIsMpKJwuGHvO18PqdPAJ/UqwAXUmY7H5w9lNkKccK1IQyFp cKiSALBDsdL76iRZ8lNRzuCfppjnGb4wLZongk66+Rm3v7LPVna4+D219NQMphjTaRdG 58lw== MIME-Version: 1.0 X-Received: by 10.152.4.101 with SMTP id j5mr565912laj.67.1370537777145; Thu, 06 Jun 2013 09:56:17 -0700 (PDT) Sender: mmorley@mpcm.com Received: by 10.114.160.69 with HTTP; Thu, 6 Jun 2013 09:56:17 -0700 (PDT) In-Reply-To: References: Date: Thu, 6 Jun 2013 12:56:17 -0400 X-Google-Sender-Auth: fQnpGygfcsQCql-XpdD-byt2KOE Message-ID: From: Matthew Morley To: "Joe Hildebrand (jhildebr)" Content-Type: multipart/alternative; boundary=089e0149423c5bbad804de7f31dc X-Gm-Message-State: ALoCoQntM8tPmSNzrLqxiMYgItUsCidd/ijzzyCnaIadcmzKaZH9U00bDGx66K6slZPr6htlLzuF Cc: Nico Williams , Stephan Beal , Markus Lanthaler , "json@ietf.org" Subject: Re: [Json] The names within an object SHOULD be unique. X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 06 Jun 2013 16:56:19 -0000 --089e0149423c5bbad804de7f31dc Content-Type: text/plain; charset=ISO-8859-1 On Wed, Jun 5, 2013 at 11:44 PM, Joe Hildebrand (jhildebr) < jhildebr@cisco.com> wrote: > On 6/5/13 7:56 PM, "Matthew Morley" wrote: > > >The best way to handle 'comments' is to have them be first class citizens > >in the data. It is a topic that goes back a long way, and since they were > >removed with intention then, using ambiguity in the specification to > >re-add them seems like a poor approach > > now. > > Do you have a backward-compatible proposal? I can't think of one, but > that doesn't make it impossible. > Nope :) I was meaning that the comment should be in data structure itself, existing as a pattern of usage in JSON, rather than part of the JSON specification. There are examples of adding "_comment_{foo}":"comment on pair foo" to objects and insertion of {"_comment_0":"comment on index 0"} into arrays. With the expectation that those comment keys and comment objects be stripped if their existence will break schema expectations. But it goes a bit further than just that, in that comments on a top level array or object would require the payload being wrapped in an array with the 0 index being the comment object, and the 1 index being the real payload. It is the unordered nature of keys, that makes the use of duplicate keys for comments seem like a very strange choice. Every time I look at a JSON object, I try to imagine the keys (usually on a single line with the value) constantly shifting their order and cycling around. That is the reality of what can happen as it encodes/decodes and gets passed around. -- Matthew P. C. Morley --089e0149423c5bbad804de7f31dc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Jun 5, 2013 at 11:44 PM, Joe Hildebrand (jhildebr)= <jhildebr@cisco.com> wrote:
=
On 6/5/13 7:56 PM, "M= atthew Morley" <matt@mpcm.com&= gt; wrote:

>The best way to handle 'comments' is to have them be first clas= s citizens
>in the data. It is a topic that goes back a long way, and since they we= re
>removed with intention then, using ambiguity in the specification to >re-add them seems like a poor approach
> now.

Do you have a backward-compatible proposal? =A0I can't think of o= ne, but
that doesn't make it impossible.

Nope :)=

I was meaning that the comment should be in data structure itself, = existing as=A0a pattern of usage in JSON, rather than part of the JSON spec= ification.


There are examples of adding "_comment_{foo}":"comme= nt on pair foo" to objects and insertion of {"_comment_0":&q= uot;comment on index 0"} into arrays. With the expectation that those = comment keys and comment objects be stripped if their existence will break = schema expectations. But it goes a bit further than just that, in that comm= ents on a top level array or object would require the payload being wrapped= in an array with the 0 index being the comment object, and the 1 index bei= ng the real payload.

It is the unordered nature of keys, that makes the use of duplicate key= s for comments seem like a very strange choice.=A0Every time I look at a JS= ON object, I try to imagine the keys (usually on a single line with the val= ue) constantly shifting their order and cycling around. That is the reality= of what can happen as it encodes/decodes and gets passed around.

--=A0
Matthew P. C. Morley
--089e0149423c5bbad804de7f31dc-- From cabo@tzi.org Thu Jun 6 09:59:53 2013 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 7A3B621F9A48 for ; Thu, 6 Jun 2013 09:59:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kts+O2ZxzrJW for ; Thu, 6 Jun 2013 09:59:48 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 579A521F9A47 for ; Thu, 6 Jun 2013 09:59:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r56GxdY8021800; Thu, 6 Jun 2013 18:59:39 +0200 (CEST) Received: from 216.xarxa-10-83-85.eduroam.upc.edu (cisne-cn09.upc.es [147.83.182.9]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 99A053EC4; Thu, 6 Jun 2013 18:59:39 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <67FC4D12-AE76-45AC-A9B1-18FA33D030B4@vpnc.org> Date: Thu, 6 Jun 2013 18:59:38 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <51AF9D4C.5060403@crockford.com> <60563185-85A8-4696-8B8C-9282256CFA71@vpnc.org> <255B9BB34FB7D647A506DC292726F6E1151B10582A@WSMSG3153V.srv.dir.telstra.com> <19943667-1EC6-427F-9122-EC037BDE47F1@vpnc.org> <51AFEC73.1030904@crockford.com> <2484862A-4DFF-44D7-9D9D-7E44520C5BED@vpnc.org> <51B06A44.1070008@crockford.com> <2E0B8DF9-BF9F-485E-B011-D9864C4DB875@vpnc.org> <67FC4D12-AE76-45AC-A9B1-18FA33D030B4@vpnc.org> To: Paul Hoffman X-Mailer: Apple Mail (2.1503) Cc: json@ietf.org Subject: Re: [Json] Update reference for ABNF X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 06 Jun 2013 16:59:53 -0000 On Jun 6, 2013, at 18:54, Paul Hoffman wrote: > some WGs have passed non-ABNF-compliant documents due to having too = few checkers. I got this wrong once, and the IETF chair had this message for me: http://www.youtube.com/watch?feature=3Dplayer_embedded&v=3DLbK-g8tKnoc Yes, we want to get this right. (And sorry for invoking Godwin's law so early.) Gr=FC=DFe, Carsten From markus.lanthaler@gmx.net Thu Jun 6 10:11:00 2013 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 3CE0621F9A30 for ; Thu, 6 Jun 2013 10:11:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.15 X-Spam-Level: X-Spam-Status: No, score=-1.15 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nx+PdXRe-on1 for ; Thu, 6 Jun 2013 10:10:54 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) by ietfa.amsl.com (Postfix) with ESMTP id 2503F21F9A75 for ; Thu, 6 Jun 2013 10:10:53 -0700 (PDT) Received: from mailout-de.gmx.net ([10.1.76.1]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0MHdX0-1Unx5s3mE0-003IhR for ; Thu, 06 Jun 2013 19:10:52 +0200 Received: (qmail invoked by alias); 06 Jun 2013 17:10:52 -0000 Received: from 84-115-182-43.dynamic.surfer.at (EHLO Vostro3500) [84.115.182.43] by mail.gmx.net (mp001) with SMTP; 06 Jun 2013 19:10:52 +0200 X-Authenticated: #419883 X-Provags-ID: V01U2FsdGVkX18UlmRDK1AUPlPTfy3gXI0W9WBhbfDdub6Ju3eWpm 22DmigKFSIy/cc From: "Markus Lanthaler" To: References: <51AF8479.5080002@crockford.com> <51AF9ACF.5020507@cisco.com> <51AFB3F8.8060708@crockford.com> <8F32953C-C788-4DC9-888E-920E2BEB7FDD@yahoo.com> <831B8E46-F239-4353-8F95-8DF3F9BD2E78@yahoo.com> <51AFC924.2030805@crockford.com> In-Reply-To: Date: Thu, 6 Jun 2013 19:10:44 +0200 Message-ID: <00b601ce62d8$c9eddcb0$5dc99610$@lanthaler@gmx.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 thread-index: Ac5iyepZqDgj2J6GQwWCk5XH5IbjNQADp7BQ Content-Language: de X-Y-GMX-Trusted: 0 Subject: Re: [Json] The names within an object SHOULD be unique. X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 06 Jun 2013 17:11:00 -0000 On Thursday, June 06, 2013 5:24 PM, Paul Hoffman wrote: > Proposal: > > In Section 2.2: > Current: > The names within an object SHOULD be unique. > Proposed: > If the names within an object are not unique, the result of parsing > the > object is unpredictable, and the parse may even fail completely. > Thus, > the names within an object SHOULD be unique. > > In Section 4, add a new paragraph: > If a parser encounters an object with duplicate names, the parser MAY > fail to parse the JSON text; if the parser accepts objects with duplicate > names, it SHOULD accept only the last name/value pair that has the > duplicate name. +1 if the last SHOULD is replaced with a MUST -- Markus Lanthaler @markuslanthaler From internet-drafts@ietf.org Thu Jun 6 10:18:26 2013 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 5E8E321F99B7; Thu, 6 Jun 2013 10:18:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.367 X-Spam-Level: X-Spam-Status: No, score=-102.367 tagged_above=-999 required=5 tests=[AWL=0.233, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n5rfTdds8g-n; Thu, 6 Jun 2013 10:18:26 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 66D5421F99DC; Thu, 6 Jun 2013 10:18:25 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.50 Message-ID: <20130606171825.5998.37767.idtracker@ietfa.amsl.com> Date: Thu, 06 Jun 2013 10:18:25 -0700 Cc: json@ietf.org Subject: [Json] I-D Action: draft-ietf-json-rfc4627bis-02.txt X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 06 Jun 2013 17:18:26 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the JavaScript Object Notation Working Group = of the IETF. Title : The application/json Media Type for JavaScript Object No= tation (JSON) Author(s) : Douglas Crockford Filename : draft-ietf-json-rfc4627bis-02.txt Pages : 11 Date : 2013-06-06 Abstract: JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format. It was derived from the ECMAScript Programming Language Standard. JSON defines a small set of formatting rules for the portable representation of structured data. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-json-rfc4627bis There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-json-rfc4627bis-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-json-rfc4627bis-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From cromis@gmail.com Thu Jun 6 10:19:40 2013 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 4670F21F99DC for ; Thu, 6 Jun 2013 10:19:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RCQE7Vy4VDMH for ; Thu, 6 Jun 2013 10:19:35 -0700 (PDT) Received: from mail-qe0-f44.google.com (mail-qe0-f44.google.com [209.85.128.44]) by ietfa.amsl.com (Postfix) with ESMTP id 15D7C21F9339 for ; Thu, 6 Jun 2013 10:19:35 -0700 (PDT) Received: by mail-qe0-f44.google.com with SMTP id 6so2106510qeb.3 for ; Thu, 06 Jun 2013 10:19:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:from:date:x-google-sender-auth:message-id :subject:to:content-type; bh=t+pcPp15povZ4j7vzC3kajk2SFp9taejU0xjFbhGxPA=; b=XeiH4uagHNuY4mV5m3IxxuPJxXygy/0AJ65eF1k7GBoccESHK/zz338h2yJ2gszoO2 lsmvqiAWerDqQbQszPyqan11JnFOP5iS21bm3GuwMYTKZU6vV106NkxVEZomO41dD7JG MVwtSnFTaeq2L+z4P4NQM7tt6KuTYHhkqD96xz4+Z2B3j/ERYTaQ3FaIUesM97r15ebj iLuhYb7pzqMfKMGg/e5aH6PCOkbjtq3lCTKXvNEVf8uRzPyxIU2/NqJp9htx5JHD5dzF QPVJpCjSHiwVvdLo4q3NAyqhFPtj+oX+/b2SIeEYw2XOnZzMRjbOF+SNy/sOj6rRp6+9 Up+A== X-Received: by 10.49.58.97 with SMTP id p1mr15994394qeq.59.1370539170894; Thu, 06 Jun 2013 10:19:30 -0700 (PDT) MIME-Version: 1.0 Sender: cromis@gmail.com Received: by 10.49.106.228 with HTTP; Thu, 6 Jun 2013 10:19:10 -0700 (PDT) From: Jacob Davies Date: Thu, 6 Jun 2013 10:19:10 -0700 X-Google-Sender-Auth: RawxgAcIuKKQbGm0NiueSAqolp4 Message-ID: To: "json@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Subject: [Json] Parsers X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 06 Jun 2013 17:19:40 -0000 RFC 4627 text: 4. Parsers A JSON parser transforms a JSON text into another representation. A JSON parser MUST accept all texts that conform to the JSON grammar. A JSON parser MAY accept non-JSON forms or extensions. An implementation may set limits on the size of texts that it accepts. An implementation may set limits on the maximum depth of nesting. An implementation may set limits on the range of numbers. An implementation may set limits on the length and character contents of strings. -- 1) It seems to me that "A JSON parser MUST accept all texts that conform to the JSON grammar" is both impossible and immediately contradicted in the next paragraph. No parser accepts all texts in the sense of faithfully processing them into another representation without error, because the entire text is of indefinite length, as are many of its components, and I think this is intending to say something about not inventing your own subset of JSON. Maybe there is another way of expressing the intent of this sentence. 2) I think there was also earlier discussion about whether the acceptance of non-JSON forms or extensions is desirable. It seems undesirable to me. 3) It is not stated that implementations may limit the number of elements in arrays or objects. Perhaps that whole paragraph could be something like: "Implementations may vary in their handling of the size of texts, the maximum depth of nesting of arrays and objects, the number of elements in arrays or objects, the range of numbers, and the length and character contents of strings." 4) It might also suggest what parsers should do when they encounter texts they cannot faithfully represent. Some extant implementations truncate numbers larger than those they can faithfully represent, for instance, which is bad. I think parsers should be strongly encouraged to produce an error and no representation when they read a text they cannot faithfully represent, rather than no error and a partial, non-verisimilar representation. -Jacob From douglas@crockford.com Thu Jun 6 10:19:41 2013 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 0CC6721F9A3A for ; Thu, 6 Jun 2013 10:19:41 -0700 (PDT) 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=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IT4OCk5hRBc1 for ; Thu, 6 Jun 2013 10:19:35 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id 1D4F521F99BD for ; Thu, 6 Jun 2013 10:19:35 -0700 (PDT) Received: from [192.168.114.223] ([216.113.168.135]) by mrelay.perfora.net (node=mrus4) with ESMTP (Nemesis) id 0LvEBG-1UKciK24KA-00zby8; Thu, 06 Jun 2013 13:19:20 -0400 Message-ID: <51B0C48B.60705@crockford.com> Date: Thu, 06 Jun 2013 10:19:07 -0700 From: Douglas Crockford User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Paul Hoffman References: <57273D15-22B0-485D-81D2-715B9945028D@vpnc.org> In-Reply-To: <57273D15-22B0-485D-81D2-715B9945028D@vpnc.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V02:K0:Kdiin/CQ+cRGbDlBrg9mzRPuHNTo3M+dXD3nqBYaF/N o1JVPxMgf5PyeVL3WZ6UvJZR33VFkTCn6eHQjjP04rFLoFRdrf Dn9sO5cIp5x+rd7CiU7MvNFwq2gM78etLpxwIvEklzAS/XtQ6Z 0GwFVwdJ/+Q3V6JEtchNfo+uAiTKCYiiyHiFXaAKYFf7+MJJdR z0EiDbeiMNP+k5Edhz7rugl4HQCkW8HeixwMRGUeccq7ZQZ2Ji VBoy8Y8ICMcUY2WRDd2cXPT84ny6iBrWOGNaVoxTSrqUS6MRcl 8S4pGjPuf6KL+6frvbyUtc010upZKo6ML3hz7ooZYbWUi6vECV NzvfhAoPGfhUCtU3O1RY= Cc: "json@ietf.org" Subject: Re: [Json] Please ignore that -01 draft X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 06 Jun 2013 17:19:41 -0000 Sorry for the confusion. This process is very new to me, and not making a lot of sense yet. On 6/6/2013 9:14 AM, Paul Hoffman wrote: > This is difficult to say, but the -01 draft that Douglas Crockford just published should be ignored. Matt and I will ask him to pubish -02 that looks like -00. > > In our earlier message, Matt and I said that new drafts would come after consensus calls, and there have clearly been no consensus calls on any of the topics in the -01 draft. In fact, the wording is still very much in flux. Matt and I do *not* want the WG to feel that discussion on any of these topics has been cut off, or even attenuated. > > So, please immediately ignore the -01 draft and continue the discussions as if it was never published. > > --Paul Hoffman From paul.hoffman@vpnc.org Thu Jun 6 10:20:03 2013 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 53F7C21F9AA3 for ; Thu, 6 Jun 2013 10:20:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.053 X-Spam-Level: X-Spam-Status: No, score=-102.053 tagged_above=-999 required=5 tests=[AWL=0.546, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HKonsZ9EVnvo for ; Thu, 6 Jun 2013 10:20:02 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 214AF21F9A9D for ; Thu, 6 Jun 2013 10:20:02 -0700 (PDT) Received: from [10.20.30.90] (50-0-66-165.dsl.dynamic.sonic.net [50.0.66.165]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r56HK08L033729 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 6 Jun 2013 10:20:01 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Paul Hoffman In-Reply-To: <386096B1-A43E-43E1-AD03-90424958D9B3@yahoo.com> Date: Thu, 6 Jun 2013 10:20:00 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <51AF8479.5080002@crockford.com> <51AF9ACF.5020507@cisco.com> <51AFB3F8.8060708@crockford.com> <8F32953C-C788-4DC9-888E-920E2BEB7FDD@yahoo.com> <831B8E46-F239-4353-8F95-8DF3F9BD2E78@yahoo.com> <51AFC924.2030805@crockford.com> <386096B1-A43E-43E1-AD03-90424958D9B3@yahoo.com> To: Vinny A X-Mailer: Apple Mail (2.1508) Cc: "json@ietf.org" Subject: Re: [Json] The names within an object SHOULD be unique. X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 06 Jun 2013 17:20:03 -0000 FWIW, I like Vinny's construct better than my proposal. Less description = in Section 2, and pointers to Sections 4 and 5. And I agree that the = MUST for the parser is more appropriate than the SHOULD. --Paul Hoffman On Jun 6, 2013, at 9:40 AM, Vinny A wrote: > On Jun 6, 2013, at 10:24 AM, Paul Hoffman = wrote: >> The new text should use language that is already in RFC 4627; "key" = is not such a word. To be fair to implementers, the new document also = needs to deal with both emitters and parsers. >>=20 >> Proposal: >>=20 >> In Section 2.2: >> Current: >> The names within an object SHOULD be unique. >> Proposed: >> If the names within an object are not unique, the result of parsing = the=20 >> object is unpredictable, and the parse may even fail completely. = Thus, >> the names within an object SHOULD be unique. >>=20 >> In Section 4, add a new paragraph: >> If a parser encounters an object with duplicate names, the parser = MAY >> fail to parse the JSON text; if the parser accepts objects with = duplicate >> names, it SHOULD accept only the last name/value pair that has the >> duplicate name.=20 >=20 > If we have to recommend to both parsers and emitters, I'd like to make = a slight change to your wording: >=20 > In Section 2.2: > Current: > The names within an object SHOULD be unique. > Proposed: > The names within an object SHOULD be unique. Non-unique keys have = unpredictable effects (refer to sections 4 & 5). >=20 > In Section 4 (Parsers) add a new paragraph: > If a parser encounters an object with duplicate names, the parser = MAY fail to parse the JSON text; if the parser accepts objects with = duplicate names, it MUST accept only the last name/value pair that has = the duplicate name.=20 >=20 > In Section 5 (Generators) add a new paragraph: > A JSON generator SHOULD not duplicate names. If duplicate names are = generated, the authoritative name/value pair MUST be listed last. >=20 > ----------------- > Vinny > www.jsontest.com >=20 > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json From tsaloranta@gmail.com Thu Jun 6 10:32:11 2013 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 2C34021F9339 for ; Thu, 6 Jun 2013 10:32:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.532 X-Spam-Level: X-Spam-Status: No, score=-1.532 tagged_above=-999 required=5 tests=[AWL=1.067, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ShgPCGAUtCi8 for ; Thu, 6 Jun 2013 10:32:10 -0700 (PDT) Received: from mail-wg0-x22c.google.com (mail-wg0-x22c.google.com [IPv6:2a00:1450:400c:c00::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 24DE921F9959 for ; Thu, 6 Jun 2013 10:32:04 -0700 (PDT) Received: by mail-wg0-f44.google.com with SMTP id m15so1286513wgh.23 for ; Thu, 06 Jun 2013 10:32:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=qCfiOdDF0zTsFUTp0yGiefmfYrvqvDUh/0P0nVS7ap8=; b=C+LTVANYlzBWXyQfgMYI6oa2/6R0viTQ88kpBcvgGMPgiErXqwjiRno5e6h+4rpdNl uBe+VBf8MaQVD/9xNR80c4kGO3shvT7bKf3/Qud7UDKyjyhxmcKcBfInGwIRqucupJWl fkS8PrH1bz+UpAkhYm8Lo7zMb7cIHRCNP7fWjYzWOvXvnNpwXrKcR0iedAls2B0JfRJd r/CBANko9seN5HnthEUPf2jLZU1AxT6yHgiQrAmBisRsR/oiK+1NLoenIMlA4hmwerCp xzDVhV7EyzpFHA9kiW6Bd9w5JbH87Cg6njSOCU6gn09BD+eau93nJzRLSjqHMFNRUki7 sF/w== MIME-Version: 1.0 X-Received: by 10.180.7.230 with SMTP id m6mr3121003wia.55.1370539924046; Thu, 06 Jun 2013 10:32:04 -0700 (PDT) Received: by 10.227.97.6 with HTTP; Thu, 6 Jun 2013 10:32:03 -0700 (PDT) In-Reply-To: References: <51AF8479.5080002@crockford.com> <51AF8A9B.1020900@crockford.com> <51af8f23.85f8420a.597e.0ccbSMTPIN_ADDED_BROKEN@mx.google.com> <51afa4ff.89e9420a.6d90.212fSMTPIN_ADDED_BROKEN@mx.google.com> Date: Thu, 6 Jun 2013 10:32:03 -0700 Message-ID: From: Tatu Saloranta To: Stephan Beal Content-Type: multipart/alternative; boundary=f46d044403b853af9a04de7fb13b Cc: "json@ietf.org" Subject: Re: [Json] The names within an object SHOULD be unique. X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 06 Jun 2013 17:32:11 -0000 --f46d044403b853af9a04de7fb13b Content-Type: text/plain; charset=ISO-8859-1 On Thu, Jun 6, 2013 at 7:55 AM, Stephan Beal wrote: > > On Thu, Jun 6, 2013 at 1:19 AM, Nico Williams wrote: > >> Oh, this might actually be important. Perhaps the best way to handle >> comments is to have the "schema" (if there is one, stated or >> otherwise) specify some keys as being comments, but that doesn't help >> for free-form data. >> > > This brings with it a performance penalty because all keys being slurped > up now have to be checked against a whitelist/blacklist of keys. > > And if generators were to be prohibited from outputting duplicates, they too must keep track of all keys for all open object contexts I think it is reasonable to point out that use of duplicate keys is not supported, nor should systems rely on such usage working. In fact, NOT specifying proper handling for this case may be better for interoperability; if specific "use first" or "use last" is sanctioned, it will be more likely to support usage of multiple instances. Furthermore, mandating one or the other will hurt some use cases; for "use first", decoder/parser must keep information around to suppress (or error on) multiples. And "use last" case would be impractical for purely streaming implementation since it is impossible to force such usage without buffering the whole content to determine value to use. For these reasons, I would prefer simple discouraging use of duplicate names, without trying to specify "but if you must, then use X" processing. -+ Tatu +- --f46d044403b853af9a04de7fb13b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Jun 6, 2013 at 7:55 AM, Stephan Beal <sgbeal@= googlemail.com> wrote:

On Thu, Jun 6, 2013 at 1:1= 9 AM, Nico Williams <nico@cryptonector.com> wrote:
Oh,= this might actually be important. =A0Perhaps the best way to handle=
comments is to have the "schema" (if there is one, stated or
otherwise) specify some keys as being comments, but that doesn't help for free-form data.

This brings w= ith it a performance penalty because all keys being slurped up now have to = be checked against a whitelist/blacklist of keys.


And= if generators were to be prohibited from outputting duplicates, they too m= ust keep track of all keys for all open object contexts

I think it is reasonable to point out that use of dupl= icate keys is not supported, nor should systems rely on such usage working.= In fact, NOT specifying proper handling for this case may be better for in= teroperability; if specific "use first" or "use last" i= s sanctioned, it will be more likely to support usage of multiple instances= . Furthermore, mandating one or the other will hurt some use cases; for &qu= ot;use first", decoder/parser must keep information around to suppress= (or error on) multiples.
And "use last" case would be impractical for purely st= reaming implementation since it is impossible to force such usage without b= uffering the whole content to determine value to use.

For these reasons, I would prefer simple discouraging use = of duplicate names, without trying to specify "but if you must, then u= se X" processing.

-+ Tatu +-

--f46d044403b853af9a04de7fb13b-- From jhildebr@cisco.com Thu Jun 6 10:32:37 2013 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 9E9C921F995B for ; Thu, 6 Jun 2013 10:32:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BQE2EQv7QZn4 for ; Thu, 6 Jun 2013 10:32:24 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 8F17521F994C for ; Thu, 6 Jun 2013 10:32:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=442; q=dns/txt; s=iport; t=1370539944; x=1371749544; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=Zy42gxl7e8PaBaCkbEWy7/spthBrVTHoNXh+UuSxgP0=; b=d+KF2jsuHOa4UxQNlwVDRyjEWhmE3lf2IrVgPBSVATt6Zj/yBOLtrcRC A2NTBxggd7WqHnVTMSV129a/MhUFyHzl0pJK3ljPyLlOEm/4C5zoQnB0j Oc9zEwLgDDT8vHk6xSKlsjT6iNg10bEujW8jO//ZVr7qyNIGMwiazGdMD w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgcFAIbGsFGtJV2b/2dsb2JhbABZgwm/d3gWdIIlAQQ6PxIBCCIUQiUCBAENBQiIBbt/jwExB4J6YQOof4MPgic X-IronPort-AV: E=Sophos;i="4.87,816,1363132800"; d="scan'208";a="219672500" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-7.cisco.com with ESMTP; 06 Jun 2013 17:32:24 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r56HWNbN016555 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 6 Jun 2013 17:32:23 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.56]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.02.0318.004; Thu, 6 Jun 2013 12:32:23 -0500 From: "Joe Hildebrand (jhildebr)" To: Douglas Crockford , Tim Bray Thread-Topic: [Json] Unpaired surrogates in JSON strings Thread-Index: AQHOYkg5aH+sWe/75UqTmsr195d0xpkoJhcAgAAOOoCAAD0kgIAAaL4AgAAID4A= Date: Thu, 6 Jun 2013 17:32:22 +0000 Message-ID: In-Reply-To: <51B06C80.50708@crockford.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [10.21.88.234] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: John Cowan , Paul Hoffman , "json@ietf.org" Subject: Re: [Json] Unpaired surrogates in JSON strings X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 06 Jun 2013 17:32:37 -0000 On 6/6/13 5:03 AM, "Douglas Crockford" wrote: >I agree. The critical thing that Unicode contributes to JSON is the >numbers used in \u forms. It is unfortunate that ECMAScript and Unicode >use the word character so differently. So I think JSON should talk >exclusively about Unicode Codepoints, because that provides the least >ambiguity, and not use the word characters at all. +1 --=20 Joe Hildebrand From tsaloranta@gmail.com Thu Jun 6 10:36:09 2013 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 F205621F9948 for ; Thu, 6 Jun 2013 10:36:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.888 X-Spam-Level: X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[AWL=0.712, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p90MVXAzLrNs for ; Thu, 6 Jun 2013 10:36:09 -0700 (PDT) Received: from mail-wg0-x231.google.com (mail-wg0-x231.google.com [IPv6:2a00:1450:400c:c00::231]) by ietfa.amsl.com (Postfix) with ESMTP id 83EAC21F9A8B for ; Thu, 6 Jun 2013 10:36:08 -0700 (PDT) Received: by mail-wg0-f49.google.com with SMTP id a12so513457wgh.4 for ; Thu, 06 Jun 2013 10:36:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=0n5kLvuIM5SmFH6aWM8/6HBkMX4ckWhYZZqJ3baz4co=; b=snH32EwZHJzMbEjENgGzDXP26H1xMRLFeNO9JDst5ztuP9lJoDSKmK42h952hg/zDp RZaEn2JI0r0aNJ08U0LibM0aZG4kHqrOE5W6WEHnhSixGDxnrfqP2heRSdz/5YD2s5Cq WQu7a7zOdtgEhnJreFVgJrjlKjtyNwp9zE0xahMqYWF0goiEzDyUbMYbVKQ2dSDdhd+t MUIvKwyh52HrODGkW1vBFGoIcZL7qQfCMBqlm/Z/qm0EqCyKu7Pipf3pp14/h9dWykB7 7HZ722Kas6QKUDu6JGW1kwCe92ocqMt2K5e/X63Q9BoZMWMaG1Gm6WFEVt6nar2Fd4Cm q37g== MIME-Version: 1.0 X-Received: by 10.180.184.2 with SMTP id eq2mr10450243wic.50.1370540167624; Thu, 06 Jun 2013 10:36:07 -0700 (PDT) Received: by 10.227.97.6 with HTTP; Thu, 6 Jun 2013 10:36:07 -0700 (PDT) In-Reply-To: <386096B1-A43E-43E1-AD03-90424958D9B3@yahoo.com> References: <51AF8479.5080002@crockford.com> <51AF9ACF.5020507@cisco.com> <51AFB3F8.8060708@crockford.com> <8F32953C-C788-4DC9-888E-920E2BEB7FDD@yahoo.com> <831B8E46-F239-4353-8F95-8DF3F9BD2E78@yahoo.com> <51AFC924.2030805@crockford.com> <386096B1-A43E-43E1-AD03-90424958D9B3@yahoo.com> Date: Thu, 6 Jun 2013 10:36:07 -0700 Message-ID: From: Tatu Saloranta To: Vinny A Content-Type: multipart/alternative; boundary=001a11c3660cd780af04de7fbf42 Cc: Paul Hoffman , "json@ietf.org" Subject: Re: [Json] The names within an object SHOULD be unique. X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 06 Jun 2013 17:36:10 -0000 --001a11c3660cd780af04de7fbf42 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Jun 6, 2013 at 9:40 AM, Vinny A wrote: > On Jun 6, 2013, at 10:24 AM, Paul Hoffman wrote: > > The new text should use language that is already in RFC 4627; "key" is not > such a word. To be fair to implementers, the new document also needs to > deal with both emitters and parsers. > > Proposal: > > In Section 2.2: > Current: > The names within an object SHOULD be unique. > Proposed: > If the names within an object are not unique, the result of parsing the > object is unpredictable, and the parse may even fail completely. Thus, > the names within an object SHOULD be unique. > > In Section 4, add a new paragraph: > If a parser encounters an object with duplicate names, the parser MAY > fail to parse the JSON text; if the parser accepts objects with duplicate > names, it SHOULD accept only the last name/value pair that has the > duplicate name. > > > If we have to recommend to both parsers and emitters, I'd like to make a > slight change to your wording: > > > In Section 2.2: > Current: > The names within an object SHOULD be unique. > Proposed: > * The names within an object SHOULD be unique. Non-unique keys have > unpredictable effects (refer to sections 4 & 5).* > > This sounds good. > In Section 4 (Parsers) add a new paragraph: > *If a parser encounters an object with duplicate names, the parser > MAY fail to parse the JSON text; if the parser accepts objects with > duplicate names, it MUST accept only the last name/value pair that has the > duplicate name. * > > In Section 5 (Generators) add a new paragraph: > * A JSON generator SHOULD not duplicate names. If duplicate names are > generated, the authoritative name/value pair MUST be listed last.* > I find this problematic from streaming parsing perspective: if JSON content is to be exposed as a stream of tokens, then this behavior is impractical to implement. Even exposing just the first such key (or entry) is problematic due to need to keep track of all seen keys. But at least it is more practical than filtering out all but last. Streaming parsing is the natural way to level processing, similar to XML division of labor (SAX/Stax in Java, DOM/databind/XSLT on top), and although more commonly used by frameworks and not end users, is an important and common use case. -+ Tatu +- --001a11c3660cd780af04de7fbf42 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Thu, Jun 6, 2013 at 9:40 AM, Vinny A <jsontest@yahoo.com&g= t; wrote:
On Jun 6, 2013, at 10:24 AM, Paul Hoffman <<= a href=3D"mailto:paul.hoffman@vpnc.org" target=3D"_blank">paul.hoffman@vpnc= .org> wrote:
The new text should use language= that is already in RFC 4627; "key" is not such a word. To be fai= r to implementers, the new document also needs to deal with both emitters a= nd parsers.

Proposal:

In Sectio= n 2.2:
Current:
=A0=A0The names within an o= bject SHOULD be unique.
Proposed:
=A0=A0If = the names within an object are not unique, the result of parsing the=A0
=A0=A0object is unpredictable, and the parse may even fail completely= . Thus,
=A0=A0the names within an object SHOULD be unique.<= /span>

In Section 4, add a new paragraph:<= br>=A0=A0If a parser encounters an object with duplicate names, the p= arser MAY
=A0=A0fail to parse the JSON text; if the parser accepts objects with= duplicate
=A0=A0names, it SHOULD accept only the last name= /value pair that has the
=A0=A0duplicate name.=A0

If we have to recommend to both parsers= and emitters, I'd like to make a slight change to your wording:=


In Section 2.2:
Current:
=A0 =A0=A0The names within an object SHOULD be unique.
Proposed:
=A0 =A0The names=A0within an object SH= OULD be unique. Non-unique keys have unpredictable effects (refer to sectio= ns 4 & 5).


This so= unds good.

=A0
In Section 4 (Parsers) add a new paragraph:
=A0 = If a parser encounters an object with duplicate names, the parser MAY=A0= fail to parse the JSON text; if the parser accepts objects with duplicate= =A0names, it MUST accept only the last name/value pair that has the duplica= te name.=A0

In Section 5 (Generators) add a new paragraph:
=A0 =A0A JSON generator SHOULD not duplicate names. If duplic= ate names are generated, the authoritative name/value pair MUST be listed l= ast.


I find this pro= blematic from streaming parsing perspective: if JSON content is to be expos= ed as a stream of tokens, then this behavior is impractical to implement. E= ven exposing just the first such key (or entry) is problematic due to need = to keep track of all seen keys. But at least it is more practical than filt= ering out all but last.

Streaming parsing is the natural way to level pro= cessing, similar to XML division of labor (SAX/Stax in Java, DOM/databind/X= SLT on top), and although more commonly used by frameworks and not end user= s, is an important and common use case.

-+ Tatu +-

--001a11c3660cd780af04de7fbf42-- From paul.hoffman@vpnc.org Thu Jun 6 10:41:24 2013 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 A97A021F9A1A for ; Thu, 6 Jun 2013 10:41:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.155 X-Spam-Level: X-Spam-Status: No, score=-102.155 tagged_above=-999 required=5 tests=[AWL=0.444, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 69s-NfHypiD7 for ; Thu, 6 Jun 2013 10:41:24 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 2787421F8EC3 for ; Thu, 6 Jun 2013 10:41:19 -0700 (PDT) Received: from [10.20.30.90] (50-0-66-165.dsl.dynamic.sonic.net [50.0.66.165]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r56HfH71034581 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 6 Jun 2013 10:41:17 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) From: Paul Hoffman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: Date: Thu, 6 Jun 2013 10:41:16 -0700 To: "json@ietf.org" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) Subject: [Json] Call for real-world examples of how parsers deal with duplicate keys X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 06 Jun 2013 17:41:24 -0000 Greetings again. Knowing what current parsers do with duplicate keys = might be useful to this discussion. Of course, some people will exclaim = "but that's wrong!" to some of what we see, but seeing it may be useful = nonetheless. I propose the following JSON text for the tests: {"a":1,"a":2} --Paul Hoffman =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D And I'll start with Python. from __future__ import print_function import json a =3D '{"a":1,"a":2}' print(json.loads(a)) # python2.6 keytest.py {u'a': 2} # python2.7 keytest.py {u'a': 2} # python3.2 keytest.py {'a': 2} From jhildebr@cisco.com Thu Jun 6 10:49:20 2013 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 E558521F9AE1 for ; Thu, 6 Jun 2013 10:49:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZBbiJABnEy4F for ; Thu, 6 Jun 2013 10:49:15 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 50BD221F9AD7 for ; Thu, 6 Jun 2013 10:49:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1229; q=dns/txt; s=iport; t=1370540955; x=1371750555; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=kv8yXmPyjUTITCzFVLMLYMywh03hbXW0poS3J8rtuy0=; b=Sr7jll8p9dh7oxopOTIbcSvm2HHqVm5DHGxoLDszC3UfMXgefM/krpkt Tljdk/JAL7DY0kGEDsQv7rFi+K5pPomdbvZl9Z11PgnwjkLSVeYEsZz2W BxN7tsmhwPHZHrTkMmLKHS6Euy7ZDTtC2WWuFCvpsDXNC4JAmKUXS/a1g I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AggFADXLsFGtJV2c/2dsb2JhbABZgwm/d3kWdIIjAQEBAwE6PxIBCCIUQiUCBA4FCId/Brt9jwExB4J6YQOTbZUSgw+CJw X-IronPort-AV: E=Sophos;i="4.87,816,1363132800"; d="scan'208";a="219702172" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-6.cisco.com with ESMTP; 06 Jun 2013 17:49:05 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r56Hn5N4011269 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 6 Jun 2013 17:49:05 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.56]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.02.0318.004; Thu, 6 Jun 2013 12:49:05 -0500 From: "Joe Hildebrand (jhildebr)" To: Douglas Crockford Thread-Topic: [Json] Unpaired surrogates in JSON strings Thread-Index: AQHOYkg5aH+sWe/75UqTmsr195d0xpkoJhcAgAAN2ICAAAJhAIAApyAAgAAJfgA= Date: Thu, 6 Jun 2013 17:49:04 +0000 Message-ID: In-Reply-To: <51B06F38.8050707@crockford.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [10.21.88.234] Content-Type: text/plain; charset="us-ascii" Content-ID: <2312B8ABD1760946ABEDFF8AB4434E70@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Tim Bray , Paul Hoffman , "json@ietf.org" Subject: Re: [Json] Unpaired surrogates in JSON strings X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 06 Jun 2013 17:49:21 -0000 On 6/6/13 5:15 AM, "Douglas Crockford" wrote: >> That's not a code point. That's half a surrogate pair for a code point >> encoded in UTF16. It's only the same in the BMP. >> >What then is the standard name for a 16-bit element of text? When >JavaScript was created, that word was character. What is the word now? Let's say rather that we understand Unicode better than we did then. When we only cared about the Basic Multilingual Plane, it was easy to just say "wchar_t", and hope the compiler writer knew more than we did. Technically, wchar_t was supposed to be big enough to hold any supported code point, but in practice, it was usually 16 bits. This forced people to start using UTF16 in wchar_t's when they needed to access codepoints outside the BMP. This was a hack, but the Java, JavaScript, and .Net folks went with it in order to make their implementations a little easier. Some newer languages are using UTF8 as their internal String representation, which works ok. Note that counting code points correctly in either system requires a full scan of the string. UTF32 doesn't suffer from this, but always requires 4 bytes per code point. --=20 Joe Hildebrand From stefan@drees.name Thu Jun 6 10:49:44 2013 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 3479F21F9AFB for ; Thu, 6 Jun 2013 10:49:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nyk0ZTSbhPYd for ; Thu, 6 Jun 2013 10:49:38 -0700 (PDT) Received: from mout.web.de (mout.web.de [212.227.15.3]) by ietfa.amsl.com (Postfix) with ESMTP id 9563221F9AF1 for ; Thu, 6 Jun 2013 10:49:38 -0700 (PDT) Received: from newyork.local.box ([77.13.209.10]) by smtp.web.de (mrweb004) with ESMTPSA (Nemesis) id 0Lex9L-1U2Hbb1J67-00qhBG; Thu, 06 Jun 2013 19:49:36 +0200 Message-ID: <51B0CBAF.9070809@drees.name> Date: Thu, 06 Jun 2013 19:49:35 +0200 From: Stefan Drees User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Paul Hoffman References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:riyGuyBBhpGRy2Fmpks8Bg7DSzW5dIRUYeoCoQk6jkOuA+sXvPJ arAzYWn66wts8v1xhIInYKQbJosaolnZ5LZ0DPja+nzYVvr1xjqsoEiOR53FdLoNs21Ibae /754rnHRqVERoc9cpHm/ZhslD53zEn1KBLDEU23MTgbqNbv/lQjHkvfCl85hf66q68r+PUz iTRZmCWspohomhpMLUJQg== Cc: "json@ietf.org" Subject: Re: [Json] Call for real-world examples of how parsers deal with duplicate keys X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stefan@drees.name List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 17:49:44 -0000 On 06.06.13 19:41, Paul Hoffman wrote: > Greetings again. Knowing what current parsers do with duplicate keys might be useful to this discussion. Of course, some people will exclaim "but that's wrong!" to some of what we see, but seeing it may be useful nonetheless. > > I propose the following JSON text for the tests: > > {"a":1,"a":2} > > --Paul Hoffman > > ============================== > > And I'll start with Python. > > from __future__ import print_function > import json > a = '{"a":1,"a":2}' > print(json.loads(a)) > > # python2.6 keytest.py > {u'a': 2} > # python2.7 keytest.py > {u'a': 2} > # python3.2 keytest.py > {'a': 2} don't tell anyone, but I'll continue with php (5.3.25): $> cat test_json.php php test_json.php stdClass Object ( [a] => 2 ) All the best, Stefan. From petejson@codalogic.com Thu Jun 6 10:50:15 2013 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 BE16E21F9AA2 for ; Thu, 6 Jun 2013 10:50:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.932 X-Spam-Level: X-Spam-Status: No, score=-0.932 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_HEAD_XUNSENT=1.666, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S6wO8XE1wVKM for ; Thu, 6 Jun 2013 10:50:11 -0700 (PDT) Received: from codalogic.com (codalogic.com [94.136.60.219]) by ietfa.amsl.com (Postfix) with ESMTP id 7AC0621F9AE2 for ; Thu, 6 Jun 2013 10:50:09 -0700 (PDT) Received: (qmail 28170 invoked from network); 6 Jun 2013 18:50:05 +0100 Received: from host86-132-241-164.range86-132.btcentralplus.com (HELO codalogic) (86.132.241.164) by codalogic.com with (RC4-MD5 encrypted) SMTP; 6 Jun 2013 18:50:05 +0100 Message-ID: <5781A1976FE5419DAF8EF46B480E420B@codalogic> From: "Pete Cordell" To: "Tatu Saloranta" , "Stephan Beal" X-Unsent: 1 References: <51AF8479.5080002@crockford.com><51AF8A9B.1020900@crockford.com><51af8f23.85f8420a.597e.0ccbSMTPIN_ADDED_BROKEN@mx.google.com><51afa4ff.89e9420a.6d90.212fSMTPIN_ADDED_BROKEN@mx.google.com> x-vipre-scanned: 0243A29800482A0243A3E5 Date: Thu, 6 Jun 2013 18:50:05 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Cc: json@ietf.org Subject: Re: [Json] The names within an object SHOULD be unique. X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 06 Jun 2013 17:50:15 -0000 Original Message From: "Tatu Saloranta" . > For these reasons, I would prefer simple discouraging use of duplicate > names, without trying to specify "but if you must, then use X" processing. +1. (editing text suggested elsewhere) Can you scare the heck out of implementers by saying something like: In Section 4 (Parsers) add a new paragraph: If a parser encounters an object with duplicate names, the behavior is undefined. The parser MAY fail to parse the JSON text, it MAY only accept the first name/value pair that has the duplicate name, it MAY only accept the last name/value pair that has the duplicate name, it MAY ignore all name/value pair that have the duplicate name, or it MAY perform some other action. In Section 5 (Generators) add a new paragraph: A JSON generator SHOULD not duplicate names. Pete Cordell Codalogic Ltd C++ tools for C++ programmers, http://codalogic.com Read & write XML in C++, http://www.xml2cpp.com From jhildebr@cisco.com Thu Jun 6 10:51:31 2013 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 7E81921F9B08 for ; Thu, 6 Jun 2013 10:51:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NfwkfXifCG0N for ; Thu, 6 Jun 2013 10:51:26 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 449E421F9B29 for ; Thu, 6 Jun 2013 10:51:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=552; q=dns/txt; s=iport; t=1370541082; x=1371750682; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=0v+okb6fO0IohcmQin1zCgvFCW0+2SENXrrgiFKbOxs=; b=GOZ26zz6J88LRzB35D4DfXlMupEToIZmS/wPiozj61YDX1k0gGJq+0G9 AlPFhrF9uyNJkPvVaVc6Xm1336L90b8NvOyEaGGddaNlvLyYAF1E1U/d0 R8KMH9msXJN2o5mVdRjmyenu431OyZRGCEu2ld6g+CgnZxbDKaT/zzjGM E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgcFALPKsFGtJXG//2dsb2JhbABZgwm/d3gWdIIlAQR5EgEIDhRWJQIEAQ0FCIgFu3uOfwIxB4J6YQOIaKAXgw+CJw X-IronPort-AV: E=Sophos;i="4.87,816,1363132800"; d="scan'208";a="219697259" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-5.cisco.com with ESMTP; 06 Jun 2013 17:51:21 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r56HpLQv021207 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 6 Jun 2013 17:51:21 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.56]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.02.0318.004; Thu, 6 Jun 2013 12:51:20 -0500 From: "Joe Hildebrand (jhildebr)" To: Tim Bray , "Matt Miller (mamille2)" Thread-Topic: [Json] Strings Thread-Index: AQHOYks3qXYMVZxHuUK8pIRm8dGJzZkn+HmAgAEjmgCAABz3AIAAAaCA//+s34A= Date: Thu, 6 Jun 2013 17:51:20 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [10.21.88.234] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <6D0994C2D37D70428AB0178D6F291B13@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Paul Hoffman , "json@ietf.org" Subject: Re: [Json] Strings X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 06 Jun 2013 17:51:31 -0000 On 6/6/13 10:48 AM, "Tim Bray" wrote: >If keys are unicode strings, the proper languagee is: > > >=B3For purpose of establishing key equality, comparisons MUST be conducted= , >after all escaping is done, on a character-by-character basis by >comparing numeric character codepoints. There is to be no modification of >any kind to the characters in keys, including > case-changing or combining-form normalization.=B2 maybe remove character-by-character as redundant and possibly confusing? --=20 Joe Hildebrand From jhildebr@cisco.com Thu Jun 6 10:53:09 2013 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 1B3AB21F9B08 for ; Thu, 6 Jun 2013 10:53:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rmTJqGC791QR for ; Thu, 6 Jun 2013 10:53:03 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 66A0821F9B2F for ; Thu, 6 Jun 2013 10:53:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=911; q=dns/txt; s=iport; t=1370541183; x=1371750783; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=Dgt57g4C97MdUkw6ULBdBbfj1DnEP9B3ioMWUEAnP7A=; b=GiAU+c1aT651SWUiLxDyi7h/AhJkOgAA3srQNeozP1Y+DNp+xCp3cpGq JrvkhxYCuTn9kSkybyB+Ap8b3dGiNd9MJpV54RZNVQvbeh1Gs76Gtiicf IUqGekmoN5EiYAZ8UwYgPZ7LIDBVM7NVbZ+0EFhx2w9uFRpuu6KKSNsWg 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AggFADXLsFGtJXG8/2dsb2JhbABZgwm/d3kWdIIjAQEBBDoyCgMSAQgYChRCJQIEAQ0FCIgFu32PATEHgnphA6h/gw+CJw X-IronPort-AV: E=Sophos;i="4.87,816,1363132800"; d="scan'208";a="219704158" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-6.cisco.com with ESMTP; 06 Jun 2013 17:53:03 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r56Hr2Bf019730 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 6 Jun 2013 17:53:02 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.56]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.02.0318.004; Thu, 6 Jun 2013 12:53:02 -0500 From: "Joe Hildebrand (jhildebr)" To: Paul Hoffman , Carsten Bormann Thread-Topic: [Json] Update reference for ABNF Thread-Index: AQHOYlR0vnpujuiFN0KbF2i2aAN76ZkoQXSAgAAA8ACAAJUMAIAATbWAgAAU64CAAAIGAP//q9yA Date: Thu, 6 Jun 2013 17:53:02 +0000 Message-ID: In-Reply-To: <67FC4D12-AE76-45AC-A9B1-18FA33D030B4@vpnc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [10.21.88.234] Content-Type: text/plain; charset="us-ascii" Content-ID: <901A7A74D0391B4DB19DBCB0159A2286@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "json@ietf.org" Subject: Re: [Json] Update reference for ABNF X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 06 Jun 2013 17:53:09 -0000 On 6/6/13 10:54 AM, "Paul Hoffman" wrote: >On Jun 6, 2013, at 9:46 AM, Carsten Bormann wrote: > >> On Jun 6, 2013, at 17:32, Paul Hoffman wrote: >>=20 >>> Will one or more of you who care about good ABNF volunteer to do >>>careful checks against RFC 5234? >>=20 >> Well, so far I only checked that 5234 is not worse for 4627bis than >>4234. >> But I can also volunteer to torture-test the ABNF itself. > >Thank you, we have a volunteer! Who will be the second? That's a serious >question: some WGs have passed non-ABNF-compliant documents due to having >too few checkers. Fortunately, there is little ABNF in this document, so >that should cause others to want to gain this new and valuable skill. I've got some adequate abnf parsing code that I wrote last year against 5234. I'll at least run that. --=20 Joe Hildebrand From stefan@drees.name Thu Jun 6 11:04:19 2013 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 41E1E21F99D1 for ; Thu, 6 Jun 2013 11:04:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e7ly-8Cdj1GP for ; Thu, 6 Jun 2013 11:04:14 -0700 (PDT) Received: from mout.web.de (mout.web.de [212.227.17.12]) by ietfa.amsl.com (Postfix) with ESMTP id A30DC21E8054 for ; Thu, 6 Jun 2013 11:04:13 -0700 (PDT) Received: from newyork.local.box ([77.13.209.10]) by smtp.web.de (mrweb003) with ESMTPSA (Nemesis) id 0LnS3i-1UAlp12Q18-00hqkv; Thu, 06 Jun 2013 20:04:09 +0200 Message-ID: <51B0CF18.1060108@drees.name> Date: Thu, 06 Jun 2013 20:04:08 +0200 From: Stefan Drees User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Paul Hoffman References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V02:K0:jGD7H3QhoVZrvGyGQdA+XEKZkxiuAzQsjXTHF2/8rfu 7x4agHIS92/rX3oBSAqu4XVjOxPjOWw1my+AZ0ztLc5APSH4Hu uXaAVjKFHG0qx0vnWH1EhYJPwMpVktHwSSftPYs1Z+FNhh/yEV WLcoylez4svFakkwvrQkQePEPsl3jKQpzF+imADIxdysUgMoiL sifL+ejb+OI8hVnpkS0TQ== Cc: "json@ietf.org" Subject: Re: [Json] Call for real-world examples of how parsers deal with duplicate keys X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stefan@drees.name List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 18:04:19 -0000 On 06.06.13 19:41, Paul Hoffman wrote: > Greetings again. Knowing what current parsers do with duplicate keys might be useful to this discussion. Of course, some people will exclaim "but that's wrong!" to some of what we see, but seeing it may be useful nonetheless. > > I propose the following JSON text for the tests: > > {"a":1,"a":2} > > --Paul Hoffman > > ============================== > > And I'll start with Python. > > from __future__ import print_function > import json > a = '{"a":1,"a":2}' > print(json.loads(a)) > > # python2.6 keytest.py > {u'a': 2} > # python2.7 keytest.py > {u'a': 2} > # python3.2 keytest.py > {'a': 2} > and also ruby(1.8.7) and the JSON parser as implemented in the json gem: $> cat test_json.rb require 'rubygems' require 'json' require 'pp' pp JSON.parse('{"a":1,"a":2}') $> ruby ./test_json.rb {"a"=>2} All the best, Stefan. From framefritti@gmail.com Thu Jun 6 11:05:33 2013 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 02F7021E80A5 for ; Thu, 6 Jun 2013 11:05:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.004 X-Spam-Level: X-Spam-Status: No, score=-0.004 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_75=0.6, J_CHICKENPOX_84=0.6, NO_RELAYS=-0.001, WEIRD_QUOTING=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uz5cz-W1emUg for ; Thu, 6 Jun 2013 11:05:32 -0700 (PDT) Received: from mail-la0-x22d.google.com (mail-la0-x22d.google.com [IPv6:2a00:1450:4010:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 9612821E80A9 for ; Thu, 6 Jun 2013 11:05:22 -0700 (PDT) Received: by mail-la0-f45.google.com with SMTP id fr10so2882138lab.18 for ; Thu, 06 Jun 2013 11:05:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=fjNpfmSxr5VCovk+hNcrWHlVHf36ixiZCGKq9dKVMpM=; b=xYTU3VJ+NijnjM/xGs3L+r4SjKiiEpqHNiGU/+LU1R/go3yznn6VP5PFLCmd/TA3e7 6WK6MoMVYf4Lej4DwpQlQuzW4+nPRhPHR/dMXABXdsYaRaf59SiDeavU6oQk493+TYlF tDvwOczNtCJxe70941q3e9lQEUQrMpSoI8waKSAc5W+ZfsAqMdkXMDOUeAjGFVHQzV2z 4URDqDUwGPQi6wI1aHnXPgsWRUtMxwqUIGHHJh8fmNIz6tetwXawBTsS7PdTEwxQXpKo snIZrdk6VmrRMIw2uflFfVTD6ijLQRtG09CSAAu6a6VJ9I9mWSuAVrvXFrFboEJbjQvI NlFQ== MIME-Version: 1.0 X-Received: by 10.112.199.100 with SMTP id jj4mr394944lbc.91.1370541921465; Thu, 06 Jun 2013 11:05:21 -0700 (PDT) Received: by 10.112.143.165 with HTTP; Thu, 6 Jun 2013 11:05:21 -0700 (PDT) In-Reply-To: <51B0CBAF.9070809@drees.name> References: <51B0CBAF.9070809@drees.name> Date: Thu, 6 Jun 2013 20:05:21 +0200 Message-ID: From: Riccardo Bernardini To: "json@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [Json] Call for real-world examples of how parsers deal with duplicate keys X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 06 Jun 2013 18:05:33 -0000 Ada language, parser in the package GNATCOLL.JSON (used, I think, also by the Ada Web Server) -------- Source code ------- with GNATCOLL.JSON; use GNATCOLL.JSON; with Ada.Text_IO; use Ada.Text_IO; procedure my_test is Parsed : constant JSON_Value := Read ("{""a"":1,""a"":2}", ""); Val : Integer; begin Val := Get (Parsed, "a"); Put_Line ("A=" & Integer'Image (Val)); end my_test; ---- Output ---- $ ./my_test A= 2 On Thu, Jun 6, 2013 at 7:49 PM, Stefan Drees wrote: > On 06.06.13 19:41, Paul Hoffman wrote: >> >> Greetings again. Knowing what current parsers do with duplicate keys might >> be useful to this discussion. Of course, some people will exclaim "but >> that's wrong!" to some of what we see, but seeing it may be useful >> nonetheless. >> >> I propose the following JSON text for the tests: >> >> {"a":1,"a":2} >> >> --Paul Hoffman >> >> ============================== >> >> And I'll start with Python. >> >> from __future__ import print_function >> import json >> a = '{"a":1,"a":2}' >> print(json.loads(a)) >> >> # python2.6 keytest.py >> {u'a': 2} >> # python2.7 keytest.py >> {u'a': 2} >> # python3.2 keytest.py >> {'a': 2} > > > don't tell anyone, but I'll continue with php (5.3.25): > $> cat test_json.php > $d = json_decode('{"a":1,"a":2}'); > print_r($d); > """ > > $> php test_json.php > stdClass Object > ( > [a] => 2 > ) > > All the best, > Stefan. > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json From mamille2@cisco.com Thu Jun 6 11:05:45 2013 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 6550321E80AA for ; Thu, 6 Jun 2013 11:05:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h9k4zs0YT9Z6 for ; Thu, 6 Jun 2013 11:05:40 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id E17A021E80B3 for ; Thu, 6 Jun 2013 11:05:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7328; q=dns/txt; s=iport; t=1370541940; x=1371751540; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=X2GfgQEfPw7oqfWHsfwI/N2q6RpJCUajdsm9WOfZLjM=; b=elxsmNpikp0Qwrah0u5RNCXhBMC4E+L6ZRsINMHs/kfIJgZIfSwK8Dhn N4RpHxBl3F27wWaJTEQ+JeaL3cL3eW/PMbve4DyGDlx2pPrvffFnFjkUp YHzj2Jp69dQtdPy+ZMbWo97LRuN5UBPIK1zm5SpcTraAjmVGEioTwlf2G s=; X-Files: smime.p7s : 4136 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgkFAE7OsFGtJXG8/2dsb2JhbABZgwkwv0d5FnSCIwEBAQMBHVwFCwIBCCIkAjAlAgQOBQgGh3kGvAOPATEHCYJxYQOQAIEshzyQF4MPgic X-IronPort-AV: E=Sophos;i="4.87,816,1363132800"; d="p7s'?scan'208";a="219706277" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-5.cisco.com with ESMTP; 06 Jun 2013 18:05:39 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r56I5bjh009456 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 6 Jun 2013 18:05:37 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.24]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.02.0318.004; Thu, 6 Jun 2013 13:05:37 -0500 From: "Matt Miller (mamille2)" To: Paul Hoffman Thread-Topic: [Json] Call for real-world examples of how parsers deal with duplicate keys Thread-Index: AQHOYt0SaR52gsJ1Vkq+L7gyeb9HuZkpTvoA Date: Thu, 6 Jun 2013 18:05:36 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.129.24.59] Content-Type: multipart/signed; boundary="Apple-Mail=_B9DE1BBF-213B-4F17-8444-9C106EF5AC6A"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Cc: "json@ietf.org" Subject: Re: [Json] Call for real-world examples of how parsers deal with duplicate keys X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 06 Jun 2013 18:05:45 -0000 --Apple-Mail=_B9DE1BBF-213B-4F17-8444-9C106EF5AC6A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jun 6, 2013, at 11:41 AM, Paul Hoffman wrote: > Greetings again. Knowing what current parsers do with duplicate keys = might be useful to this discussion. Of course, some people will exclaim = "but that's wrong!" to some of what we see, but seeing it may be useful = nonetheless. >=20 > I propose the following JSON text for the tests: >=20 > {"a":1,"a":2} >=20 > --Paul Hoffman >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D >=20 > And I'll start with Python. >=20 > from __future__ import print_function > import json > a =3D '{"a":1,"a":2}' > print(json.loads(a)) >=20 > # python2.6 keytest.py > {u'a': 2} > # python2.7 keytest.py > {u'a': 2} > # python3.2 keytest.py > {'a': 2} Experiments should always have a control! I think we can consider this = the control: -----BEGIN JAVASCRIPT----- var input =3D '{"a":1,"a":2}'; var output; output =3D JSON.parse(input); output =3D JSON.stringify(output); console.log(output); -----END JAVASCRIPT----- # node.js 0.10.8 {"a":2} # Firefox 22 {"a":2} # Safari 6.5 {"a":2} # Chrome 27 {"a":2} - m&m Matt Miller < mamille2@cisco.com > Cisco Systems, Inc. --Apple-Mail=_B9DE1BBF-213B-4F17-8444-9C106EF5AC6A Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMezCCBjQw ggQcoAMCAQICAR4wDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDE1NVoX DTE3MTAyNDIxMDE1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMcJg8zOLdgasSmkLhOrlr6KMoOMpohBllVHrdRvEg/q6r8jR+EK 75xCGhR8ToREoqe7zM9/UnC6TS2y9UKTpT1v7RSMzR0t6ndl0TWBuUr/UXBhPk+Kmy7bI4yW4urC +y7P3/1/X7U8ocb8VpH/Clt+4iq7nirMcNh6qJR+xjOhV+VHzQMALuGYn5KZmc1NbJQYclsGkDxD z2UbFqE2+6vIZoL+jb9x4Pa5gNf1TwSDkOkikZB1xtB4ZqtXThaABSONdfmv/Z1pua3FYxnCFmdr /+N2JLKutIxMYqQOJebr/f/h5t95m4JgrM3Y/w7YX9d7YAL9jvN4SydHsU6n65cCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRTcu2SnODaywFc fH6WNU7y1LhRgjAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBAAqDCH14qywG XLhjjF6uHLkjd02hcdh9hrw+VUsv+q1eeQWB21jWj3kJ96AUlPCoEGZ/ynJNScWy6QMVQjbbMXlt UfO4n4bGGdKo3awPWp61tjAFgraLJgDk+DsSvUD6EowjMTNx25GQgyYJ5RPIzKKR9tQW8gGK+2+R HxkUCTbYFnL6kl8Ch507rUdPPipJ9CgJFws3kDS3gOS5WFMxcjO5DwKfKSETEPrHh7p5shuuNktv sv6hxHTLhiMKX893gxdT3XLS9OKmCv87vkINQcNEcIIoFWbP9HORz9v3vQwR4e3ksLc2JZOAFK+s sS5XMEoznzpihEP0PLc4dCBYjbvSD7kxgDwZ+Aj8Q9PkbvE9sIPP7ON0fz095HdThKjiVJe6vofq +n6b1NBc8XdrQvBmunwxD5nvtTW4vtN6VY7mUCmxsCieuoBJ9OlqmsVWQvifIYf40dJPZkk9YgGT zWLpXDSfLSplbY2LL9C9U0ptvjcDjefLTvqSFc7tw1sEhF0n/qpA2r0GpvkLRDmcSwVyPvmjFBGq Up/pNy8ZuPGQmHwFi2/14+xeSUDG2bwnsYJQG2EdJCB6luQ57GEnTA/yKZSTKI8dDQa8Sd3zfXb1 9mOgSF0bBdXbuKhEpuP9wirslFe6fQ1t5j5R0xi72MZ8ikMu1RQZKCyDbMwazlHiMIIGPzCCBSeg AwIBAgIDBoRIMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcN MTMwNDMwMjE1NDQyWhcNMTQwNTAyMDUzOTA0WjBbMRkwFwYDVQQNExBiN2F6NndOY0t0R3JtMEpF MRswGQYDVQQDDBJtYW1pbGxlMkBjaXNjby5jb20xITAfBgkqhkiG9w0BCQEWEm1hbWlsbGUyQGNp c2NvLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJbKBMsG+9UFTx9uq/bhhXgu vJvO8z7cwKaqqwZhVf5z/kHFyCNijtmTOE+YXjA8mWR4aoBwB5SvGypI/cJUofJ+AlBTC4g+RMx/ K0Ab4/jQqTQz9CDzMOB+Wm+rt8ZJ7A8ZzOJmNDAsf/VvB8l2A1SQz1UsAixgH16NTr8SlblAXEKk 4hwpCudUiNjjQokqJ0H686UBKVorcZSgXaza8XMqGtJF/8mNhR9GQYi7Xht1ky+9LFOrto2daZto KJRwMeVusVdHUeKEQSu7jztw8HchH3KEb7Q+r5X+hhDZoddfKE8d5eyPuhiZdrzv7OlNZ0fSLdx7 3AE3nx9/R5YlXucCAwEAAaOCAtgwggLUMAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQW MBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQUxGd+/qrdVudHrIKkw5xOMY7eaLUwHwYD VR0jBBgwFoAUU3Ltkpzg2ssBXHx+ljVO8tS4UYIwHQYDVR0RBBYwFIESbWFtaWxsZTJAY2lzY28u Y29tMIIBTAYDVR0gBIIBQzCCAT8wggE7BgsrBgEEAYG1NwECAzCCASowLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0 Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBp c3N1ZWQgYWNjb3JkaW5nIHRvIHRoZSBDbGFzcyAxIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9m IHRoZSBTdGFydENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBw dXJwb3NlIGluIGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMDYG A1UdHwQvMC0wK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUxLWNybC5jcmwwgY4G CCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIv Y2xhc3MxL2NsaWVudC9jYTBCBggrBgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2Vy dHMvc3ViLmNsYXNzMS5jbGllbnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRz c2wuY29tLzANBgkqhkiG9w0BAQUFAAOCAQEAlDhXbGEI7lbqUcu5r2JHZaMsbRZda/99ZqODzWGX 0llou9jGccsAWDPPwRRe2+ROpXfH4cuJZElTcLDeZSp/qpXKhjYieFSX8+Ml9sKEj5UOSqQLyoLk PtrIJV12Jk3nuG2Jc0UeEnGwK/aqtzy7+bfEVI0ziyVM2gChHh0RH74KyiwYWknbOTRIkZcz/ulE DVFQp63uj6wfmDNvAUHBAdhKVqA1S/rfP1KcDZpf1NfvwXJibiqTRA6K1EOxTJOP41n/XdvHqHXL RWL2xrOUI9/URANr/ok3OrsuZEMFnAAGefS1bWS/hFtUGVkHGiKEBbyDW7da2ULXbuC7umrQnzGC A28wggNrAgEBMIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkG A1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwaESDAJBgUrDgMCGgUA oIIBrzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMzA2MDYxODA1 MzZaMCMGCSqGSIb3DQEJBDEWBBR7YGYUCNLnuaF8hro5sHoPM5qIWzCBpQYJKwYBBAGCNxAEMYGX MIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3Mg MSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwaESDCBpwYLKoZIhvcNAQkQAgsxgZeg gZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1 cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAx IFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDBoRIMA0GCSqGSIb3DQEBAQUABIIBAJZd gWw4NGnfCzbdg7bK1ujlGUXuj0xXQ6ucxGrTnJeq9Rr3DUfc0Z+Nggh5ixR1P+psKc5LC5bwQ3yR PlOigk9exnAJLKDI8rPBQAlBBikymC0TQ8teogzlWmL2Kjc+C+1bZ5hVcTwRmVZMjNugtL55K1LJ TVkDqxb992qTn6kR+m8LyO37ttXJs5ocmmaIAOR90MaA801UcW+tX/Wz2Cl1FG3wvXAZOCDBcWL0 gsIyY6fzJ0UpLoLCvEIoEogJyPsBvNybUDvlfzlU960ITzo3Pl7avgmowswVzAwDsicd0KYjIxUu sIDQpDMhBe531WU0dGHoPdf0mPh0UpxayE8AAAAAAAA= --Apple-Mail=_B9DE1BBF-213B-4F17-8444-9C106EF5AC6A-- From derhoermi@gmx.net Thu Jun 6 11:18:29 2013 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 64F0F21F9424 for ; Thu, 6 Jun 2013 11:18:29 -0700 (PDT) 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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A+83SeSQwwuq for ; Thu, 6 Jun 2013 11:18:25 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) by ietfa.amsl.com (Postfix) with ESMTP id A486721F9298 for ; Thu, 6 Jun 2013 11:18:24 -0700 (PDT) Received: from mailout-de.gmx.net ([10.1.76.20]) by mrigmx.server.lan (mrigmx002) with ESMTP (Nemesis) id 0MaXUl-1V4feY1UBl-00K8kw for ; Thu, 06 Jun 2013 20:18:23 +0200 Received: (qmail invoked by alias); 06 Jun 2013 18:18:22 -0000 Received: from p5B2318C1.dip0.t-ipconnect.de (EHLO netb.Speedport_W_700V) [91.35.24.193] by mail.gmx.net (mp020) with SMTP; 06 Jun 2013 20:18:22 +0200 X-Authenticated: #723575 X-Provags-ID: V01U2FsdGVkX19HU7Z3pbdHA/KRKymeoF7gDaTr1FOnoi3b29TCA7 gUsd7VVIBmtiup From: Bjoern Hoehrmann To: Paul Hoffman Date: Thu, 06 Jun 2013 20:18:23 +0200 Message-ID: References: In-Reply-To: X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 Cc: "json@ietf.org" Subject: Re: [Json] Call for real-world examples of how parsers deal with duplicate keys X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 06 Jun 2013 18:18:29 -0000 * Paul Hoffman wrote: >Greetings again. Knowing what current parsers do with duplicate keys >might be useful to this discussion. Of course, some people will exclaim >"but that's wrong!" to some of what we see, but seeing it may be useful >nonetheless. > >I propose the following JSON text for the tests: > >{"a":1,"a":2} I note that this test is insufficient for a conclusion like "takes the last value", but it should be okay for concluding "does not reject the input under default settings". With Perl, the JSON module on CPAN has a pure-perl module JSON::PP, but would generally prefer a a C-based module like JSON::XS when available (and `use JSON;` hides the choice). #!perl -w use JSON::PP; use Data::Dumper; print Dumper([ JSON::PP->new->decode('{"a":1,"a":2}') ]); and the same with JSON::XS in place of JSON::PP will print $VAR1 = [ { 'a' => 2 } ]; In Microsoft's .NET Framework the System.Runtime.Serialization.Json reader abstracts JSON into XML... using System; using System.Text; using System.Runtime.Serialization.Json; class Program { static void Main(string[] args) { var json = "{\"a\":1,\"a\":2}"; var bytes = UTF8Encoding.UTF8.GetBytes(json); var p = JsonReaderWriterFactory.CreateJsonReader(bytes, new System.Xml.XmlDictionaryReaderQuotas()); while (p.Read()) { Console.WriteLine("{0}", p.ReadOuterXml()); } } } which results in 1 2 This being a streaming parser it reports both instances as they are in the document. -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ From douglas@crockford.com Thu Jun 6 12:15:22 2013 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 9B91611E80EE for ; Thu, 6 Jun 2013 12:15:22 -0700 (PDT) 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=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kW-wHC8eZilx for ; Thu, 6 Jun 2013 12:15:16 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id B6DDA11E80ED for ; Thu, 6 Jun 2013 12:15:16 -0700 (PDT) Received: from [192.168.114.223] ([216.113.168.135]) by mrelay.perfora.net (node=mrus2) with ESMTP (Nemesis) id 0M1WMb-1UVKWm0THt-00tRCf; Thu, 06 Jun 2013 15:15:15 -0400 Message-ID: <51B0DFB6.10803@crockford.com> Date: Thu, 06 Jun 2013 12:15:02 -0700 From: Douglas Crockford User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "json@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V02:K0:g3LL3NS+Dd/U5ewyzg++jwRAbpsdxyuKZYrNVTBtph3 caGYYfSh8MDVbwI69LLXaXkKoF24WiRHVez06nvto/oaUsMQs2 TFht4rttaBxVctKQdYh7cdAdt0W0xf4AcqQjysDsa0HSAiTjEI /1SEqsgeJDBOFPJ2KtA6sdzgHXNZx0XnS/UBJDvwqO3t6h/cxf ZJvPd3wY3HQhNMY6c0inRt52t0qLONt0QKfliiBr1EEx3XkEod 4I/TMVBf3afEOpFg1l+PDjMsYsR1DumdKIyDajuScmXOgHwqsj nkHcmFp7x47n8A+0+rkz0kfXwQraVIZKNEDShCY1ky6qDeEQBb X2iWwbLosPUGnXtqPzVw= Subject: [Json] Introduction X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 06 Jun 2013 19:15:22 -0000 I propose changing the introduction to de-emphasize JavaScript and emphasize Data Format, conforming to the new title. JSON is a text format for the serialization of structured data. It was inspired by the object literals of JavaScript, as defined in the ECMAScript Programming Language Standard, Fifth Edition[ECMA]. JSON can represent four primitive types (strings, numbers, booleans, and null) and two structured types (objects and arrays). A string is a sequence of zero or more characters. An object is an unordered collection of zero or more name/value pairs, where a name is a string and a value is a string, number, boolean, null, object, or array. An array is an ordered sequence of zero or more values. The terms "object" and "array" come from the conventions of JavaScript. JSON's design goals were for it to be minimal, portable, textual, and a subset of JavaScript. JSON stands for JavaScript Object Notation. From douglas@crockford.com Thu Jun 6 12:17:20 2013 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 8612C11E80ED for ; Thu, 6 Jun 2013 12:17:20 -0700 (PDT) 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=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gXM9wCJNUie3 for ; Thu, 6 Jun 2013 12:17:14 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id 946C221E8087 for ; Thu, 6 Jun 2013 12:17:14 -0700 (PDT) Received: from [192.168.114.223] ([216.113.168.135]) by mrelay.perfora.net (node=mrus4) with ESMTP (Nemesis) id 0MMTME-1Uk9Zu2u9W-007xEo; Thu, 06 Jun 2013 15:17:13 -0400 Message-ID: <51B0E02E.4070209@crockford.com> Date: Thu, 06 Jun 2013 12:17:02 -0700 From: Douglas Crockford User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "json@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V02:K0:RbTHixgqCBcyjWF+Oo/YYdggQsj0jA3i7nA7hhj5+hG LJovXNvFFxNDIpy94bAWuV3+jlNaX+oMDdLNnYmchu7awxwCuU o7MW8dc+yVZs0t7pcj1gUdBbS1lokUwVona21pvTK1NRlLUCvj AIjFpbDwLYZQGnqqgt0QpBwiqfpnhg0rGahRKa0wWqyV1YzfPA 7wVEeozliRm1rEdS9u78hqP0BdGfReIk88C7UO4Y1xNvwib5It GkTh1LyLhdhbBzRDZmPuZQc3O4LAgt164IS8tk1qINg5a3/SQD wrTQJjLxCK1VE6blyfRDf/tln+7WVHEO7GV1tDofm4d2lS0Z2h GhZzLnpuZv8y1ODtI5iXCu7YnB3e5N0gtbL1C1Sdt Subject: [Json] Security Considerations X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 06 Jun 2013 19:17:20 -0000 Proposal: With any data format, it is important to encode correctly. Care must be taken when constructing JSON texts by concatenation. For example: account = 4627; comment = "\",\"account\":262"; // provided by attacker json_text = "(\"account\":" + account + ",\"comment\":\"" + comment + "\"}"; The result will be {"account":4627,"comment":"","account":262} which some parsers MAY see as being the same as {"comment":"","account":262} This confusion allows an attacker to modify the account property or any other property. It is much wiser to use JSON generators, which are available in many forms for most programming languages, to do the encoding, avoiding the confusion hazard. JSON is so similar to some programming languages that the native parsing ability of the language processors can be used to parse JSON texts. This should be avoided because the native parser will accept code which is not JSON. For example, JavaScript's eval() function is able parse JSON text, but is can also parse programs. If an attacker can inject code into the JSON text (as we saw above), then it can compromise the system. JSON parsers should always be used instead. From tbray@textuality.com Thu Jun 6 12:23:36 2013 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 2048221F8BF7 for ; Thu, 6 Jun 2013 12:23:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.078 X-Spam-Level: * X-Spam-Status: No, score=1.078 tagged_above=-999 required=5 tests=[AWL=-1.040, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_SORBS_DUL=0.877, RDNS_NONE=0.1, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UK3TUYu3ogPE for ; Thu, 6 Jun 2013 12:23:32 -0700 (PDT) Received: from mail-ve0-x233.google.com (mail-ve0-x233.google.com [IPv6:2607:f8b0:400c:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id DFB2521F9349 for ; Thu, 6 Jun 2013 12:23:31 -0700 (PDT) Received: by mail-ve0-f179.google.com with SMTP id d10so2541019vea.10 for ; Thu, 06 Jun 2013 12:23:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=Y0uKJJu2kVU5EE9aQTs1TA0/W66klcS3omWBJsRxO7Y=; b=Fq2x2Bv0v9Pag54YAvTbjMQ/VMUv1nd1+OB1SflhgFSfF7V9po6H8rrgT2kaYmPZsG IUGwOhQr0JJICtzyqOf4Hypg4z3IQ29UJd85HHNgTZWsw3GXnVSu5FYl2PXzSU0Cvjyg 6MAkIg/MRrRhLYyRuhu3k+BQo0UNJxUmZRgmYecXc1SNhdFGxgJEAuX1v/QvHZyHaqRE OrdRxCoM0mFHSWxY40G7kCXf0rMN2pmavamPzQcpTOCuufXDrjDqgPIkiDf1QN+THidt WtErWuWu+sk8yPjWUbL+Wv8ueeZiayw8QCqbGLzHmY2o5gt4vILutc3aN+UJI5m45jMJ n4Nw== MIME-Version: 1.0 X-Received: by 10.220.45.9 with SMTP id c9mr17750785vcf.65.1370546610986; Thu, 06 Jun 2013 12:23:30 -0700 (PDT) Received: by 10.220.48.14 with HTTP; Thu, 6 Jun 2013 12:23:30 -0700 (PDT) X-Originating-IP: [96.49.81.176] In-Reply-To: <51B0DFB6.10803@crockford.com> References: <51B0DFB6.10803@crockford.com> Date: Thu, 6 Jun 2013 12:23:30 -0700 Message-ID: From: Tim Bray To: Douglas Crockford Content-Type: multipart/alternative; boundary=001a11c2013ee57ed304de813f5d X-Gm-Message-State: ALoCoQlKERHoC2LHRqXTk6/x5dxjM1BXcjfHYMdJNOOUmudih8V7V+kRTBT+YBOmkNbadQIk16DR Cc: "json@ietf.org" Subject: Re: [Json] Introduction X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 06 Jun 2013 19:23:36 -0000 --001a11c2013ee57ed304de813f5d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable +1, except for: we need some more arguing on what goes after =E2=80=9Ca str= ing is...=E2=80=9D -T On Thu, Jun 6, 2013 at 12:15 PM, Douglas Crockford w= rote: > I propose changing the introduction to de-emphasize JavaScript and > emphasize Data Format, conforming to the new title. > > JSON is a text format for the serialization of structured data. It > was inspired by the object literals of JavaScript, as defined in the > ECMAScript Programming Language Standard, Fifth Edition[ECMA]. > > JSON can represent four primitive types (strings, numbers, booleans, > and null) and two structured types (objects and arrays). > > A string is a sequence of zero or more characters. > > An object is an unordered collection of zero or more name/value > pairs, where a name is a string and a value is a string, number, > boolean, null, object, or array. > > An array is an ordered sequence of zero or more values. > > The terms "object" and "array" come from the conventions of > JavaScript. > > JSON's design goals were for it to be minimal, portable, textual, and > a subset of JavaScript. JSON stands for JavaScript Object Notation. > > ______________________________**_________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/**listinfo/json > --001a11c2013ee57ed304de813f5d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
+1, except for: we need some more arguing on what goe= s after =E2=80=9Ca string is...=E2=80=9D

-T


On Thu, Jun 6, 2013 at= 12:15 PM, Douglas Crockford <douglas@crockford.com> wro= te:
I propose changing the introduction to de-em= phasize JavaScript and emphasize Data Format, conforming to the new title.<= br>
=C2=A0 =C2=A0JSON is a text format for the serialization of structured data= . It
=C2=A0 =C2=A0was inspired by the object literals of JavaScript, as defined = in the
=C2=A0 =C2=A0ECMAScript Programming Language Standard, Fifth Edition[ECMA].=

=C2=A0 =C2=A0JSON can represent four primitive types (strings, numbers, boo= leans,
=C2=A0 =C2=A0and null) and two structured types (objects and arrays).

=C2=A0 =C2=A0A string is a sequence of zero or more characters.

=C2=A0 =C2=A0An object is an unordered collection of zero or more name/valu= e
=C2=A0 =C2=A0pairs, where a name is a string and a value is a string, numbe= r,
=C2=A0 =C2=A0boolean, null, object, or array.

=C2=A0 =C2=A0An array is an ordered sequence of zero or more values.

=C2=A0 =C2=A0The terms "object" and "array" come from t= he conventions of
=C2=A0 =C2=A0JavaScript.

=C2=A0 =C2=A0JSON's design goals were for it to be minimal, portable, t= extual, and
=C2=A0 =C2=A0a subset of JavaScript. =C2=A0JSON stands for JavaScript Objec= t Notation.

_______________________________________________
json mailing list
json@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/json

--001a11c2013ee57ed304de813f5d-- From douglas@crockford.com Thu Jun 6 12:25:57 2013 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 3617E21F9952 for ; Thu, 6 Jun 2013 12:25:57 -0700 (PDT) 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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RzqH2txVEpvr for ; Thu, 6 Jun 2013 12:25:51 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id 45C5921F8BF7 for ; Thu, 6 Jun 2013 12:25:51 -0700 (PDT) Received: from [192.168.114.223] ([216.113.168.135]) by mrelay.perfora.net (node=mrus3) with ESMTP (Nemesis) id 0McDxn-1V48F90F8R-00ImZj; Thu, 06 Jun 2013 15:25:50 -0400 Message-ID: <51B0E231.3030703@crockford.com> Date: Thu, 06 Jun 2013 12:25:37 -0700 From: Douglas Crockford User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Tim Bray References: <51B0DFB6.10803@crockford.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Provags-ID: V02:K0:2/hN6BL/tEiprpmp4sJdXZmXKiWZBbz52hK8kLEjjs4 Fuz+AhgwSQa9QpwDCkJPKlfvt/eRO4jxBqixcJlQiBrcYX+20I ouvgCdaHlyTAQqllQlhLHhfPKhEMp7DAM+W0Ne22J6wgGPeiHQ EIIokdyJuKFft32dvAaauMIgkUl1M+Yc2Lbv/6xkMWpkO66XQr GkV8IZTH5en+lex/SUzaeDpjtOhCEy6pM3PsWd9g4UNFPflIRo BJHxC4mJYPIJKdXuwTbcjdxMYfBxDgee4WjUf/ete3kWjV1LTa WC9sl7Btd/zRKWihI/nfzvnlPreQssTjVpg8K1wvn5azymBtkz Y3BjcE7Q1+R0NUsH2U7koUWd+dBJDVuorkaJixVUo Cc: "json@ietf.org" Subject: Re: [Json] Introduction X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 06 Jun 2013 19:25:57 -0000 On 6/6/2013 12:23 PM, Tim Bray wrote: > +1, except for: we need some more arguing on what goes after “a string > is...†> > -T In the introduction? Can't wait until the String section? From paul.hoffman@vpnc.org Thu Jun 6 12:33:27 2013 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 4333E21E805E for ; Thu, 6 Jun 2013 12:33:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j3BQcOqr1SMM for ; Thu, 6 Jun 2013 12:33:26 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 7BFBF21E8054 for ; Thu, 6 Jun 2013 12:33:26 -0700 (PDT) Received: from [165.227.249.247] (sn80.proper.com [75.101.18.80]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r56JXM6f038551 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 6 Jun 2013 12:33:23 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Paul Hoffman In-Reply-To: <51B0E231.3030703@crockford.com> Date: Thu, 6 Jun 2013 12:33:21 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <51B0DFB6.10803@crockford.com> <51B0E231.3030703@crockford.com> To: Douglas Crockford X-Mailer: Apple Mail (2.1508) Cc: Tim Bray , "json@ietf.org" Subject: Re: [Json] Introduction X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 06 Jun 2013 19:33:27 -0000 On Jun 6, 2013, at 12:25 PM, Douglas Crockford = wrote: > On 6/6/2013 12:23 PM, Tim Bray wrote: >> +1, except for: we need some more arguing on what goes after =93a = string is...=94 +1=20 > In the introduction? Can't wait until the String section? Nope. Preconceived notions start in the Introduction. :-) --Paul Hoffman= From tsaloranta@gmail.com Thu Jun 6 12:37:55 2013 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 8D2CF11E80F9 for ; Thu, 6 Jun 2013 12:37:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.065 X-Spam-Level: X-Spam-Status: No, score=-2.065 tagged_above=-999 required=5 tests=[AWL=0.534, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e+gB5vfENWPk for ; Thu, 6 Jun 2013 12:37:54 -0700 (PDT) Received: from mail-we0-x22c.google.com (mail-we0-x22c.google.com [IPv6:2a00:1450:400c:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 4A0F311E80E4 for ; Thu, 6 Jun 2013 12:37:54 -0700 (PDT) Received: by mail-we0-f172.google.com with SMTP id q56so2443576wes.31 for ; Thu, 06 Jun 2013 12:37:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=H+grleXX9WqzIAERlwWZzp9cpijF92k7mU9bHur0vfE=; b=O9aUG5ML4KzrockiLpYN6xdKOz1FDF6O4mJp/Scn7b9vYXhg3M2oYaHlgLNt0FozHQ nVwadSqk184l0iyxp7UIX2nMYeVBd7ZwxALQfhL7VIsP85DYNlb4xfcq1pztPYMv4jC9 sgV48oWTT3JHPPZ33nx2PMHK2mrIzB0q/yXIMH3e8/UaA+jpBb8JxzJ/W5w7ra7aC77y 8E8J9DKTTE5QILFT1UXfEYw6WA75Ui1Q3fwZkS5JRkKGRBLx8m7Jlqu+K5HHv7ZaT+fE q2/8z0szg8MMx+/rQI2L1YK7RtHEEUsVvQw1XM22JdFavj3OVodLj3wyY/D8p6+au75L UlVw== MIME-Version: 1.0 X-Received: by 10.180.21.242 with SMTP id y18mr10898471wie.7.1370547473443; Thu, 06 Jun 2013 12:37:53 -0700 (PDT) Received: by 10.227.97.6 with HTTP; Thu, 6 Jun 2013 12:37:53 -0700 (PDT) In-Reply-To: References: Date: Thu, 6 Jun 2013 12:37:53 -0700 Message-ID: From: Tatu Saloranta To: Paul Hoffman Content-Type: multipart/alternative; boundary=047d7bb70b2c4d784404de81730e Cc: "json@ietf.org" Subject: Re: [Json] Call for real-world examples of how parsers deal with duplicate keys X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 06 Jun 2013 19:37:55 -0000 --047d7bb70b2c4d784404de81730e Content-Type: text/plain; charset=ISO-8859-1 On Thu, Jun 6, 2013 at 10:41 AM, Paul Hoffman wrote: > Greetings again. Knowing what current parsers do with duplicate keys might > be useful to this discussion. Of course, some people will exclaim "but > that's wrong!" to some of what we see, but seeing it may be useful > nonetheless. > > I propose the following JSON text for the tests: > > {"a":1,"a":2} > > --Paul Hoffman > > ============================== > > And I'll start with Python. > > from __future__ import print_function > import json > a = '{"a":1,"a":2}' > print(json.loads(a)) > > # python2.6 keytest.py > {u'a': 2} > # python2.7 keytest.py > {u'a': 2} > # python3.2 keytest.py > {'a': 2} > > > On Java, Jackson library: - Exposes both entries (key/value pairs) at streaming parsing level - Exposes last value via tree model and data-binding (which use streaming parser for tokenization) -- may optionally report errors during building of tree model, if error reporting not disabled. other Java libraries I am familiar with will also do one of three possibilities, I think GSON for example behaves same as Jackson as it also uses streaming/builder layering. -+ Tatu +- --047d7bb70b2c4d784404de81730e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Jun 6, 2013 at 10:41 AM, Paul Hoffman <paul.h= offman@vpnc.org> wrote:
Greetings again. Knowing what current parsers do with dupl= icate keys might be useful to this discussion. Of course, some people will = exclaim "but that's wrong!" to some of what we see, but seein= g it may be useful nonetheless.

I propose the following JSON text for the tests:

{"a":1,"a":2}

--Paul Hoffman

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D

And I'll start with Python.

from __future__ import print_function
import json
a =3D '{"a":1,"a":2}'
print(json.loads(a))

# python2.6 keytest.py
{u'a': 2}
# python2.7 keytest.py
{u'a': 2}
# python3.2 keytest.py
{'a': 2}





On Java, Jackson library:
<= div style=3D"font-family:arial,sans-serif;font-size:13px">
- Expo= ses both entries (key/value pairs) at streaming parsing level
- Exposes last value via= tree model and data-binding (which use streaming parser for tokenization) = -- may optionally report errors during building of tree model, if error rep= orting not disabled.

other Java libraries I= am familiar with will also do one of three possibilities, I think GSON for= example behaves same as Jackson as it also uses streaming/builder layering= .
=A0
-+ Tatu +-

<= /div>
--047d7bb70b2c4d784404de81730e-- From jsontest@yahoo.com Thu Jun 6 12:39:39 2013 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 3414011E80FD for ; Thu, 6 Jun 2013 12:39:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.282 X-Spam-Level: X-Spam-Status: No, score=0.282 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FijnLblKHwfT for ; Thu, 6 Jun 2013 12:39:34 -0700 (PDT) Received: from nm6-vm5.bullet.mail.gq1.yahoo.com (nm6-vm5.bullet.mail.gq1.yahoo.com [98.136.218.196]) by ietfa.amsl.com (Postfix) with ESMTP id ADE5011E80FA for ; Thu, 6 Jun 2013 12:39:34 -0700 (PDT) Received: from [98.137.12.174] by nm6.bullet.mail.gq1.yahoo.com with NNFMP; 06 Jun 2013 19:39:34 -0000 Received: from [98.136.185.28] by tm13.bullet.mail.gq1.yahoo.com with NNFMP; 06 Jun 2013 19:39:34 -0000 Received: from [127.0.0.1] by smtp109.mail.gq1.yahoo.com with NNFMP; 06 Jun 2013 19:39:34 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1370547574; bh=b4qJxeYYyXJWnDIEM9WbU4FN2tm8Ce50dznlFJnrFZc=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:References:In-Reply-To:Mime-Version:Content-Type:Content-Transfer-Encoding:Message-Id:Cc:X-Mailer:From:Subject:Date:To; b=CG7Rld48murcmfnxjTThLwb4PfnV1rA1Hly+Cr8lrsaw+SKtLbCnqUdzFUuClaScAYH8rsTT0Dokbk66K0viF9PlNpGuHTKbMStxfWZv9I1t9fMp0DW5dI+4tAvVjyqodmCOjRayFMiPU1NIjFgqpL7fuxnI5BQUUF3LuPUznSc= X-Yahoo-Newman-Id: 240062.78233.bm@smtp109.mail.gq1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: DPhL9.kVM1kZxU9UGFrnsSn5MumDkuU6.qS_aQW.GBD1hQj Ls4gMZfMngwMO7sf3wxACUg5_PkRY6Aug9SH9Yh4nbOZIPJfSPqt7mq0weP_ YEw7r1T5HKycGIbD3yj0wJNac7aCEUvmRHeFm3YVq4HeuBmpjganCY1ifCNF j.e4YZoJb94jCo0ETW_AqMItQhXOy2KUZuh_NuTo4wvJLcMFeWarvS9Q36Li S5tJAIa8a75bOckmuFqLRMHwmaXOPHi65EUo_jJ7J9ZTwNHPbBSH9KMN9UhI dxRYHrrbkv5mRJDm6J0F2R8yAFidLXcLfCFDqB6Tsw3v4LrOI2rFndzpzHbD 7ubh7rNyqSJcZwU4_JR1lkAeZLLkgwrGtuUMhd6cLjNeO.lw70R2WTQr3DVT 1SZ5wNKDjiytSS6CuM7lxfK6eJwJOWwK.w4lxqdBV6JOs8le0GRuJHIox12Q eSY8OgDTQTqjPhHczemD7NYtdm5t58SAhbqAX__g1JJUDrTjAO98V1v2L_9i AIWmhmwowch7tZSc2dKEuqU0FvgiJ90ppb8xOPtAWObDMQ6BbkI322AeoXk7 S76YzInDpClWv93xvhqt5nsWMdMvCLj62R2F5jed8T0PlK7gzekrreBH5PWB HFBBproDdHifbGOYm4wd11qo2mc66D3ikGgqNH9HUZAvKFt9XXsPxdRiGNSW 0E6o- X-Yahoo-SMTP: indQcmSswBC8IKsm6t4aCAPskK3T X-Rocket-Received: from [192.168.0.102] (jsontest@76.29.100.42 with ) by smtp109.mail.gq1.yahoo.com with SMTP; 06 Jun 2013 12:39:34 -0700 PDT References: In-Reply-To: Mime-Version: 1.0 (1.0) Content-Type: multipart/alternative; boundary=Apple-Mail-36B71595-1036-47EB-B83E-CB1640DF82D1 Content-Transfer-Encoding: 7bit Message-Id: <68781957-C96E-4D30-96F3-6C50B59B7DAE@yahoo.com> X-Mailer: iPod Mail (9B206) From: Vinny A Date: Thu, 6 Jun 2013 14:39:33 -0500 To: Paul Hoffman Cc: "json@ietf.org" Subject: Re: [Json] Call for real-world examples of how parsers deal with duplicate keys X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 06 Jun 2013 19:39:39 -0000 --Apple-Mail-36B71595-1036-47EB-B83E-CB1640DF82D1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii The org.json reference parser causes an exception when it hits a duplicated k= ey. See https://github.com/douglascrockford/JSON-java/blob/master/JSONObject= .java , line 1186, in putOnce. ----------------- Vinny www.jsontest.com On Jun 6, 2013, at 12:41 PM, Paul Hoffman wrote: > Greetings again. Knowing what current parsers do with duplicate keys might= be useful to this discussion. Of course, some people will exclaim "but that= 's wrong!" to some of what we see, but seeing it may be useful nonetheless. >=20 > I propose the following JSON text for the tests: >=20 > {"a":1,"a":2} >=20 > --Paul Hoffman >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D >=20 > And I'll start with Python. >=20 > from __future__ import print_function > import json > a =3D '{"a":1,"a":2}' > print(json.loads(a)) >=20 > # python2.6 keytest.py > {u'a': 2} > # python2.7 keytest.py > {u'a': 2} > # python3.2 keytest.py > {'a': 2} >=20 >=20 > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json --Apple-Mail-36B71595-1036-47EB-B83E-CB1640DF82D1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
The org.json reference= parser causes an exception when it hits a duplicated key. See https://github.com/douglascr= ockford/JSON-java/blob/master/JSONObject.java , line 1186, in putOnce.


-----------------
Vinn= y

On Jun 6, 2013, at 12:41 PM, Paul Hoffman <paul.hoffman@vpnc.org> wrote:

Greetings again. Knowing what c= urrent parsers do with duplicate keys might be useful to this discussion. Of= course, some people will exclaim "but that's wrong!" to some of what we see= , but seeing it may be useful nonetheless.

= I propose the following JSON text for the tests:

= {"a":1,"a":2}

--Paul Hoffman
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

And= I'll start with Python.

from __future__ im= port print_function
import json
a =3D '{"a":= 1,"a":2}'
print(json.loads(a))

# python2.6 keytest.py
{u'a': 2}
# pytho= n2.7 keytest.py
{u'a': 2}
# python3.2 keytes= t.py
{'a': 2}


_______________________________________________
json mai= ling list
json@ietf.org=
http= s://www.ietf.org/mailman/listinfo/json
= --Apple-Mail-36B71595-1036-47EB-B83E-CB1640DF82D1-- From sgbeal@googlemail.com Thu Jun 6 12:50:11 2013 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 C2D0A21E80B0 for ; Thu, 6 Jun 2013 12:50:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.008 X-Spam-Level: X-Spam-Status: No, score=-1.008 tagged_above=-999 required=5 tests=[AWL=-0.323, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MISSING_HEADERS=1.292, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CGOj60CzztiI for ; Thu, 6 Jun 2013 12:50:07 -0700 (PDT) Received: from mail-wg0-x22f.google.com (mail-wg0-x22f.google.com [IPv6:2a00:1450:400c:c00::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 69CEC21E80A7 for ; Thu, 6 Jun 2013 12:50:07 -0700 (PDT) Received: by mail-wg0-f47.google.com with SMTP id e11so2415101wgh.2 for ; Thu, 06 Jun 2013 12:50:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:cc :content-type; bh=1jArutRvBBDFIT98Zk6c2nyltJr2LE068BJr496vHC8=; b=f8zKOjm+5QWl7xtTsdgnVKQ9bfEVRU0cNksxKW7XuqcGnLwJJ/hFgq4yoRV5tDB2XR FdgD9TtCTgTvVXKkF27NpdeZcGn/6/DrPiipbPjlr7O2BaT0T6Yr1pXN8nPJ0ySfu7MB wlR6j3tqpCtdRTt3LrIF1qb6DwFamZMozNTWxmITgwtTwFDOZyu0V9c9GkfKsOX//hrA Wd4cnfw8K/ag8JZqNtOAafT802Qk1dotydAhiKn+Ad3HRjxE28sSH4YuqWmtGWZyXtXy oMQrcMxVa/vA4WK6Boq7Zu/cZPeZXJmBPqWyY2vvk4QPgm7J4Ggz8D68C7lpM3nPxU3x fj0g== MIME-Version: 1.0 X-Received: by 10.194.179.102 with SMTP id df6mr33445873wjc.42.1370548206520; Thu, 06 Jun 2013 12:50:06 -0700 (PDT) Received: by 10.194.42.230 with HTTP; Thu, 6 Jun 2013 12:50:06 -0700 (PDT) In-Reply-To: References: Date: Thu, 6 Jun 2013 21:50:06 +0200 Message-ID: From: Stephan Beal Cc: "json@ietf.org" Content-Type: multipart/alternative; boundary=089e01493c34ff4f0a04de819ef3 Subject: Re: [Json] Call for real-world examples of how parsers deal with duplicate keys X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 06 Jun 2013 19:50:12 -0000 --089e01493c34ff4f0a04de819ef3 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Jun 6, 2013 at 7:41 PM, Paul Hoffman wrote: > Greetings again. Knowing what current parsers do with duplicate keys might > be useful to this discussion. Of course, some people will exclaim "but > that's wrong!" to some of what we see, but seeing it may be useful > nonetheless. > > I propose the following JSON text for the tests: > > {"a":1,"a":2} > My C and C++ implementations would result in {"a":2}. That was the only implementation which made intuitive sense to me (and is faster than erroring on dupes in the C++ code, which of course uses std::map as the basis, and avoids me having to search that map to check for a dupe). While library-level coding effort would not be notably more to error on dupes, it does add another error case/code for clients to check for, and it just didn't make sense to me to deal with this (what i consider to be a) corner case. This approach also, IMO, conforms to the "principal of least surprise," which for me means "last one wins.' -- ----- stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal --089e01493c34ff4f0a04de819ef3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Thu, Jun 6, 2013 at 7:41= PM, Paul Hoffman <paul.hoffman@vpnc.org> wrote:
Greetings again. Knowing what current parser= s do with duplicate keys might be useful to this discussion. Of course, som= e people will exclaim "but that's wrong!" to some of what we = see, but seeing it may be useful nonetheless.

I propose the following JSON text for the tests:

{"a":1,"a":2}

My C and C++ implementations would result in {"a":2}. That was t= he only implementation which made intuitive sense to me (and is faster than= erroring on dupes in the C++ code, which of course uses std::map as the ba= sis, and avoids me having to search that map to check for a dupe). While li= brary-level coding effort would not be notably more to error on dupes, it d= oes add another error case/code for clients to check for, and it just didn&= #39;t make sense to me to deal with this (what i consider to be a) corner c= ase. This approach also, IMO, conforms to the "principal of least surp= rise," which for me means "last one wins.'

--
----- stephan beal
http://wanderinghorse.net/home= /stephan/
--089e01493c34ff4f0a04de819ef3-- From jhildebr@cisco.com Thu Jun 6 12:57:23 2013 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 317F121E80A7 for ; Thu, 6 Jun 2013 12:57:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SdZBktgh4Nio for ; Thu, 6 Jun 2013 12:57:17 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id A1B2D21F8F7A for ; Thu, 6 Jun 2013 12:57:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=992; q=dns/txt; s=iport; t=1370548637; x=1371758237; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=xcS6fiLruDMB+E+5DCP+7FhUaBVkNjcLJYyvT/nbiD0=; b=Du08Xg7HxWxB/xsb5mtja60EoGtTS3RvCSaIWV/LgePPGEE4i3KPGhF9 o9iU/oLHT19HKT7n24ksNigJD7bwNpbcJyg71L9azuNG85mJjYIyP/Agr DYSRMW6pni6jXzvr3AJg06J5ir5+X5NbNNGJf24EOhcrKNZFxTRiPDRhO I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AggFAG7osFGtJXG//2dsb2JhbABZgwm/enoWdIIjAQEBAwE6RA0BCCIUQiUCBAESCId/BrtcjwE4gnphA6h/gw+CJw X-IronPort-AV: E=Sophos;i="4.87,817,1363132800"; d="scan'208";a="219741837" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-7.cisco.com with ESMTP; 06 Jun 2013 19:57:17 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r56JvGHg011665 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 6 Jun 2013 19:57:16 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.56]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.02.0318.004; Thu, 6 Jun 2013 14:57:16 -0500 From: "Joe Hildebrand (jhildebr)" To: Douglas Crockford , "json@ietf.org" Thread-Topic: [Json] Introduction Thread-Index: AQHOYuozVesgCtU8h0urTtW8JO4SV5kpCXqA Date: Thu, 6 Jun 2013 19:57:16 +0000 Message-ID: In-Reply-To: <51B0DFB6.10803@crockford.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [10.21.88.234] Content-Type: text/plain; charset="us-ascii" Content-ID: <1DF6E3C6958E7E4D944CC7D1079D3EE6@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Json] Introduction X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 06 Jun 2013 19:57:23 -0000 On 6/6/13 1:15 PM, "Douglas Crockford" wrote: > A string is a sequence of zero or more characters. How about: "A string is a sequence of code points for almost any Unicode character." ("almost" here refers to the ones that need to be escaped) > An object is an unordered collection of zero or more name/value > pairs, where a name is a string and a value is a string, number, > boolean, null, object, or array. > > An array is an ordered sequence of zero or more values. > > The terms "object" and "array" come from the conventions of > JavaScript. I think this graf can be deleted. > JSON's design goals were for it to be minimal, portable, textual, and > a subset of JavaScript. JSON stands for JavaScript Object Notation. Should we add something like: "However, JSON is now used in many different programming languages. This document describes a language-neutral approach." --=20 Joe Hildebrand From sgbeal@googlemail.com Thu Jun 6 13:00:58 2013 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 6430F11E80F2 for ; Thu, 6 Jun 2013 13:00:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.9 X-Spam-Level: X-Spam-Status: No, score=-0.9 tagged_above=-999 required=5 tests=[AWL=-0.215, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MISSING_HEADERS=1.292, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bcX3tzrQ6POh for ; Thu, 6 Jun 2013 13:00:57 -0700 (PDT) Received: from mail-wg0-x22e.google.com (mail-wg0-x22e.google.com [IPv6:2a00:1450:400c:c00::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 7791821F93B9 for ; Thu, 6 Jun 2013 13:00:57 -0700 (PDT) Received: by mail-wg0-f46.google.com with SMTP id l18so2416893wgh.1 for ; Thu, 06 Jun 2013 13:00:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:cc :content-type; bh=w8qlEC3OYjMy/t4qjWm1fOBHfJk3J+GBvtOAsF46+/8=; b=T4rGvtgqehlSSs2KbBs7TqVfmlZ0b5x0ELlW+53qcYxk3Vx1x0wd0Qy/JdsNcnkSSU 41mt88ypFMtwdKNSw+2AtHj3zmB2Wtb29zvLekF1DDKq2Mli9/U8J3k97aihhgIEsNDZ qTyOmxkmLedVwgWv7KZRxRIaV85exc/nlQU7vaGvZh1AQqiGayRAGVFZGhbfusGsVUcx yO6GlRAeZO8ZCV+znxKqyWbgCeMA65WYg95xm15eLXtYUEkrZtV4F39TtSdTd/8CK0bF AEWKJ8HOv1+KQSKG48cRBW5u2DiYqJNqzM71z1NrNCtcvotD+rxpH4R74jGVaRgpxLLT Dvlg== MIME-Version: 1.0 X-Received: by 10.180.198.110 with SMTP id jb14mr11072684wic.37.1370548856623; Thu, 06 Jun 2013 13:00:56 -0700 (PDT) Received: by 10.194.42.230 with HTTP; Thu, 6 Jun 2013 13:00:56 -0700 (PDT) In-Reply-To: <51B0E02E.4070209@crockford.com> References: <51B0E02E.4070209@crockford.com> Date: Thu, 6 Jun 2013 22:00:56 +0200 Message-ID: From: Stephan Beal Cc: "json@ietf.org" Content-Type: multipart/alternative; boundary=047d7b6227cebf178904de81c517 Subject: Re: [Json] Security Considerations X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 06 Jun 2013 20:00:58 -0000 --047d7b6227cebf178904de81c517 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Jun 6, 2013 at 9:17 PM, Douglas Crockford wrote: > which some parsers MAY see as being the same as > > {"comment":"","account":262} That wording "may" not be valid/necessary, depending on how the debate on the handling of multiple keys goes ;). If, for example, implementations are required to fail on multiple keys then any other behaviour is non-compliant and need not (necessarily) be specified by the spec, except perhaps as "non-normative" info. > It is much wiser to use JSON generators, which are available in many > forms for most programming languages, to do the encoding, avoiding > the confusion hazard. > Some generators (streaming ones) can still create dupes. For example, JavaScript's eval() function is able parse JSON text, > but is can also parse programs. If an attacker can inject code into > the JSON text (as we saw above), then it can compromise the system. > JSON parsers should always be used instead. > IMHO that all belongs well within the realm of Best Practice (perhaps a Security Concerns sub-section). -- ----- stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal --047d7b6227cebf178904de81c517 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Jun 6, 2013 at 9:17 PM, Douglas Crockford <do= uglas@crockford.com> wrote:
=A0 =A0which some parsers MAY see as being the same as
=
> =A0 {"comment":"","account":262}

=
=A0

That wording "may" not be= valid/necessary, depending on how the debate on the handling of multiple k= eys goes ;). If, for example, implementations are required to fail on multi= ple keys then any other behaviour is non-compliant and need not (necessaril= y) be specified by the spec, except perhaps as "non-normative" in= fo.
=A0
=A0 =A0It is much wiser to use JSON generato= rs, which are available in many
=A0 =A0forms for most programming languages, to do the encoding, avoiding =A0 =A0the confusion hazard.

Some= generators (streaming ones) can still create dupes.

=A0 =A0For example, JavaScript's eval() function is able parse JSON tex= t,
=A0 =A0but is can also parse programs. =A0If an attacker can inject code in= to
=A0 =A0the JSON text (as we saw above), then it can compromise the system.<= br> =A0 =A0JSON parsers should always be used instead.
IMHO that all belongs well within the realm of Best Pract= ice (perhaps a Security Concerns sub-section).

--=
----- stephan beal
http://wanderinghorse.net/home/stephan/
--047d7b6227cebf178904de81c517-- From sgbeal@googlemail.com Thu Jun 6 13:03:20 2013 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 AD58221E8085 for ; Thu, 6 Jun 2013 13:03:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.847 X-Spam-Level: X-Spam-Status: No, score=-0.847 tagged_above=-999 required=5 tests=[AWL=-0.161, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MISSING_HEADERS=1.292, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tuPUhFoj1drR for ; Thu, 6 Jun 2013 13:03:20 -0700 (PDT) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 651A911E80E3 for ; Thu, 6 Jun 2013 13:03:16 -0700 (PDT) Received: by mail-wi0-f170.google.com with SMTP id ey16so730036wid.5 for ; Thu, 06 Jun 2013 13:03:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:cc :content-type; bh=kHwDimON+2Lpi2DsHH7QFVvxd2JLC6E8ng/LzojwGMs=; b=hxDohzCBqEv8RmKEXKslIeNFSIfhEO5ff6Equfu9FmWAqJi23mLyp6Hc+TSmdTgz/3 1KrU0Z78wRxCnMB2mYYmBGtCiZw8y2fRWadC71aRq64Z//Tj/wPGAhZrAp8giiUBh00J OJwHx4FKpz/8Gs44hgZ5Z6Bj1XZuVhCgBOTlz6V5BdxfEDwb/AOdCyIL7wWmtaV/tvhx t3xU2DFoPKDIFXxJq/EthC9dUrbH73NjS4N3PsJb3bKfiLPvRWXriciwSJWH1GS9j4gt uwm98exLJQNqjwJ3unelCs0zQe+r6vbRRHYnV32Tb5JwR+w8wfAadyk9xsY288xODxAH i4wA== MIME-Version: 1.0 X-Received: by 10.180.14.130 with SMTP id p2mr11152103wic.32.1370548995342; Thu, 06 Jun 2013 13:03:15 -0700 (PDT) Received: by 10.194.42.230 with HTTP; Thu, 6 Jun 2013 13:03:15 -0700 (PDT) In-Reply-To: References: <51B0DFB6.10803@crockford.com> Date: Thu, 6 Jun 2013 22:03:15 +0200 Message-ID: From: Stephan Beal Cc: "json@ietf.org" Content-Type: multipart/alternative; boundary=f46d040f9f4403c8b804de81ce79 Subject: Re: [Json] Introduction X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 06 Jun 2013 20:03:20 -0000 --f46d040f9f4403c8b804de81ce79 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Jun 6, 2013 at 9:57 PM, Joe Hildebrand (jhildebr) < jhildebr@cisco.com> wrote: > On 6/6/13 1:15 PM, "Douglas Crockford" wrote: > > A string is a sequence of zero or more characters. > > How about: > > "A string is a sequence of code points for almost any Unicode character." > ... enclosed by double-quotes (ASCII 34 decimal, 0x22 hex). (or whatever the convention is for being explicit about which exact characters are being used.) -- ----- stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal --f46d040f9f4403c8b804de81ce79 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

= On Thu, Jun 6, 2013 at 9:57 PM, Joe Hildebrand (jhildebr) <jhildebr@cisco= .com> wrote:
On 6/6/13 1:15 PM, "D= ouglas Crockford" <douglas= @crockford.com> wrote:
> =A0 =A0A string is a sequence of zero or more characters.

How about:

"A string is a sequence of code points for almost any Unicode characte= r."

... enclosed by double-q= uotes (ASCII 34 decimal, 0x22 hex).

(or what= ever the convention is for being explicit about which exact characters are = being used.)

--
----- stephan beal
http://wanderinghorse.net/home= /stephan/
--f46d040f9f4403c8b804de81ce79-- From sgbeal@googlemail.com Thu Jun 6 13:05:30 2013 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 035EF11E80FE for ; Thu, 6 Jun 2013 13:05:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.46 X-Spam-Level: X-Spam-Status: No, score=-1.46 tagged_above=-999 required=5 tests=[AWL=0.517, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9HSkfRakzkZz for ; Thu, 6 Jun 2013 13:05:29 -0700 (PDT) Received: from mail-wg0-x231.google.com (mail-wg0-x231.google.com [IPv6:2a00:1450:400c:c00::231]) by ietfa.amsl.com (Postfix) with ESMTP id E261711E80E3 for ; Thu, 6 Jun 2013 13:05:28 -0700 (PDT) Received: by mail-wg0-f49.google.com with SMTP id a12so639736wgh.4 for ; Thu, 06 Jun 2013 13:05:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=+XVfShyAGopgqlm5KkfnxI0fhP28psIFe5ljIEcOG1o=; b=t55mTHL1sRWwEl9vHm+yzi4emYeBi2gHdQhdNxfTRo2Qm7pC8pJ5eZE/AwnA8EpHJN XsWDkvjXBNZ/1P+DE1r+Rota2khoqMAQWZI4VlAGnwudMKF/0Dq5pRXjNkhlh7ENPTyE vcvs4Yx1nkVenHuWZ5GGLVywMhmA/NXSI+wO71ip/6XcS8gqFe77I0DpECsueJyG36j0 0pewFoqMJyDI9vYuJaVzWZc7zvv2C1fcGvJRUTusyL1MoBpNE8a492/nZGW/nea5l+ON AA7h/Wr1j8Sfcxr8BHMertKO7CFeJFLqMV864OjX1Whcc4E6puYY5FYhqWity3cqi0E7 4wtw== MIME-Version: 1.0 X-Received: by 10.194.95.167 with SMTP id dl7mr33395218wjb.46.1370549128062; Thu, 06 Jun 2013 13:05:28 -0700 (PDT) Received: by 10.194.42.230 with HTTP; Thu, 6 Jun 2013 13:05:28 -0700 (PDT) In-Reply-To: <51B0DFB6.10803@crockford.com> References: <51B0DFB6.10803@crockford.com> Date: Thu, 6 Jun 2013 22:05:28 +0200 Message-ID: From: Stephan Beal To: "json@ietf.org" Content-Type: multipart/alternative; boundary=047d7bb042f2ecee3d04de81d582 Subject: Re: [Json] Introduction X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 06 Jun 2013 20:05:30 -0000 --047d7bb042f2ecee3d04de81d582 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Jun 6, 2013 at 9:15 PM, Douglas Crockford wrote: > a subset of JavaScript. JSON stands for JavaScript Object Notation. > i thought the expansion of the acronym was still under debate? (i don't have an opinion either way, though.) -- ----- stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal --047d7bb042f2ecee3d04de81d582 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Jun 6, 2013 at 9:15 PM, Douglas Crockford <do= uglas@crockford.com> wrote:
=A0 =A0a subset of JavaScript. =A0JSON stand= s for JavaScript Object Notation.

i thought the expansion of the acronym was still under debate? (i don'= t have an opinion either way, though.)

--
----- stephan beal
http://wanderinghorse.net/home= /stephan/
--047d7bb042f2ecee3d04de81d582-- From jhildebr@cisco.com Thu Jun 6 13:24:54 2013 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 F39AA11E8105 for ; Thu, 6 Jun 2013 13:24:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bK4rNcQFxVBs for ; Thu, 6 Jun 2013 13:24:48 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 6B04821E80BD for ; Thu, 6 Jun 2013 13:24:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=596; q=dns/txt; s=iport; t=1370550288; x=1371759888; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=B7ynRnKzcG5XHzRGLTlFmhBpJsVb4Wn8w9YYHueYgA8=; b=BCUVPlji1UoY33N36undKJ6GvpSxjvst3lyX5DS9+QGMZRKO2nnBz+IO 1S09waGcx8KzvNh70Urcp5HyvDM9dLUpL+8a+3W09aw+B7jqxj5ya4rmS hTT71rRosS31WEKxz5M1QPm5Mm00I4JsWAxDOCkCEWnO/BbG40VMfwBES 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgcFAH3vsFGtJV2a/2dsb2JhbABZgwm/enoWdIIlAQQ6PxIBCA4UFEIlAgQOBQiHcwMPsnQNiFKMVYIsMQeCemEDqH+DD4In X-IronPort-AV: E=Sophos;i="4.87,817,1363132800"; d="scan'208";a="219564497" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-1.cisco.com with ESMTP; 06 Jun 2013 20:24:48 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r56KOlhV010964 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 6 Jun 2013 20:24:47 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.56]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.02.0318.004; Thu, 6 Jun 2013 15:24:47 -0500 From: "Joe Hildebrand (jhildebr)" To: Stephan Beal Thread-Topic: [Json] Introduction Thread-Index: AQHOYuozVesgCtU8h0urTtW8JO4SV5kpCXqAgABmRYD//6FtgA== Date: Thu, 6 Jun 2013 20:24:46 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [10.21.88.234] Content-Type: text/plain; charset="us-ascii" Content-ID: <7008E851F8CA884ABF9EC931134B5ACC@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "json@ietf.org" Subject: Re: [Json] Introduction X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 06 Jun 2013 20:24:54 -0000 On 6/6/13 2:03 PM, "Stephan Beal" wrote: >"A string is a sequence of code points for almost any Unicode character." > >... enclosed by double-quotes (ASCII 34 decimal, 0x22 hex). > >(or whatever the convention is for being explicit about which exact >characters are being used.) I like it. So: A string is a sequence of code points for almost any Unicode character enclosed by double-quotes (QUOTATION MARK, U+0022). Or we can hold off on the U+ bit until the string section, which I think would make the intro read better. --=20 Joe Hildebrand From tbray@textuality.com Thu Jun 6 13:33:31 2013 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 7E57021F9944 for ; Thu, 6 Jun 2013 13:33:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.591 X-Spam-Level: X-Spam-Status: No, score=0.591 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_SORBS_DUL=0.877, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yvuWHYfgQeuo for ; Thu, 6 Jun 2013 13:33:26 -0700 (PDT) Received: from mail-ve0-x22f.google.com (mail-ve0-x22f.google.com [IPv6:2607:f8b0:400c:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 54C1E21F972C for ; Thu, 6 Jun 2013 13:33:26 -0700 (PDT) Received: by mail-ve0-f175.google.com with SMTP id da11so2503562veb.6 for ; Thu, 06 Jun 2013 13:33:25 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=q3wRVCTytUsGCrukMG8fNO/rLSL1d6dRn+R1u828/A4=; b=ZyaAWfyKPrbP3+JyvVJaTiEwfrNJfo02Pi/ICOdrgEz2x2E10XKiib+Sz/SOki3HfA gzXfukPPdWWok0SEiYsBPvCACiDcXS0xfvf+ecY8eIkyuXQRau0MXon6dM2MhHyYD49x sy2BH5NVQgDfLwk/189X76VkfkbE0GzXgs4RAPBjFHoVq41TBfujiync8pwgGSJlTiP5 0ZbeTmF7uDOqHDMPqF7ufHo75qU/Vtv8WuNeGmlYhqTGl6/A8HTKlvSZEarw27+5AVVT uZzMc00n//iZMfmEbT68okWiZRVT9q8ygi0dm+DahyHj0BghZpwof11vVcRzM64sMJo1 WB8A== MIME-Version: 1.0 X-Received: by 10.52.30.14 with SMTP id o14mr18407886vdh.106.1370550805721; Thu, 06 Jun 2013 13:33:25 -0700 (PDT) Received: by 10.220.48.14 with HTTP; Thu, 6 Jun 2013 13:33:25 -0700 (PDT) X-Originating-IP: [96.49.81.176] In-Reply-To: References: Date: Thu, 6 Jun 2013 13:33:25 -0700 Message-ID: From: Tim Bray To: "Joe Hildebrand (jhildebr)" Content-Type: multipart/alternative; boundary=20cf307ca1e6ec0d6504de82397c X-Gm-Message-State: ALoCoQlEVPmOYWpJPJA/6F3O8G+bUPhsH25h16n5lDd94eBwDUqH8EXIlSXeg79NqdwgEicVTQdU Cc: Stephan Beal , "json@ietf.org" Subject: Re: [Json] Introduction X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 06 Jun 2013 20:33:31 -0000 --20cf307ca1e6ec0d6504de82397c Content-Type: text/plain; charset=UTF-8 On Thu, Jun 6, 2013 at 1:24 PM, Joe Hildebrand (jhildebr) < jhildebr@cisco.com> wrote: > > >"A string is a sequence of code points for almost any Unicode character." > Well, surrogates are not code points for any Unicode character. Two surrogates may be combined to produce a code point for a character. So if we are going to treat unpaired surrogates as acceptable, then this is false. If we say that strings MUST NOT contain unpaired surrogates, then this is correct. -T --20cf307ca1e6ec0d6504de82397c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Jun 6, 2013 at 1:24 PM, Joe Hildebrand (jhildebr) <= ;jhildebr@cisco.com= > wrote:

>"A string is a sequence of code points for almost any Unicode char= acter."

Well, surrogates are not c= ode points for any Unicode character.=C2=A0 Two surrogates may be combined = to produce a code point for a character.=C2=A0 So if we are going to treat = unpaired surrogates as acceptable, then this is false.=C2=A0 If we say that= strings MUST NOT contain unpaired surrogates, then this is correct.=C2=A0= =C2=A0 -T


=C2=A0

--20cf307ca1e6ec0d6504de82397c-- From jhildebr@cisco.com Thu Jun 6 13:41:26 2013 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 069F621E8085 for ; Thu, 6 Jun 2013 13:41:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2cJIdxJTQnTh for ; Thu, 6 Jun 2013 13:41:20 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 66CFD11E80E4 for ; Thu, 6 Jun 2013 13:41:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=584; q=dns/txt; s=iport; t=1370551280; x=1371760880; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=/WDM4Gv+Xv0WhtDOwWJi6YSL1kg8Nm2+OLHfLSBVkTY=; b=LohXOvWyXNNzC7j2wC1Nt7xYtGdLqZXXf9Zq239MhCYgn2KZA9HH9LtH OjT3j7lgpk6vYZi0BYZhuiMFS6EBZp65epmMy6ErdtJ/+bDbl1SPazUgg s9PuYDXFvbsvSp7HY4GyHO6I2QcnGSyEJjRGYqC+8pK1K7y1y9JCxDg/Y s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AggFAL3ysFGtJXG+/2dsb2JhbABZgwm/eXoWdIIjAQEBBDo/EgEIDgoKFEIlAgQOBQiIBbtPjwExB4J6YQOof4MPgic X-IronPort-AV: E=Sophos;i="4.87,817,1363132800"; d="scan'208";a="219852323" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-4.cisco.com with ESMTP; 06 Jun 2013 20:41:19 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r56KfJ5R027397 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 6 Jun 2013 20:41:19 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.56]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.02.0318.004; Thu, 6 Jun 2013 15:41:19 -0500 From: "Joe Hildebrand (jhildebr)" To: Tim Bray Thread-Topic: [Json] Introduction Thread-Index: AQHOYuozVesgCtU8h0urTtW8JO4SV5kpCXqAgABmRYD//6FtgIAAZwGA//+dm4A= Date: Thu, 6 Jun 2013 20:41:18 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [10.21.88.234] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Stephan Beal , "json@ietf.org" Subject: Re: [Json] Introduction X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 06 Jun 2013 20:41:26 -0000 On 6/6/13 2:33 PM, "Tim Bray" wrote: >On Thu, Jun 6, 2013 at 1:24 PM, Joe Hildebrand (jhildebr) > wrote: > >>"A string is a sequence of code points for almost any Unicode character." > >Well, surrogates are not code points for any Unicode character. Two >surrogates may be combined to produce a code point for a character. So >if we are going to treat unpaired surrogates as acceptable, then this is >false. If we say that strings MUST NOT > contain unpaired surrogates, then this is correct. -T --=20 Joe Hildebrand From jhildebr@cisco.com Thu Jun 6 13:43:40 2013 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 168DD21F998A for ; Thu, 6 Jun 2013 13:43:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ic0cxFpZEl-q for ; Thu, 6 Jun 2013 13:43:34 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 6EB2521E8085 for ; Thu, 6 Jun 2013 13:43:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=738; q=dns/txt; s=iport; t=1370551414; x=1371761014; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=MzsReYjnEriMa0B0n3HVoYrL3X5R1HqWky5FrY6olxQ=; b=gGCw6HNUrZNb4S2wa3g+BDheryCY8/C56GhDnSi5AlObVa3/KxSADKbP I6HkhpP74F5QKVGSHNb52BJCvtctU1O+/RwrupGw1W5MH/TbpWUt5J378 5VEzKpMoZsnnqskhnTabenC4qIqAkzqMiafv1t5Pk2RLMzhOyapmbCXHx 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AggFACLzsFGtJV2c/2dsb2JhbABZgwm/eXoWdIIjAQEBBDozDBIBCA4KChRCJQIEDgUIiAW7UI8BMQeCemEDqH+DD4In X-IronPort-AV: E=Sophos;i="4.87,817,1363132800"; d="scan'208";a="219758525" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-7.cisco.com with ESMTP; 06 Jun 2013 20:43:32 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r56KhR9I024775 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 6 Jun 2013 20:43:31 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.56]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.02.0318.004; Thu, 6 Jun 2013 15:43:29 -0500 From: "Joe Hildebrand (jhildebr)" To: Tim Bray Thread-Topic: [Json] Introduction Thread-Index: AQHOYuozVesgCtU8h0urTtW8JO4SV5kpCXqAgABmRYD//6FtgIAAZwGA//+eNwA= Date: Thu, 6 Jun 2013 20:43:28 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [10.21.88.234] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Stephan Beal , "json@ietf.org" Subject: Re: [Json] Introduction X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 06 Jun 2013 20:43:40 -0000 Sorry for the empty msg. I'm still learning to live with sticky modifier keys. On 6/6/13 2:33 PM, "Tim Bray" wrote: >On Thu, Jun 6, 2013 at 1:24 PM, Joe Hildebrand (jhildebr) > wrote: > >>"A string is a sequence of code points for almost any Unicode character." > >Well, surrogates are not code points for any Unicode character. Two >surrogates may be combined to produce a code point for a character. So >if we are going to treat unpaired surrogates as acceptable, then this is >false. If we say that strings MUST NOT > contain unpaired surrogates, then this is correct. -T that was intentional. I think unpaired surrogates are always a bug. --=20 Joe Hildebrand From cromis@gmail.com Thu Jun 6 13:50:31 2013 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 B122E21F9691 for ; Thu, 6 Jun 2013 13:50:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D2nPuNLMQsAH for ; Thu, 6 Jun 2013 13:50:26 -0700 (PDT) Received: from mail-qe0-f41.google.com (mail-qe0-f41.google.com [209.85.128.41]) by ietfa.amsl.com (Postfix) with ESMTP id 2CB3421F965B for ; Thu, 6 Jun 2013 13:50:26 -0700 (PDT) Received: by mail-qe0-f41.google.com with SMTP id b4so2262992qen.14 for ; Thu, 06 Jun 2013 13:50:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:from:date:x-google-sender-auth:message-id :subject:to:content-type; bh=Y6NnQ/MgZIo4/i/pU1pIIAjECcLTRmbOMcQZydoYBSk=; b=lYt7W0lk8b772v3RltAnfk0lL8QTaVZcKiEy5EUrOVTmMc4Z9ZNRmtRgRKAm9eT/xa wactXC8jjt8w1bMJm15Q+Gse2BGdPSsJzbXV3QMeJqjLhlS3TDjCK2zoPBsy0bLbwjIA TxiiEwMW/1Dm1A8osOuIVsDgemhMqBO36mW0TgyMfmP6dxfMmp0Aypn57ZjRsSzmqfJj yC9UXV1bXM6vMIN5per0FqMnINvgTzsYIhL/FOCuhsSjMger5F7JafTcQa2xN3hsV5sm /Hobvt1xhKzUfJ1HS4yffVuZJTcZmIADGFtQG61ElPfCf0H82IBDIbt8xLZpL9X3OAjy 9wlA== X-Received: by 10.224.177.201 with SMTP id bj9mr15237577qab.14.1370551825614; Thu, 06 Jun 2013 13:50:25 -0700 (PDT) MIME-Version: 1.0 Sender: cromis@gmail.com Received: by 10.49.106.228 with HTTP; Thu, 6 Jun 2013 13:50:05 -0700 (PDT) From: Jacob Davies Date: Thu, 6 Jun 2013 13:50:05 -0700 X-Google-Sender-Auth: XScXO-S-2YOkTMqghmWhzDGJ4ok Message-ID: To: "json@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Subject: [Json] The parts of JSON (a possible aid to discussion) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 06 Jun 2013 20:50:31 -0000 RFC 4267 does not clearly separate the various parts of JSON, relying on intuitive interpretation. That has worked out pretty well and I don't suggest changing that, but in this discussion I've found it useful to think in terms of distinct sub-parts. They are: 1) The JSON data model. 2) The textual language described by the ABNF. 3) The byte-sequence format denoted by the MIME media type "application/json". 1) The JSON data model. There is a description of the abstract data model in the original document: JSON can represent four primitive types (strings, numbers, booleans, and null) and two structured types (objects and arrays). A string is a sequence of zero or more Unicode characters [UNICODE]. An object is an unordered collection of zero or more name/value pairs, where a name is a string and a value is a string, number, boolean, null, object, or array. An array is an ordered sequence of zero or more values. This is clear except: a) It omits a detailed description of null, boolean, and number values. b) The description of strings as sequences of specifically Unicode characters is in my opinion misplaced in a section that otherwise is speaking in abstract terms. It is enough to say that a string is an indefinite-length sequence of (abstract) characters. [I see Douglas' last proposal for this section omits the mention of Unicode.] c) Implementations must be free to represent this abstract model as a concrete data model in any suitable way. For instance, they may not be able to represent Unicode strings, or non-integer numbers, but that is no reason they cannot work with some JSON models. The abstract model ought to be unconcerned with Unicode or any such temporal specificity, and the only thing the specification need say about the concrete models of implementation is to warn that they may vary in what ranges and sizes and kinds of values they can represent, including which characters they can faithfully represent. Perhaps something like: "JSON is a language for representing models consisting of four primitive types (strings, numbers, booleans, and null) and two structured types (objects and arrays). An object is an unordered collection of zero or more name/value pairs, where a name is a string and a value is a string, number, boolean, null, object, or array. An array is an ordered sequence of zero or more values. A number has an integer part of indefinite length, an optional decimal fractional part of indefinite length, and an optional integer exponent that may be positive or negative. A string is a sequence of zero or more characters. A boolean is either true or false. A null has no further structure." 2) The textual language described by the ABNF. This is most of the original specification. It very nearly consists of language defined in terms of an abstract but unspecified full alphabet containing abstract characters. The language is mostly concerned with the arrangement of those characters drawn from the basic JSON alphabet (required to be a subset of the full alphabet). There are a number of proscribed characters that are not required to be in the full alphabet, but if they are, may not literally appear in JSON texts (some control characters) and some that are also not required, not proscribed, but are restricted in where they may appear (certain whitespace characters). And then additionally, in JSON strings all other characters from the full alphabet that are not specifically restricted nor proscribed may be literally included. The language describes how to translate the abstract model to & from a textual representation in the abstract full alphabet, without specifying that full alphabet beyond the required, proscribed, and restricted characters. This includes the description of and required interpretation of escape sequences, and here it says that \u escapes should be interpreted as representing Unicode characters (or parts of surrogate pairs). That's the only place in this part where anything concretely related to Unicode needs to be invoked and it should not dictate that all concrete model representations or all JSON texts or all byte serializations be Unicode, only that the Unicode tables be used to look up the character for \u escapes. 3) The byte-sequence format denoted by the MIME media-type "application/json". This is the only part where the gritty details of format detection, encoding, byte-order marks and so on are important. It is connected to the textual language by requiring the interpretation of "byte sequences of type application/json" as "JSON texts where the full alphabet in use is Unicode, and the encoding is UTF-8 (unless the application can determine otherwise)". Applications could still be free to detect UTF-16 and UTF-32 formats, BOMs, or whatever else they feel they can determine; all that is required is that they must accept UTF-8 JSON texts if they claim to accept application/json. The standard should not be as hypertechnical as this, but it could omit certain unnecessarily specific phrasings (e.g. of Unicode strings in the abstract model and that JSON texts (in the abstract sense vs. "documents of type application/json") be written in Unicode). Interoperability should not be hurt by such omissions since the definition of the media-type still completely defines how to interpret a given sequence of bytes described as "application/json". -Jacob From cowan@ccil.org Thu Jun 6 14:07:16 2013 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 3422211E8119 for ; Thu, 6 Jun 2013 14:07:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.789 X-Spam-Level: X-Spam-Status: No, score=-2.789 tagged_above=-999 required=5 tests=[AWL=0.810, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ykA1JIdDiZ8k for ; Thu, 6 Jun 2013 14:07:11 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id 2D47311E8111 for ; Thu, 6 Jun 2013 14:07:11 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1UkhOo-0006Zm-06; Thu, 06 Jun 2013 17:07:10 -0400 Date: Thu, 6 Jun 2013 17:07:09 -0400 From: John Cowan To: Stephan Beal Message-ID: <20130606210709.GH3090@mercury.ccil.org> References: <51B0DFB6.10803@crockford.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Cc: "json@ietf.org" Subject: Re: [Json] Introduction X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 06 Jun 2013 21:07:16 -0000 Stephan Beal scripsit: > On Thu, Jun 6, 2013 at 9:57 PM, Joe Hildebrand (jhildebr) < > jhildebr@cisco.com> wrote: > > > On 6/6/13 1:15 PM, "Douglas Crockford" wrote: > > > A string is a sequence of zero or more characters. > > > > How about: > > > > "A string is a sequence of code points for almost any Unicode character." > > > > ... enclosed by double-quotes (ASCII 34 decimal, 0x22 hex). No, these remarks confuse a string as an object in the data model (which is what's being defined here) with the representation of a string on the wire. -- John Cowan cowan@ccil.org http://ccil.org/~cowan [R]eversing the apostolic precept to be all things to all men, I usually [before Darwin] defended the tenability of the received doctrines, when I had to do with the [evolution]ists; and stood up for the possibility of [evolution] among the orthodox --thereby, no doubt, increasing an already current, but quite undeserved, reputation for needless combativeness. --T. H. Huxley From sgbeal@googlemail.com Thu Jun 6 14:21:04 2013 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 0CE4D11E8103 for ; Thu, 6 Jun 2013 14:21:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.9 X-Spam-Level: X-Spam-Status: No, score=-0.9 tagged_above=-999 required=5 tests=[AWL=-0.215, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MISSING_HEADERS=1.292, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2NsJK3XB+UeQ for ; Thu, 6 Jun 2013 14:21:01 -0700 (PDT) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) by ietfa.amsl.com (Postfix) with ESMTP id D8E6F21E8056 for ; Thu, 6 Jun 2013 14:20:55 -0700 (PDT) Received: by mail-wi0-f170.google.com with SMTP id ey16so792330wid.5 for ; Thu, 06 Jun 2013 14:20:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:cc :content-type; bh=zD4KGBv4jqrf2Vv16mQtmXoBj6GQ9zIOMtVDKe6xeQ8=; b=vNkGTmx5VJ0eEpRUmCeIDCgZy6KdvBd1NhBzrKZjD28tf0du1cAPSYS9G7axpZDgyR LcjyJy6IF1z36YDL3tjfaESLz3Xewmksb7jUMc1GM4WDnmq3W4UbkaoyZZu8vgN4aX4m iW/JS84BmtNb2wcT2I9PFQBsXUfYPNAKpbGD1roZbIUXrYbwWXW3ICkZRd+mhX2jbEo0 c/+fngzbHpiUmpbrZ8Ha8KLJfYZt1/aqBgGb6y9J1AZwUN1KOCbtBk9TPQ0RqJLodj1e YPhZXtzTAt+dNDbonJnu5K6llg28DBur9bjXq36iT+tdbrt58YvNxPbsQGX6HyuW6iB/ pmkA== MIME-Version: 1.0 X-Received: by 10.180.14.130 with SMTP id p2mr11334417wic.32.1370553652663; Thu, 06 Jun 2013 14:20:52 -0700 (PDT) Received: by 10.194.42.230 with HTTP; Thu, 6 Jun 2013 14:20:52 -0700 (PDT) In-Reply-To: <20130606210709.GH3090@mercury.ccil.org> References: <51B0DFB6.10803@crockford.com> <20130606210709.GH3090@mercury.ccil.org> Date: Thu, 6 Jun 2013 23:20:52 +0200 Message-ID: From: Stephan Beal Cc: "json@ietf.org" Content-Type: multipart/alternative; boundary=f46d040f9f449cdca204de82e347 Subject: Re: [Json] Introduction X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 06 Jun 2013 21:21:04 -0000 --f46d040f9f449cdca204de82e347 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Jun 6, 2013 at 11:07 PM, John Cowan wrote: > No, these remarks confuse a string as an object in the data model > (which is what's being defined here) with the representation of a > string on the wire. > Fair enough, but the quotes are very important to the definition of strings for parsers and emiters. Imagine writing a parser for JSON if the quote marks fell within the realm of the proposed definition (without the quotes specifier). Imagine emiting strings per that definition - there's no mention of quotation marks. Maybe this particular place in the document isn't where it needs to be mentioned - it is part of the formal grammar, after all. If economy of words is a goal, trim it, by all means, but IMO it's more correct (meaning correct for more cases, though admittedly perhaps not for this particular level) if a quotes qualifier is included. -- ----- stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal --f46d040f9f449cdca204de82e347 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Jun 6, 2013 at 11:07 PM, John Cowan <cowan@m= ercury.ccil.org> wrote:
No, these remarks confuse a string as an obj= ect in the data model
(which is what's being defined here) with the representation of a
string on the wire.

Fair enough, = but the quotes are very important to the definition of strings for parsers = and emiters. Imagine writing a parser for JSON if the quote marks fell with= in the realm of the proposed definition (without the quotes specifier). Ima= gine emiting strings per that definition - there's no mention of quotat= ion marks. Maybe this particular place in the document isn't where it n= eeds to be mentioned - it is part of the formal grammar, after all. =A0If e= conomy of words is a goal, trim it, by all means, but IMO it's more cor= rect (meaning correct for more cases, though admittedly perhaps not for thi= s particular level) if a quotes qualifier is included.

--
----- stephan beal
http://wanderinghorse.net/home= /stephan/
--f46d040f9f449cdca204de82e347-- From sgbeal@googlemail.com Thu Jun 6 14:23:10 2013 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 E6DC121F9640 for ; Thu, 6 Jun 2013 14:23:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.516 X-Spam-Level: X-Spam-Status: No, score=-1.516 tagged_above=-999 required=5 tests=[AWL=0.461, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K5f6pdvhO7rQ for ; Thu, 6 Jun 2013 14:23:10 -0700 (PDT) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) by ietfa.amsl.com (Postfix) with ESMTP id 3062021F9630 for ; Thu, 6 Jun 2013 14:23:09 -0700 (PDT) Received: by mail-wi0-f177.google.com with SMTP id ey16so777302wid.10 for ; Thu, 06 Jun 2013 14:23:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=Eu8/kCuiXOXtLJSU0AVrcS/G7XXldnCW2yesjH2TLIs=; b=kzpHHCEGlD/NM4kBrC71oQMQ16o+YRCpL9Peyz1tR0jlUdxzDOmaKNseViGF7+TA5S 4ewnDSLsCg7b8EgyvlYmpQubG3qxVB6D60wwgho9+GDPHKEVhZmCDzl4hnqrIY6eNt3j 2aecdgcXcqWfaIfvXIGtVUaTCGJRbtbFN0LZrScOUhLjh2w6tFdk6pSbRvBWwjLQdBiT yVGZY9uPNi6Eee4X0sV0lHW/HUKErIcHnHkltWu1Vy+OaSvfVecm/VnizxbdDj+Q3r8t ZZVk/YlFcGFVe/KAY982IjVqVaOeBICHkgFKzQSMEIeMHpKwxVWER4htyDtxEbfGstH/ q/5w== MIME-Version: 1.0 X-Received: by 10.180.198.110 with SMTP id jb14mr11264821wic.37.1370553788179; Thu, 06 Jun 2013 14:23:08 -0700 (PDT) Received: by 10.194.42.230 with HTTP; Thu, 6 Jun 2013 14:23:08 -0700 (PDT) In-Reply-To: References: Date: Thu, 6 Jun 2013 23:23:08 +0200 Message-ID: From: Stephan Beal To: "json@ietf.org" Content-Type: multipart/alternative; boundary=047d7b6227ceb0a94d04de82eb75 Subject: Re: [Json] Introduction X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 06 Jun 2013 21:23:11 -0000 --047d7b6227ceb0a94d04de82eb75 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Jun 6, 2013 at 10:24 PM, Joe Hildebrand (jhildebr) < jhildebr@cisco.com> wrote: > A string is a sequence of code points for almost any Unicode character > enclosed by double-quotes (QUOTATION MARK, U+0022). > We forgot "... any Unicode character or a JSON character escape sequence..." though that sounds somewhat awkward. -- ----- stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal --047d7b6227ceb0a94d04de82eb75 Content-Type: text/html; charset=ISO-8859-1
On Thu, Jun 6, 2013 at 10:24 PM, Joe Hildebrand (jhildebr) <jhildebr@cisco.com> wrote:
A string is a sequence of code points for almost any Unicode character
enclosed by double-quotes (QUOTATION MARK, U+0022).

We forgot "... any Unicode character or a JSON character escape sequence..."

though that sounds somewhat awkward.

--
----- stephan beal
http://wanderinghorse.net/home/stephan/
--047d7b6227ceb0a94d04de82eb75-- From jhildebr@cisco.com Thu Jun 6 14:31:15 2013 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 AD98611E812B for ; Thu, 6 Jun 2013 14:31:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NUvG-ROZd-CB for ; Thu, 6 Jun 2013 14:31:10 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 1AB7F11E8103 for ; Thu, 6 Jun 2013 14:31:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1808; q=dns/txt; s=iport; t=1370554270; x=1371763870; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=oxCQtFGv8VQKBU6s+vtehluutfD/TFgPRVblLRYvuHU=; b=gOoyuBjqAEEJKnSTKZa/kEhe8jbcrTmdgQyQOhxRYnpm+CUkjkTmaDNC Fy4FuGa80u50d24Ummj7xfqRF2i+WYfk7o55LAZeSdYBVg83T+/9/oEIT chvbwe2fWMr0e6Thm3GKZaXqmwP7035+1OOxEDIcuScuiPeyKHotIy4o8 M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgcFAGP+sFGtJV2Z/2dsb2JhbABZgwm/HXoWdIIlAQQ6UQEIIhRCJQIEARIIiAW7TI8BOIJ6YQOof4MPgic X-IronPort-AV: E=Sophos;i="4.87,817,1363132800"; d="scan'208";a="219786447" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-5.cisco.com with ESMTP; 06 Jun 2013 21:31:09 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r56LV6bu023551 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 6 Jun 2013 21:31:06 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.56]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.02.0318.004; Thu, 6 Jun 2013 16:31:05 -0500 From: "Joe Hildebrand (jhildebr)" To: Jacob Davies , "json@ietf.org" Thread-Topic: [Json] The parts of JSON (a possible aid to discussion) Thread-Index: AQHOYvd+smBXbfrsAEGrkWVGGt20lpkpI5eA Date: Thu, 6 Jun 2013 21:31:05 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [10.21.88.234] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Json] The parts of JSON (a possible aid to discussion) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 06 Jun 2013 21:31:15 -0000 On 6/6/13 2:50 PM, "Jacob Davies" wrote: >b) The description of strings as sequences of specifically Unicode >characters is in my opinion misplaced in a section that otherwise is >speaking in abstract terms. It is enough to say that a string is an >indefinite-length sequence of (abstract) characters. [I see Douglas' >last proposal for this section omits the mention of Unicode.] Unicode code points are suitably abstract. I agree that "character" is probably not abstract enough. >This includes the description of and required interpretation of escape >sequences, and here it says that \u escapes should be interpreted as >representing Unicode characters (or parts of surrogate pairs). That's >the only place in this part where anything concretely related to >Unicode needs to be invoked and it should not dictate that all >concrete model representations or all JSON texts or all byte >serializations be Unicode, only that the Unicode tables be used to >look up the character for \u escapes. I doubt you need to use the tables, except much later in the process when turning the parsed code points into glyphs. I agree that in the abstract model, the only place you care about Unicode is when reasoning about strings, however. In the abstract model, true is an atom with a particular semantic, not the sequence of code points corresponding to the characters t,r,u, and e. The rest of your message, while probably technically correct, effectively says we're defining an infoset for JSON. I don't like where that got XML, but the multiple potential wire encodings for JSON may necessitate the extra level of abstraction, if we're going to be super-clear. Or we may elect to remain slightly fuzzy, and a lot easier to read. --=20 Joe Hildebrand From jsontest@yahoo.com Thu Jun 6 14:33:22 2013 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 9088221E8063 for ; Thu, 6 Jun 2013 14:33:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.156 X-Spam-Level: X-Spam-Status: No, score=-1.156 tagged_above=-999 required=5 tests=[AWL=1.442, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YcNlm1mt9tW2 for ; Thu, 6 Jun 2013 14:33:17 -0700 (PDT) Received: from nm50-vm8.bullet.mail.ne1.yahoo.com (nm50-vm8.bullet.mail.ne1.yahoo.com [98.138.121.152]) by ietfa.amsl.com (Postfix) with ESMTP id A7A8211E80FD for ; Thu, 6 Jun 2013 14:33:17 -0700 (PDT) Received: from [98.138.226.177] by nm50.bullet.mail.ne1.yahoo.com with NNFMP; 06 Jun 2013 21:33:11 -0000 Received: from [98.138.226.169] by tm12.bullet.mail.ne1.yahoo.com with NNFMP; 06 Jun 2013 21:33:11 -0000 Received: from [127.0.0.1] by omp1070.mail.ne1.yahoo.com with NNFMP; 06 Jun 2013 21:33:11 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 811070.91062.bm@omp1070.mail.ne1.yahoo.com Received: (qmail 33208 invoked by uid 60001); 6 Jun 2013 21:33:11 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1370554391; bh=VCImIx2nrnn743XQtGfLmah+PXKSMFJwuYpUm3mem/w=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=QQuaNUivNm3PDofHp3XvNtz/zHbBV49M9paWNYFDVhAF5OdwIEZYfGvMIbuYMWE1MOdtHKeqh+SCosaonxra3BEA8CUr5ZVWgPJEMfN2Gtj4eCMvhUJ41ce+N1tZ4Cdor1KGwzskMCGYXzqyNrVUXAtmEwG8YybT98u+wslW7pg= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=WsmcmuEqshD5lqTu6XVubppwGByS3eNPLkdyyjfGGRh8PzxV4g3w+zcqr7JOwPaHfzT+KlUlRUcjTmwdsNxK6r5MsCBQ2dD506RNRU+KHIL+IsnFPc5Nd3ztC9VcuIdm1OYFw+u7hvI2CuU38MpCH//G2wlLfH7OgIPcCeAnC2E=; X-YMail-OSG: gvFcl80VM1lcMnLoQlCAXOn7uAmh_mo.9HECkuc5_h.IOLr 59d3PWh7l7CzIeibblI8J6x7P_F3rxUbHVQS.rq8yPaeAGTeX9LcTkGqEvZz vfyrFe7YJ_Fy4ae4te2eEmP5YreAj0XuHTi9N2AdC5ENrsjgZ7BKdJqvijJ8 ljvvBCDHEzx71EOvdeSCLTwP3J65hWngyxK0D8TCDBbrQedJdI0rr4mPQqTI ntnOXUP_AZAhEKKaU5KYmrZu5wXxhYaRqNRi1hRXELNg1SIy_1s2HLeaUKZ0 MS5vUBZVklxioWVzQ7yY6RC8KLAed1aLQ22kU1E27jjCsDr.2NV.5mAYC0Ta mwKWqGJWPHW6MoOVhm3pyXOJcyt2LEoyDBVPmPc9H4Usr.W3K1It0V20.y5I yz37ETZVWImV99w4fa.sn.i6AC5lzVLswmC7roGWX0zY4hevPiMq1sJTmCWH XRR0b5GnCy15AJguC61e0LAvx.oGyGjb43tcZtbrtBRiKU2pu0UUQWmzqVfX CEZkmUDFd374rVxWWLEi4SR948L00SmRCFiFsXqoeWp23QBSKS8GDWSRRRIV skbj4_Q.pqq4w47oLhJzjYIKGyyhYGcFwMqYGjS2cI.LOTndnVNkq_YThoYO atvM_rM9dCPOKlMqZmuVJ_znbTtLO_F6TI8XPzgAg1omAZ0n4 Received: from [76.29.100.42] by web125601.mail.ne1.yahoo.com via HTTP; Thu, 06 Jun 2013 14:33:11 PDT X-Rocket-MIMEInfo: 002.001, VGhlIEdvIEpTT04gcGFyc2VyICjCoGh0dHA6Ly9nb2xhbmcub3JnL3BrZy9lbmNvZGluZy9qc29uL8KgKSB1c2VzIHRoZSBsYXN0IG5hbWUvdmFsdWUgZW50cnkuIFRoZSBjb2RlIGZvciBteSB0ZXN0IGlzIGJlbG93IGFuZCB0aGVyZSdzIGFsc28gYSBydW5uYWJsZSB2ZXJzaW9uIGF0wqBodHRwOi8vcGxheS5nb2xhbmcub3JnL3AvRGYxYWhDSGl2QiAuCsKgCnBhY2thZ2UgbWFpbgoKaW1wb3J0ICJmbXQiCmltcG9ydCAiZW5jb2RpbmcvanNvbiIKCmZ1bmMgbWFpbigpIHsKdmFyIGpzb25CbG9iID0gW11ieXQBMAEBAQE- X-Mailer: YahooMailWebService/0.8.145.547 References: Message-ID: <1370554391.97406.YahooMailNeo@web125601.mail.ne1.yahoo.com> Date: Thu, 6 Jun 2013 14:33:11 -0700 (PDT) From: Vinny A To: Paul Hoffman , "json@ietf.org" In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1981468715-1989714923-1370554391=:97406" Subject: Re: [Json] Call for real-world examples of how parsers deal with duplicate keys X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Vinny A List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 21:33:22 -0000 ---1981468715-1989714923-1370554391=:97406 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable The Go JSON parser (=A0http://golang.org/pkg/encoding/json/=A0) uses the la= st name/value entry. The code for my test is below and there's also a runna= ble version at=A0http://play.golang.org/p/Df1ahCHivB .=0A=A0=0Apackage main= =0A=0Aimport "fmt"=0Aimport "encoding/json"=0A=0Afunc main() {=0Avar jsonBl= ob =3D []byte(`=0A{"A": 1, "A": 2}=0A`)=0Atype JSONExample struct {=0AA int= =0A}=0Avar json_example JSONExample=0Aerr :=3D json.Unmarshal(jsonBlob, &js= on_example)=0Aif err !=3D nil {=0Afmt.Println("error:", err)=0A}=0Afmt.Prin= tf("%+v", json_example)=0A}=0A=0A=0AOutput:=A0{A:2}=0A=0A----------------= =0A-Vinny=0Awww.jsontest.com=0A=0A=0A=0A________________________________=0A= From: Paul Hoffman =0ATo: "json@ietf.org" =0ASent: Thursday, June 6, 2013 12:41 PM=0ASubject: [Json] Call for = real-world examples of how parsers deal with duplicate keys=0A =0A=0AGreeti= ngs again. Knowing what current parsers do with duplicate keys might be use= ful to this discussion. Of course, some people will exclaim "but that's wro= ng!" to some of what we see, but seeing it may be useful nonetheless.=0A=0A= I propose the following JSON text for the tests:=0A=0A{"a":1,"a":2}=0A=0A--= Paul Hoffman=0A=0A=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0A=0AAnd I'll start with Python.=0A=0Afro= m __future__ import print_function=0Aimport json=0Aa =3D '{"a":1,"a":2}'=0A= print(json.loads(a))=0A=0A# python2.6 keytest.py=0A{u'a': 2}=0A# python2.7 = keytest.py=0A{u'a': 2}=0A# python3.2 keytest.py=0A{'a': 2}=0A=0A=0A________= _______________________________________=0Ajson mailing list=0Ajson@ietf.org= =0Ahttps://www.ietf.org/mailman/listinfo/json ---1981468715-1989714923-1370554391=:97406 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
= The Go JSON parser ( http://golang.org/pkg/encoding/json/ ) uses the last name/value entry. The code for my test is below = and there's also a runnable version at http://play.golang.org/p/Df1ahC= HivB .
 
package main

import "fmt"
import = "encoding/json"

func main() {
=09var jsonBlob =3D []byte(`
=09=09{"A": 1, "A": 2}
=09`)
=09type JSONExample struct {
= =09=09A int=
=09}
=09= var json_example JSONExample
=09err :=3D json.Unmarshal(jsonBlob, &am= p;json_example)
=09if err !=3D nil {
=09=09fmt.Println("error:", err)
=09}
=09fmt.Printf("%+v", json_example)
}

<= /div>

Output: {A:2}

----------------
-Vin= ny
www.jsontest.com

From: Paul Hoffman <paul.hoffman@vpn= c.org>
To: "json@ietf.org" <j= son@ietf.org>
Sent: Thursday, June 6, 2013 12:41 PM
Subject: [Json] Call for real-world examples of how parsers dea= l with=0A=09duplicate keys

Greetings again. Knowing what current parsers do with duplicate keys = might be useful to this discussion. Of course, some people will exclaim "bu= t that's wrong!" to some of what we see, but seeing it may be useful noneth= eless.

I propose the following JSON text for the tests:

{"a":= 1,"a":2}

--Paul Hoffman

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

And I'll star= t with Python.

from __future__ import print_function
import json<= br>a =3D '{"a":1,"a":2}'
print(json.loads(a))

# python2.6 keytest= .py
{u'a': 2}
# python2.7 keytest.py
{u'a': 2}
# python3.2 keyt= est.py
{'a': 2}


_____________________________________________= __
json mailing list
json@ietf.org
https://www.ietf.org/mailman/listinfo/json

---1981468715-1989714923-1370554391=:97406-- From tbray@textuality.com Thu Jun 6 14:36:38 2013 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 0A05311E812D for ; Thu, 6 Jun 2013 14:36:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.157 X-Spam-Level: X-Spam-Status: No, score=-1.157 tagged_above=-999 required=5 tests=[AWL=1.819, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aJNMU7wxv6V7 for ; Thu, 6 Jun 2013 14:36:33 -0700 (PDT) Received: from mail-vc0-f169.google.com (mail-vc0-f169.google.com [209.85.220.169]) by ietfa.amsl.com (Postfix) with ESMTP id 7B6EF11E812E for ; Thu, 6 Jun 2013 14:36:33 -0700 (PDT) Received: by mail-vc0-f169.google.com with SMTP id ia10so2371325vcb.28 for ; Thu, 06 Jun 2013 14:36:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=cROath311XYipEmw7DF11X0YCbDHxwqH3yVy0S1GhCs=; b=M9dbuwTTmeih1vkBFLzNhy1jmo6oDA9ZcDR1bjap9d+m49AsleLBe951RPLTrYwzlu kATmGClyI0jcxTYQShBKpldcoL3drr67q+Kk/dXnNMrx8+ZbLzD1fsQ/eNZYzUpIyAOw VQ5gH/EgE4vlS4+qF/u+yxUy0LNWTtbtKervQNzGs2+zNdrWN/tDeyvfiHYgBxY/s8H7 1yaTCRXPasKBoptF5di7R4vuk4U3Ak0CoVNLcjouRstkiIk1JLYxMtVAEXFoFCxS5s8e ZFyDeVpD0UpfA3vHZXh6icIujCLe1Dh6RgwoWrXyOUHuq/ikqjlJRI6TzIRbbZRUwQBW eU7Q== MIME-Version: 1.0 X-Received: by 10.52.237.228 with SMTP id vf4mr2238325vdc.79.1370554592739; Thu, 06 Jun 2013 14:36:32 -0700 (PDT) Received: by 10.220.48.14 with HTTP; Thu, 6 Jun 2013 14:36:32 -0700 (PDT) X-Originating-IP: [96.49.81.176] In-Reply-To: References: Date: Thu, 6 Jun 2013 14:36:32 -0700 Message-ID: From: Tim Bray To: Stephan Beal Content-Type: multipart/alternative; boundary=089e0122f6aaa5592404de831b8e X-Gm-Message-State: ALoCoQmuENN5hI1hrXkUQEF/oXaROUwxFw3VwRyYn07o+43dzTHD5ceBgoJ5EmZYpxRA9cvP5iX9 Cc: "json@ietf.org" Subject: Re: [Json] Introduction X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 06 Jun 2013 21:36:38 -0000 --089e0122f6aaa5592404de831b8e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Overthinking. In the introduction, the key thing to get across is that a string contains unicode characters. The details of how it=E2=80=99s delimi= ted and escaped, and the few characters that are excluded and so on, can go in the String section. Assuming we are excluding naked surrogates: =E2=80=9CA string is a sequence of Unicode characters.=E2=80=9D On Thu, Jun 6, 2013 at 2:23 PM, Stephan Beal wrote: > On Thu, Jun 6, 2013 at 10:24 PM, Joe Hildebrand (jhildebr) < > jhildebr@cisco.com> wrote: > >> A string is a sequence of code points for almost any Unicode character >> enclosed by double-quotes (QUOTATION MARK, U+0022). >> > > We forgot "... any Unicode character or a JSON character escape > sequence..." > > though that sounds somewhat awkward. > > -- > ----- stephan beal > http://wanderinghorse.net/home/stephan/ > http://gplus.to/sgbeal > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > > --089e0122f6aaa5592404de831b8e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Overthinking.=C2=A0 In the introduction, the key thin= g to get across is that a string contains unicode characters.=C2=A0 The det= ails of how it=E2=80=99s delimited and escaped, and the few characters that= are excluded and so on, can go in the String section.=C2=A0 Assuming we ar= e excluding naked surrogates:

=E2=80=9CA string is a sequence of Unicode characters.=E2=80=9D


On Th= u, Jun 6, 2013 at 2:23 PM, Stephan Beal <sgbeal@googlemail.com>= wrote:
On Thu, J= un 6, 2013 at 10:24 PM, Joe Hildebrand (jhildebr) <jhildebr@cisco.com= > wrote:
A string is a sequence of code points f= or almost any Unicode character
enclosed by double-quotes (QUOTATI= ON MARK, U+0022).

We forgot "... any Unicode char= acter or a JSON character escape sequence..."

though that sounds somewhat awkward.

--
----- stephan beal
http://wanderinghorse.net/home/stephan/

_______________________________________________
json mailing list
json@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/json


--089e0122f6aaa5592404de831b8e-- From mamille2@cisco.com Thu Jun 6 14:36:44 2013 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 5FF1611E812E for ; Thu, 6 Jun 2013 14:36:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sg4CmD8YGRk3 for ; Thu, 6 Jun 2013 14:36:38 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id B5D1611E812D for ; Thu, 6 Jun 2013 14:36:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6839; q=dns/txt; s=iport; t=1370554598; x=1371764198; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=ZIVxRcOWizuCSgUd47s0bMScPS1EQo7UAhw4eaXmOFo=; b=DpUa2hVzXKiwgDOdREDFszwRt02daR+0vWQwLDD8j9d51pL38fcqAE+e SkWA43IoOdAReCI484rKX7cm3QrAIDv/sqqcKuzGT02DiXKcZkcOlLAGs 5P8oFaIwKVscu4QpAghwW0g4qCxa4GSB8Ca/5txO4fcnx+Fkq0yo3lkeM 4=; X-Files: smime.p7s : 4136 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AggFAG0AsVGtJXG//2dsb2JhbABZgwm/HXoWdIIjAQEBBHkFCwIBCA4KCiQCMCUCBA4FCAaHbQMPsmYNiFKMVYIsMQeCemEDkACBLJdTgw+CJw X-IronPort-AV: E=Sophos;i="4.87,817,1363132800"; d="p7s'?scan'208";a="219755101" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-2.cisco.com with ESMTP; 06 Jun 2013 21:36:38 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r56LacnY005118 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 6 Jun 2013 21:36:38 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.24]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.02.0318.004; Thu, 6 Jun 2013 16:36:37 -0500 From: "Matt Miller (mamille2)" To: Stephan Beal Thread-Topic: [Json] Introduction Thread-Index: AQHOYuozBqrUSJOZ7kCTR5ofVC4gzJkpbhMAgAABrICAAAYDAIAAEE8AgAADwwA= Date: Thu, 6 Jun 2013 21:36:37 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.129.24.59] Content-Type: multipart/signed; boundary="Apple-Mail=_655F993A-D064-4CDE-8923-61C3037A2998"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Cc: "json@ietf.org" Subject: Re: [Json] Introduction X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 06 Jun 2013 21:36:44 -0000 --Apple-Mail=_655F993A-D064-4CDE-8923-61C3037A2998 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On Jun 6, 2013, at 3:23 PM, Stephan Beal wrote: > On Thu, Jun 6, 2013 at 10:24 PM, Joe Hildebrand (jhildebr) < > jhildebr@cisco.com> wrote: >=20 >> A string is a sequence of code points for almost any Unicode = character >> enclosed by double-quotes (QUOTATION MARK, U+0022). >>=20 >=20 > We forgot "... any Unicode character or a JSON character escape = sequence..." >=20 > though that sounds somewhat awkward. /me doffs hat Remember is the intro. It doesn't need to cover all of the details; = that's done in other sections. Personally, I think it would be better to say even less about the = details, and more about origins and goals. - m&m Matt Miller < mamille2@cisco.com > Cisco Systems, Inc. --Apple-Mail=_655F993A-D064-4CDE-8923-61C3037A2998 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMezCCBjQw ggQcoAMCAQICAR4wDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDE1NVoX DTE3MTAyNDIxMDE1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMcJg8zOLdgasSmkLhOrlr6KMoOMpohBllVHrdRvEg/q6r8jR+EK 75xCGhR8ToREoqe7zM9/UnC6TS2y9UKTpT1v7RSMzR0t6ndl0TWBuUr/UXBhPk+Kmy7bI4yW4urC +y7P3/1/X7U8ocb8VpH/Clt+4iq7nirMcNh6qJR+xjOhV+VHzQMALuGYn5KZmc1NbJQYclsGkDxD z2UbFqE2+6vIZoL+jb9x4Pa5gNf1TwSDkOkikZB1xtB4ZqtXThaABSONdfmv/Z1pua3FYxnCFmdr /+N2JLKutIxMYqQOJebr/f/h5t95m4JgrM3Y/w7YX9d7YAL9jvN4SydHsU6n65cCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRTcu2SnODaywFc fH6WNU7y1LhRgjAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBAAqDCH14qywG XLhjjF6uHLkjd02hcdh9hrw+VUsv+q1eeQWB21jWj3kJ96AUlPCoEGZ/ynJNScWy6QMVQjbbMXlt UfO4n4bGGdKo3awPWp61tjAFgraLJgDk+DsSvUD6EowjMTNx25GQgyYJ5RPIzKKR9tQW8gGK+2+R HxkUCTbYFnL6kl8Ch507rUdPPipJ9CgJFws3kDS3gOS5WFMxcjO5DwKfKSETEPrHh7p5shuuNktv sv6hxHTLhiMKX893gxdT3XLS9OKmCv87vkINQcNEcIIoFWbP9HORz9v3vQwR4e3ksLc2JZOAFK+s sS5XMEoznzpihEP0PLc4dCBYjbvSD7kxgDwZ+Aj8Q9PkbvE9sIPP7ON0fz095HdThKjiVJe6vofq +n6b1NBc8XdrQvBmunwxD5nvtTW4vtN6VY7mUCmxsCieuoBJ9OlqmsVWQvifIYf40dJPZkk9YgGT zWLpXDSfLSplbY2LL9C9U0ptvjcDjefLTvqSFc7tw1sEhF0n/qpA2r0GpvkLRDmcSwVyPvmjFBGq Up/pNy8ZuPGQmHwFi2/14+xeSUDG2bwnsYJQG2EdJCB6luQ57GEnTA/yKZSTKI8dDQa8Sd3zfXb1 9mOgSF0bBdXbuKhEpuP9wirslFe6fQ1t5j5R0xi72MZ8ikMu1RQZKCyDbMwazlHiMIIGPzCCBSeg AwIBAgIDBoRIMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcN MTMwNDMwMjE1NDQyWhcNMTQwNTAyMDUzOTA0WjBbMRkwFwYDVQQNExBiN2F6NndOY0t0R3JtMEpF MRswGQYDVQQDDBJtYW1pbGxlMkBjaXNjby5jb20xITAfBgkqhkiG9w0BCQEWEm1hbWlsbGUyQGNp c2NvLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJbKBMsG+9UFTx9uq/bhhXgu vJvO8z7cwKaqqwZhVf5z/kHFyCNijtmTOE+YXjA8mWR4aoBwB5SvGypI/cJUofJ+AlBTC4g+RMx/ K0Ab4/jQqTQz9CDzMOB+Wm+rt8ZJ7A8ZzOJmNDAsf/VvB8l2A1SQz1UsAixgH16NTr8SlblAXEKk 4hwpCudUiNjjQokqJ0H686UBKVorcZSgXaza8XMqGtJF/8mNhR9GQYi7Xht1ky+9LFOrto2daZto KJRwMeVusVdHUeKEQSu7jztw8HchH3KEb7Q+r5X+hhDZoddfKE8d5eyPuhiZdrzv7OlNZ0fSLdx7 3AE3nx9/R5YlXucCAwEAAaOCAtgwggLUMAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQW MBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQUxGd+/qrdVudHrIKkw5xOMY7eaLUwHwYD VR0jBBgwFoAUU3Ltkpzg2ssBXHx+ljVO8tS4UYIwHQYDVR0RBBYwFIESbWFtaWxsZTJAY2lzY28u Y29tMIIBTAYDVR0gBIIBQzCCAT8wggE7BgsrBgEEAYG1NwECAzCCASowLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0 Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBp c3N1ZWQgYWNjb3JkaW5nIHRvIHRoZSBDbGFzcyAxIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9m IHRoZSBTdGFydENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBw dXJwb3NlIGluIGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMDYG A1UdHwQvMC0wK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUxLWNybC5jcmwwgY4G CCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIv Y2xhc3MxL2NsaWVudC9jYTBCBggrBgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2Vy dHMvc3ViLmNsYXNzMS5jbGllbnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRz c2wuY29tLzANBgkqhkiG9w0BAQUFAAOCAQEAlDhXbGEI7lbqUcu5r2JHZaMsbRZda/99ZqODzWGX 0llou9jGccsAWDPPwRRe2+ROpXfH4cuJZElTcLDeZSp/qpXKhjYieFSX8+Ml9sKEj5UOSqQLyoLk PtrIJV12Jk3nuG2Jc0UeEnGwK/aqtzy7+bfEVI0ziyVM2gChHh0RH74KyiwYWknbOTRIkZcz/ulE DVFQp63uj6wfmDNvAUHBAdhKVqA1S/rfP1KcDZpf1NfvwXJibiqTRA6K1EOxTJOP41n/XdvHqHXL RWL2xrOUI9/URANr/ok3OrsuZEMFnAAGefS1bWS/hFtUGVkHGiKEBbyDW7da2ULXbuC7umrQnzGC A28wggNrAgEBMIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkG A1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwaESDAJBgUrDgMCGgUA oIIBrzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMzA2MDYyMTM2 MzdaMCMGCSqGSIb3DQEJBDEWBBTRs9reG0hCGjUF+Q8/z/ZaRthasjCBpQYJKwYBBAGCNxAEMYGX MIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3Mg MSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwaESDCBpwYLKoZIhvcNAQkQAgsxgZeg gZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1 cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAx IFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDBoRIMA0GCSqGSIb3DQEBAQUABIIBAHn/ 0txxVitl8BwKdJ0EM1o7JAa7wflVjRuMW+h/pcbmhr+Sn8h5+iRe5hBBv9tp9qMah2//mYFdepbz daSpsoxwdsrd+wSrMA2lIm0mn4a7TBvHL0J9IS7r9f3iegM3fyH1cO8g4KbT5YfUIWgFHaeJHGGd qXt8BHk6qStWVZoVoBfqEDZWheRtBY73s+bdkTd1UD1/67r+dQwcnFxrzQ02BAMSo43ajqYoHkuW Re7TWh8w34DBDVtkXgr/8jhzdGuURkHik+NXwA0DLqS8HusVYzMYwNw36dtQZCRbMZRpH2vrzx2d ae0dNYt/zM1ArRv5g9lRvl7NvWdVD0MArNoAAAAAAAA= --Apple-Mail=_655F993A-D064-4CDE-8923-61C3037A2998-- From petejson@codalogic.com Thu Jun 6 14:44:16 2013 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 15FDF21E8063 for ; Thu, 6 Jun 2013 14:44:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.368 X-Spam-Level: X-Spam-Status: No, score=0.368 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, SARE_HEAD_XUNSENT=1.666, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ad3jehd1fZfO for ; Thu, 6 Jun 2013 14:44:11 -0700 (PDT) Received: from codalogic.com (codalogic.com [94.136.60.219]) by ietfa.amsl.com (Postfix) with ESMTP id CB46821E8056 for ; Thu, 6 Jun 2013 14:44:10 -0700 (PDT) Received: (qmail 1075 invoked from network); 6 Jun 2013 22:44:07 +0100 Received: from host86-132-241-164.range86-132.btcentralplus.com (HELO codalogic) (86.132.241.164) by codalogic.com with (RC4-MD5 encrypted) SMTP; 6 Jun 2013 22:44:07 +0100 Message-ID: <7AD64D1F8EE442CA9E340D367D943A0D@codalogic> From: "Pete Cordell" To: "Tim Bray" , "Stephan Beal" X-Unsent: 1 x-vipre-scanned: 0319EABC0048300319EC09 References: Date: Thu, 6 Jun 2013 22:44:08 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Cc: json@ietf.org Subject: Re: [Json] Introduction X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 06 Jun 2013 21:44:16 -0000 Original Message From: "Tim Bray" > Overthinking. In the introduction, the key thing to get across is that a > string contains unicode characters. The details of how it’s delimited and > escaped, and the few characters that are excluded and so on, can go in the > String section. Assuming we are excluding naked surrogates: > > “A string is a sequence of Unicode characters.†Does this allow for empty strings? Maybe that's another detail that can be left to the string section. I guess most people know that strings can be empty. Pete Cordell Codalogic Ltd C++ tools for C++ programmers, http://codalogic.com Read & write XML in C++, http://www.xml2cpp.com From cowan@ccil.org Thu Jun 6 15:03:10 2013 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 7912311E811B for ; Thu, 6 Jun 2013 15:03:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.879 X-Spam-Level: X-Spam-Status: No, score=-2.879 tagged_above=-999 required=5 tests=[AWL=0.720, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10h1j5aC-f78 for ; Thu, 6 Jun 2013 15:03:01 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id 44A2F11E80AD for ; Thu, 6 Jun 2013 15:02:58 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1UkiGf-000411-CN; Thu, 06 Jun 2013 18:02:49 -0400 Date: Thu, 6 Jun 2013 18:02:49 -0400 From: John Cowan To: "Joe Hildebrand (jhildebr)" Message-ID: <20130606220249.GJ3090@mercury.ccil.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Cc: Jacob Davies , "json@ietf.org" Subject: Re: [Json] The parts of JSON (a possible aid to discussion) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 06 Jun 2013 22:03:12 -0000 Joe Hildebrand (jhildebr) scripsit: > The rest of your message, while probably technically correct, effectively > says we're defining an infoset for JSON. I don't like where that got XML, Hey, I did the best I could, given vague and ever-changing requirements. The MicroXML data model is far superior -- and it's represented using JSON. See . You can't go wrong emulating James Clark when it comes to spec-writing. -- Evolutionary psychology is the theory John Cowan that men are nothing but horn-dogs, http://www.ccil.org/~cowan and that women only want them for their money. cowan@ccil.org --Susan McCarthy (adapted) From cabo@tzi.org Thu Jun 6 15:04:23 2013 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 DF3C411E80AD for ; Thu, 6 Jun 2013 15:04:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CB-h9O4My8Cq for ; Thu, 6 Jun 2013 15:04:16 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 49F5111E811B for ; Thu, 6 Jun 2013 15:04:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r56M44rd003808; Fri, 7 Jun 2013 00:04:04 +0200 (CEST) Received: from [192.168.182.246] (unknown [217.111.178.142]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id EF9AC3F7E; Fri, 7 Jun 2013 00:04:03 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <51B0DFB6.10803@crockford.com> Date: Fri, 7 Jun 2013 00:04:01 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <74EA08DC-E75E-413C-9EC8-E496556B8F9B@tzi.org> References: <51B0DFB6.10803@crockford.com> To: Douglas Crockford X-Mailer: Apple Mail (2.1503) Cc: "json@ietf.org" Subject: Re: [Json] Introduction X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 06 Jun 2013 22:04:23 -0000 On Jun 6, 2013, at 21:15, Douglas Crockford = wrote: > An object is an unordered collection of zero or more name/value > pairs, where a name is a string and a value is a string, number, > boolean, null, object, or array. In the light of the "real-world examples" thread: Is "unordered" still entirely true? And should the expectation that the names are unique enter this = overview? (a string, .... -> any JSON value; we don't enumerate them all for = arrays either.) Gr=FC=DFe, Carsten From jhildebr@cisco.com Thu Jun 6 15:06:16 2013 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 8B41011E811B for ; Thu, 6 Jun 2013 15:06:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RX+XscmyPiK6 for ; Thu, 6 Jun 2013 15:06:11 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 1773511E80AD for ; Thu, 6 Jun 2013 15:06:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=361; q=dns/txt; s=iport; t=1370556370; x=1371765970; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=a4ytMgryAfIDJ3gdTCwU0ke/Yb1ckr+mdYhzSNXtAUc=; b=SaBLgjUitclrAuwaaJBrZtHo+bE47M41J2Q36qE6ZJYgIWLF/gmyi2zr UHndfhG9l/NXriUQ195yewDDakNJIyYx9mUeJ0K8XZflFuzq/jrT9V3j/ 1YBooBdLWfVXGKACjeGRj4sq5zoNUY/e4cFb6MgcGEjmRyu16VA5iUIDE Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgcFACIHsVGtJXG//2dsb2JhbABZgwm/HnoWdIIlAQR5EgEIIlYlAgQBDQUIiAW7Ro8BMQeCemEDiGigF4MPgic X-IronPort-AV: E=Sophos;i="4.87,817,1363132800"; d="scan'208";a="219788595" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-8.cisco.com with ESMTP; 06 Jun 2013 22:06:09 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r56M68qo011318 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 6 Jun 2013 22:06:08 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.56]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.02.0318.004; Thu, 6 Jun 2013 17:06:08 -0500 From: "Joe Hildebrand (jhildebr)" To: Pete Cordell , Tim Bray , Stephan Beal Thread-Topic: [Json] Introduction Thread-Index: AQHOYv75VesgCtU8h0urTtW8JO4SV5kpLVMA Date: Thu, 6 Jun 2013 22:06:08 +0000 Message-ID: In-Reply-To: <7AD64D1F8EE442CA9E340D367D943A0D@codalogic> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [10.21.88.234] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <892DC68D2B5FEC43A8ED3B15A7860F69@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "json@ietf.org" Subject: Re: [Json] Introduction X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 06 Jun 2013 22:06:16 -0000 On 6/6/13 3:44 PM, "Pete Cordell" wrote: >> =B3A string is a sequence of Unicode characters.=B2 > > >Does this allow for empty strings? Maybe that's another detail that can >be=20 >left to the string section. I guess most people know that strings can be >empty. The empty sequence is a sequence. --=20 Joe Hildebrand From jhildebr@cisco.com Thu Jun 6 15:08:13 2013 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 D40C811E811B for ; Thu, 6 Jun 2013 15:08:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I6HynAZbr873 for ; Thu, 6 Jun 2013 15:08:06 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 32C7A11E811E for ; Thu, 6 Jun 2013 15:08:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=332; q=dns/txt; s=iport; t=1370556486; x=1371766086; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=x8ND9oZBdlOyX6YxL/jM7I7Af7ErIPeGNoDdGs0KUjE=; b=dXpP7R+6cMCxB3Gxr3JLA+A8a74Ik7wUN9psjQhOLMfxbhrjdkklxnU/ 0+oDbFxzHaLeGxu3RG0yXkR5xcs9aYUL5u6bWeIgmlB+6PUT40yPHSVWo TsFNhcbWaehtuXY+B0SXzyP3FljAY9h2bb6KOay61HK8MSzOKZDSOuS/8 Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgcFAJ8HsVGtJXG8/2dsb2JhbABZgwm/HnoWdIIlAQQ6PxIBCA4UFEIlAgQBDQUIiAW7SI8BMQeCemEDqH+DD4In X-IronPort-AV: E=Sophos;i="4.87,817,1363132800"; d="scan'208";a="219796685" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-5.cisco.com with ESMTP; 06 Jun 2013 22:08:05 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r56M85IA008561 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 6 Jun 2013 22:08:05 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.56]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.02.0318.004; Thu, 6 Jun 2013 17:08:05 -0500 From: "Joe Hildebrand (jhildebr)" To: Carsten Bormann , Douglas Crockford Thread-Topic: [Json] Introduction Thread-Index: AQHOYuozVesgCtU8h0urTtW8JO4SV5kpkX2A//+cigA= Date: Thu, 6 Jun 2013 22:08:04 +0000 Message-ID: In-Reply-To: <74EA08DC-E75E-413C-9EC8-E496556B8F9B@tzi.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [10.21.88.234] Content-Type: text/plain; charset="us-ascii" Content-ID: <81F9053DB442DD488CA772BF4F56236D@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "json@ietf.org" Subject: Re: [Json] Introduction X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 06 Jun 2013 22:08:13 -0000 On 6/6/13 4:04 PM, "Carsten Bormann" wrote: >Is "unordered" still entirely true? It is in the abstract model. It never was in the wire-encoded. >And should the expectation that the names are unique enter this overview? No. That's an edge case that doesn't belong in the intro. --=20 Joe Hildebrand From sgbeal@googlemail.com Thu Jun 6 15:09:18 2013 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 875CD11E811B for ; Thu, 6 Jun 2013 15:09:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.927 X-Spam-Level: X-Spam-Status: No, score=-0.927 tagged_above=-999 required=5 tests=[AWL=-0.242, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MISSING_HEADERS=1.292, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MPgDnvaCGCcL for ; Thu, 6 Jun 2013 15:09:17 -0700 (PDT) Received: from mail-we0-x22c.google.com (mail-we0-x22c.google.com [IPv6:2a00:1450:400c:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 88E2F11E8100 for ; Thu, 6 Jun 2013 15:09:16 -0700 (PDT) Received: by mail-we0-f172.google.com with SMTP id q56so2560088wes.3 for ; Thu, 06 Jun 2013 15:09:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:cc :content-type; bh=9pfFCtwvdI40LM0F+dKczZClzUf7MtfM7rfzo4kEkO0=; b=kHVy2P86xPl90zU/H8imSwGgIERw0Fkz/CiLF9mz6fMmJ9d1tthddNmylAt+mdqmG4 1OUKWmT/6N3UF0D1HIhtIX5GEDWQu2aEqGxLexSP//DmJwCvX9fXInVribR1Ecnlzfgi QxUJM6he0bfqti8LT5+lh6GT504M7L/jmrzSGbfAZJUvZAx36XqpydoLaHwSFDUduuT1 2DcxRamyg7bOPzngpLZQXi696J3Pd3VIwq8iL7q/kt6tBD66LNEtl61Ss3WvHckxa0Wh eRUMHX6pKdmkYExsLzbRuqZdAuyklH1vzxT73pjzxo/abRYTq/Tjv6tjjiLhz8bCeHTU Wa2g== MIME-Version: 1.0 X-Received: by 10.180.206.180 with SMTP id lp20mr35619wic.41.1370556555415; Thu, 06 Jun 2013 15:09:15 -0700 (PDT) Received: by 10.194.42.230 with HTTP; Thu, 6 Jun 2013 15:09:15 -0700 (PDT) In-Reply-To: <74EA08DC-E75E-413C-9EC8-E496556B8F9B@tzi.org> References: <51B0DFB6.10803@crockford.com> <74EA08DC-E75E-413C-9EC8-E496556B8F9B@tzi.org> Date: Fri, 7 Jun 2013 00:09:15 +0200 Message-ID: From: Stephan Beal Cc: "json@ietf.org" Content-Type: multipart/alternative; boundary=001a11c380b0a156ff04de83903c Subject: Re: [Json] Introduction X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 06 Jun 2013 22:09:18 -0000 --001a11c380b0a156ff04de83903c Content-Type: text/plain; charset=ISO-8859-1 On Fri, Jun 7, 2013 at 12:04 AM, Carsten Bormann wrote: > In the light of the "real-world examples" thread: > Is "unordered" still entirely true? > i believe so. i have one C-based JSON lib which explicitly leaves the ordering undefined and internally uses insertion order, and another C lib which also leaves it undefined but internally uses reverse-insertion order. Emiting does not change the order. -- ----- stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal --001a11c380b0a156ff04de83903c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, Jun 7, 2013 at 12:04 AM, Carsten Bormann <cabo@tzi.org= > wrote:
In the light of the &= quot;real-world examples" thread:
Is "unordered" still entirely true?

i believe so. i have one C-based JSON lib which explicitly lea= ves the ordering undefined and internally uses insertion order, and another= C lib which also leaves it undefined but internally uses reverse-insertion= order. Emiting does not change the order.

--
----- stephan beal
http://wanderinghorse.net/home= /stephan/
--001a11c380b0a156ff04de83903c-- From cowan@ccil.org Thu Jun 6 15:13:00 2013 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 93D3811E80F8 for ; Thu, 6 Jun 2013 15:13:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.951 X-Spam-Level: X-Spam-Status: No, score=-2.951 tagged_above=-999 required=5 tests=[AWL=0.648, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OisNIPiQsKKX for ; Thu, 6 Jun 2013 15:12:52 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id 1796B11E80AD for ; Thu, 6 Jun 2013 15:12:51 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1UkiQN-00052D-Bh; Thu, 06 Jun 2013 18:12:51 -0400 Date: Thu, 6 Jun 2013 18:12:51 -0400 From: John Cowan To: Stephan Beal Message-ID: <20130606221251.GK3090@mercury.ccil.org> References: <51B0DFB6.10803@crockford.com> <20130606210709.GH3090@mercury.ccil.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Cc: "json@ietf.org" Subject: Re: [Json] Introduction X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 06 Jun 2013 22:13:01 -0000 Stephan Beal scripsit: > Fair enough, but the quotes are very important to the definition of > strings for parsers and emiters. Oh yes. But when you are defining the data model, define the data model; when you are defining the format, define the format. You'll note that the definition of an array does not mention commas or square brackets. By the same token, strings can contain quotation marks, the format for which is \" or one of the alternatives. -- Deshil Holles eamus. Deshil Holles eamus. Deshil Holles eamus. Send us, bright one, light one, Horhorn, quickening, and wombfruit. (3x) Hoopsa, boyaboy, hoopsa! Hoopsa, boyaboy, hoopsa! Hoopsa, boyaboy, hoopsa! --Joyce, Ulysses, "Oxen of the Sun" cowan@ccil.org From jhildebr@cisco.com Thu Jun 6 15:15:27 2013 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 C1D8921E8053 for ; Thu, 6 Jun 2013 15:15:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g6bDfuTYaPx3 for ; Thu, 6 Jun 2013 15:15:22 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 1F8FA21E8056 for ; Thu, 6 Jun 2013 15:15:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=992; q=dns/txt; s=iport; t=1370556922; x=1371766522; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=agaoqDfGsPNEqsu8Ze1eDEDLQUOPo/9Ufu1Bnpfxe/Y=; b=IGtNB1h0fKJR9/MiKdQPIiWI0gf+H5HMQQZptzzTkUKQWmFcVrWYw3UW xRSiupOvECuagIEBu97MxQvwrSLyzZzaETCF0XVuUFox1G9+Dt+QSZ6yO l3otoRSV/MBaxjhwcrfMFtvpz+Mt9p/LfSVJguHrGGhmE+U/ZNqXpKqpr 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgkFABkJsVGtJXG8/2dsb2JhbABZgwkwvm56FnSCJQEEOj8SAQgiFEIlAgQOBQiIBQy7OQSPATECBYJ6YQOof4MPgic X-IronPort-AV: E=Sophos;i="4.87,817,1363132800"; d="scan'208";a="219785328" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-7.cisco.com with ESMTP; 06 Jun 2013 22:15:18 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r56MFIO0016469 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 6 Jun 2013 22:15:18 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.56]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.02.0318.004; Thu, 6 Jun 2013 17:15:18 -0500 From: "Joe Hildebrand (jhildebr)" To: John Cowan Thread-Topic: [Json] The parts of JSON (a possible aid to discussion) Thread-Index: AQHOYvd+smBXbfrsAEGrkWVGGt20lpkpI5eAgABtdoD//57kgA== Date: Thu, 6 Jun 2013 22:15:17 +0000 Message-ID: In-Reply-To: <20130606220249.GJ3090@mercury.ccil.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [10.21.88.234] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Jacob Davies , "json@ietf.org" Subject: Re: [Json] The parts of JSON (a possible aid to discussion) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 06 Jun 2013 22:15:28 -0000 On 6/6/13 4:02 PM, "John Cowan" wrote: >Joe Hildebrand (jhildebr) scripsit: > >> The rest of your message, while probably technically correct, >>effectively >> says we're defining an infoset for JSON. I don't like where that got >>XML, > >Hey, I did the best I could, given vague and ever-changing requirements. I abjectly apologize. I should have actually read the title block on the infoset doc while I had it open. Please don't take my statement as being personal in any way. I understand why we got there, I'm just not sure we want to go all that way on JSON if we can avoid it. >The MicroXML data model is far superior -- and it's represented using >JSON. >See . >You can't go wrong emulating James Clark when it comes to spec-writing. Interesting, I hadn't seen that. Just removing namespaces probably reduced the complexity tremendously. --=20 Joe Hildebrand From cabo@tzi.org Thu Jun 6 15:16:25 2013 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 3610A21E808C for ; Thu, 6 Jun 2013 15:16:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R9dQvgBMwc9W for ; Thu, 6 Jun 2013 15:16:19 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 1919921E8083 for ; Thu, 6 Jun 2013 15:16:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r56MGAbl025724; Fri, 7 Jun 2013 00:16:10 +0200 (CEST) Received: from [192.168.182.246] (unknown [217.111.178.142]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 6C3B53F80; Fri, 7 Jun 2013 00:16:10 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: Date: Fri, 7 Jun 2013 00:16:09 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "Joe Hildebrand (jhildebr)" X-Mailer: Apple Mail (2.1503) Cc: Douglas Crockford , "json@ietf.org" Subject: Re: [Json] Introduction X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 06 Jun 2013 22:16:25 -0000 On Jun 7, 2013, at 00:08, "Joe Hildebrand (jhildebr)" = wrote: >> And should the expectation that the names are unique enter this = overview? >=20 > No. That's an edge case that doesn't belong in the intro. Hmm, the difference between a multimap (which is what the text actually = appears to describe) and a map (which is what JavaScript objects are, = but we don't talk about JavaScript here any more) is way more than an = edge case. Saying it is a multimap and then taking that back later in the document = doesn't sound right. Gr=FC=DFe, Carsten From cowan@ccil.org Thu Jun 6 15:21:46 2013 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 0F10521E805F for ; Thu, 6 Jun 2013 15:21:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.01 X-Spam-Level: X-Spam-Status: No, score=-3.01 tagged_above=-999 required=5 tests=[AWL=0.589, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jyg7kcrcRTrc for ; Thu, 6 Jun 2013 15:21:41 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id C0F6C21E804B for ; Thu, 6 Jun 2013 15:21:35 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1UkiYo-0005pT-QM; Thu, 06 Jun 2013 18:21:34 -0400 Date: Thu, 6 Jun 2013 18:21:34 -0400 From: John Cowan To: "Joe Hildebrand (jhildebr)" Message-ID: <20130606222134.GM3090@mercury.ccil.org> References: <20130606220249.GJ3090@mercury.ccil.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Cc: Jacob Davies , "json@ietf.org" Subject: Re: [Json] The parts of JSON (a possible aid to discussion) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 06 Jun 2013 22:21:46 -0000 Joe Hildebrand (jhildebr) scripsit: > I abjectly apologize. No worries. "I am your brother Joseph." (Actually you're Joseph, but whatever.) > Interesting, I hadn't seen that. Just removing namespaces probably > reduced the complexity tremendously. Oh yes, and DTDs, and many other things. -- Using RELAX NG compact syntax to John Cowan develop schemas is one of the simple http://www.ccil.org/~cowan pleasures in life.... --Jeni Tennison From nico@cryptonector.com Thu Jun 6 15:21:46 2013 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 A220721E804B for ; Thu, 6 Jun 2013 15:21:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QBHDrayWXk6i for ; Thu, 6 Jun 2013 15:21:41 -0700 (PDT) Received: from homiemail-a31.g.dreamhost.com (caiajhbdcaib.dreamhost.com [208.97.132.81]) by ietfa.amsl.com (Postfix) with ESMTP id C78D321E8053 for ; Thu, 6 Jun 2013 15:21:37 -0700 (PDT) Received: from homiemail-a31.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a31.g.dreamhost.com (Postfix) with ESMTP id 9FCE1202022 for ; Thu, 6 Jun 2013 15:21:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=gK85UgsjLJlXmdLY/xKZ uklESx0=; b=h4GrFI/XJfPMqxn7dnQcnqsow6BkP20ZdnRIR6JQjOKPmQwj3Oqo pX8XFcdbHNYSvx8sAvGrbUcy6CGLEu3EMhHe5Dl3R9cdNsQYmObBv3OiViDDPRk2 P3zDpdM1u6dPEWxIWWnFOnf3irn+/X+0vDvfhdyEh+fBK9ozHVKfLj8= Received: from mail-wi0-f179.google.com (mail-wi0-f179.google.com [209.85.212.179]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a31.g.dreamhost.com (Postfix) with ESMTPSA id 4625D202018 for ; Thu, 6 Jun 2013 15:21:36 -0700 (PDT) Received: by mail-wi0-f179.google.com with SMTP id hm9so815403wib.12 for ; Thu, 06 Jun 2013 15:21:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=0f8kwulrAPjJwQbP3IWy213ZXeO30xk/la0V0+1ViJg=; b=co1LH3rYo4zB6Q+KXPEzorivK3oXCKDA3IEidqUb6IU/Yg/lMAt1QIPm3nIW3vaE3J TXkR2Bet+ZXp1jSALWTpDaFhChDlLa7JVwPXLWPpb/bI2JE0bx+qa6hvadLZc2njsxrU E1A2jy2pI81uXTBlNoIr/Q0wlRmHxv+51NzAmIQ4aFWdsCsijfjifyiYJoQ7Mjs9Lmk9 jFIQJvAls2xaDmd8hYboMXBmSsHvgpVR7ALyNDxhgNMt8UW57L0HtJpEtLxlkBUuWyV1 ZDlYEqR06OdsN9gwLfCYzxc6pHdfihQg7SzSEW59GOTZISwFPRnTVtLA1+GTJGnGTz6f WVoQ== MIME-Version: 1.0 X-Received: by 10.181.12.1 with SMTP id em1mr130687wid.4.1370557294572; Thu, 06 Jun 2013 15:21:34 -0700 (PDT) Received: by 10.216.63.136 with HTTP; Thu, 6 Jun 2013 15:21:34 -0700 (PDT) In-Reply-To: <51AF8479.5080002@crockford.com> References: <51AF8479.5080002@crockford.com> Date: Thu, 6 Jun 2013 17:21:34 -0500 Message-ID: From: Nico Williams To: Douglas Crockford Content-Type: text/plain; charset=UTF-8 Cc: "json@ietf.org" Subject: Re: [Json] The names within an object SHOULD be unique. X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 06 Jun 2013 22:21:46 -0000 >From a security point of view disparate handling of ambiguities makes me very uncomfortable. Thinking of encoders that do not have full knowledge of an object as it is encoded, I'm uncomfortable with saying "MUST NOT send duplicate keys", since determining whether a given key has already been sent might require large amounts of state. But note that this concern also applies to parsers! Consider a parser that invokes an application-provided callback/closure with a {path, value} for each value parsed. How can such a parser do anything at all about duplicate keys? At best it could detect (having kept a fair bit of state) duplicate keys. In this case the responsibility for detecting and handling duplicates moves onto the application. The application might be a jq-like filter, in which case there's nothing to do there either and we move the responsibility for handling dups onto the last parser in the pipe. Or there might not be a pipe at all and actions might be taken on the fly. Regarding comments, I thought we'd have to accept that JSON does not have comments, but since there's talk of extensions, and since we could (and many, many parsers do) have options that can default to off (unavailable), we might indeed want to consider a comments option. [*] The thought occurs that when we speak of duplicate keys we mean in the memcmp() (byte-wise) sense. We're specifically not speaking of Unicode equivalence. But depending on whether a *human* must understand object keys (doubtful in production environments) we might have to. Having thought this far, I propose this text: Encoders SHOULD NOT send duplicate keys. Some encoders might not be able to prevent duplicate keys. Therefore parsers MUST be prepared to handle duplicate keys. Stateful parsers MUST accept [use?] only the last of any set of duplicate keys. Some parsers might not be able to detect duplicate keys, much less pick only the last of them. Here a "stateful parser" is one that keeps on hand all of the values it decodes, as it decodes them. Note that accepting duplicate keys presents potential security risks. Note that sending duplicate keys risks data loss (that is, the loss of all but the last of a duplicated key's values). For the purposes of the above discussion, two or more keys in the same object are duplicates of each other if, when expressed as a sequence of code units, they are byte-wise equivalent. Nico -- From mamille2@cisco.com Thu Jun 6 15:26:32 2013 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 62E7E11E80D7 for ; Thu, 6 Jun 2013 15:26:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jJQe0ACS7YkK for ; Thu, 6 Jun 2013 15:26:26 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id B00F421F9948 for ; Thu, 6 Jun 2013 15:26:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7170; q=dns/txt; s=iport; t=1370557586; x=1371767186; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=olJZXPTyXfKBO0O4IgwMR5zmk5pbF0mLg2baudHeASc=; b=D4xbCu+S5ztOJqZyuJnAmaaRL7g7ZbLtgEPJfhueoKYPyFZIjo02K7Mv crXthRsHo+hUO6nJ9aeQ7yM98gworTcm8UxdLZFv8j2Vn30viuZsDgmJ2 /dOrQd73GNk1dc5lg7n2Gv6Ha65SC4j1WZdJHEKMOayEBjpdmZgHcgJjB 4=; X-Files: smime.p7s : 4136 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AggFAKULsVGtJXHA/2dsb2JhbABZgwm/HnoWdIIjAQEBAwF5BQsCAQgOCgokAjAlAgQOBQgGh3kGu0ePATEHgnphA5AAgSyXU4MPgic X-IronPort-AV: E=Sophos;i="4.87,817,1363132800"; d="p7s'?scan'208";a="219793580" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-8.cisco.com with ESMTP; 06 Jun 2013 22:26:26 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r56MQQC9013454 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 6 Jun 2013 22:26:26 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.24]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.02.0318.004; Thu, 6 Jun 2013 17:26:26 -0500 From: "Matt Miller (mamille2)" To: Carsten Bormann Thread-Topic: [Json] Introduction Thread-Index: AQHOYuozBqrUSJOZ7kCTR5ofVC4gzJkpkX2AgAABIgCAAAJCgIAAAt0A Date: Thu, 6 Jun 2013 22:26:24 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.129.24.59] Content-Type: multipart/signed; boundary="Apple-Mail=_6E5534A6-0BCE-482C-A92A-5B9011983443"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Cc: Douglas Crockford , "Joe Hildebrand \(jhildebr\)" , "json@ietf.org" Subject: Re: [Json] Introduction X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 06 Jun 2013 22:26:32 -0000 --Apple-Mail=_6E5534A6-0BCE-482C-A92A-5B9011983443 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On Jun 6, 2013, at 4:16 PM, Carsten Bormann wrote: > On Jun 7, 2013, at 00:08, "Joe Hildebrand (jhildebr)" = wrote: >=20 >>> And should the expectation that the names are unique enter this = overview? >>=20 >> No. That's an edge case that doesn't belong in the intro. >=20 > Hmm, the difference between a multimap (which is what the text = actually appears to describe) and a map (which is what JavaScript = objects are, but we don't talk about JavaScript here any more) is way = more than an edge case. >=20 > Saying it is a multimap and then taking that back later in the = document doesn't sound right. >=20 /me doffs hat I don't interpret the suggested intro text to describe a multimap, but = my biases are different. Not sure this helps but what about: #### An object is an unordered collection of zero or more unique name/value = pairs, where a name is a string and a value is a string, number, = boolean, null, object, or array.=20 #### - m&m Matt Miller < mamille2@cisco.com > Cisco Systems, Inc. --Apple-Mail=_6E5534A6-0BCE-482C-A92A-5B9011983443 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMezCCBjQw ggQcoAMCAQICAR4wDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDE1NVoX DTE3MTAyNDIxMDE1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMcJg8zOLdgasSmkLhOrlr6KMoOMpohBllVHrdRvEg/q6r8jR+EK 75xCGhR8ToREoqe7zM9/UnC6TS2y9UKTpT1v7RSMzR0t6ndl0TWBuUr/UXBhPk+Kmy7bI4yW4urC +y7P3/1/X7U8ocb8VpH/Clt+4iq7nirMcNh6qJR+xjOhV+VHzQMALuGYn5KZmc1NbJQYclsGkDxD z2UbFqE2+6vIZoL+jb9x4Pa5gNf1TwSDkOkikZB1xtB4ZqtXThaABSONdfmv/Z1pua3FYxnCFmdr /+N2JLKutIxMYqQOJebr/f/h5t95m4JgrM3Y/w7YX9d7YAL9jvN4SydHsU6n65cCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRTcu2SnODaywFc fH6WNU7y1LhRgjAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBAAqDCH14qywG XLhjjF6uHLkjd02hcdh9hrw+VUsv+q1eeQWB21jWj3kJ96AUlPCoEGZ/ynJNScWy6QMVQjbbMXlt UfO4n4bGGdKo3awPWp61tjAFgraLJgDk+DsSvUD6EowjMTNx25GQgyYJ5RPIzKKR9tQW8gGK+2+R HxkUCTbYFnL6kl8Ch507rUdPPipJ9CgJFws3kDS3gOS5WFMxcjO5DwKfKSETEPrHh7p5shuuNktv sv6hxHTLhiMKX893gxdT3XLS9OKmCv87vkINQcNEcIIoFWbP9HORz9v3vQwR4e3ksLc2JZOAFK+s sS5XMEoznzpihEP0PLc4dCBYjbvSD7kxgDwZ+Aj8Q9PkbvE9sIPP7ON0fz095HdThKjiVJe6vofq +n6b1NBc8XdrQvBmunwxD5nvtTW4vtN6VY7mUCmxsCieuoBJ9OlqmsVWQvifIYf40dJPZkk9YgGT zWLpXDSfLSplbY2LL9C9U0ptvjcDjefLTvqSFc7tw1sEhF0n/qpA2r0GpvkLRDmcSwVyPvmjFBGq Up/pNy8ZuPGQmHwFi2/14+xeSUDG2bwnsYJQG2EdJCB6luQ57GEnTA/yKZSTKI8dDQa8Sd3zfXb1 9mOgSF0bBdXbuKhEpuP9wirslFe6fQ1t5j5R0xi72MZ8ikMu1RQZKCyDbMwazlHiMIIGPzCCBSeg AwIBAgIDBoRIMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcN MTMwNDMwMjE1NDQyWhcNMTQwNTAyMDUzOTA0WjBbMRkwFwYDVQQNExBiN2F6NndOY0t0R3JtMEpF MRswGQYDVQQDDBJtYW1pbGxlMkBjaXNjby5jb20xITAfBgkqhkiG9w0BCQEWEm1hbWlsbGUyQGNp c2NvLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJbKBMsG+9UFTx9uq/bhhXgu vJvO8z7cwKaqqwZhVf5z/kHFyCNijtmTOE+YXjA8mWR4aoBwB5SvGypI/cJUofJ+AlBTC4g+RMx/ K0Ab4/jQqTQz9CDzMOB+Wm+rt8ZJ7A8ZzOJmNDAsf/VvB8l2A1SQz1UsAixgH16NTr8SlblAXEKk 4hwpCudUiNjjQokqJ0H686UBKVorcZSgXaza8XMqGtJF/8mNhR9GQYi7Xht1ky+9LFOrto2daZto KJRwMeVusVdHUeKEQSu7jztw8HchH3KEb7Q+r5X+hhDZoddfKE8d5eyPuhiZdrzv7OlNZ0fSLdx7 3AE3nx9/R5YlXucCAwEAAaOCAtgwggLUMAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQW MBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQUxGd+/qrdVudHrIKkw5xOMY7eaLUwHwYD VR0jBBgwFoAUU3Ltkpzg2ssBXHx+ljVO8tS4UYIwHQYDVR0RBBYwFIESbWFtaWxsZTJAY2lzY28u Y29tMIIBTAYDVR0gBIIBQzCCAT8wggE7BgsrBgEEAYG1NwECAzCCASowLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0 Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBp c3N1ZWQgYWNjb3JkaW5nIHRvIHRoZSBDbGFzcyAxIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9m IHRoZSBTdGFydENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBw dXJwb3NlIGluIGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMDYG A1UdHwQvMC0wK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUxLWNybC5jcmwwgY4G CCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIv Y2xhc3MxL2NsaWVudC9jYTBCBggrBgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2Vy dHMvc3ViLmNsYXNzMS5jbGllbnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRz c2wuY29tLzANBgkqhkiG9w0BAQUFAAOCAQEAlDhXbGEI7lbqUcu5r2JHZaMsbRZda/99ZqODzWGX 0llou9jGccsAWDPPwRRe2+ROpXfH4cuJZElTcLDeZSp/qpXKhjYieFSX8+Ml9sKEj5UOSqQLyoLk PtrIJV12Jk3nuG2Jc0UeEnGwK/aqtzy7+bfEVI0ziyVM2gChHh0RH74KyiwYWknbOTRIkZcz/ulE DVFQp63uj6wfmDNvAUHBAdhKVqA1S/rfP1KcDZpf1NfvwXJibiqTRA6K1EOxTJOP41n/XdvHqHXL RWL2xrOUI9/URANr/ok3OrsuZEMFnAAGefS1bWS/hFtUGVkHGiKEBbyDW7da2ULXbuC7umrQnzGC A28wggNrAgEBMIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkG A1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwaESDAJBgUrDgMCGgUA oIIBrzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMzA2MDYyMjI2 MjRaMCMGCSqGSIb3DQEJBDEWBBRvRVMTqpMEiZT/fDH7xKaK1vkiqTCBpQYJKwYBBAGCNxAEMYGX MIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3Mg MSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwaESDCBpwYLKoZIhvcNAQkQAgsxgZeg gZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1 cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAx IFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDBoRIMA0GCSqGSIb3DQEBAQUABIIBABbQ W2hRC/cOLPqVkGzf1ioSMGPezk/0m7Vcd+RlzEw+mInOJUQFAJbw27LrLcou/95G/wvweemp6l97 NPeKvY0iAq0/FTdEafD/wkZI51bcuzaRZp1USqbmeawgkEuALfBKQOuPG5mTjfExCIO+KuMrmijs Cx2MK3p0tbzjLIIZOjJbhglTk8gO/qB0awrqnI5Oi0PxAkWxbdAX+/fNvHNAIHIE6rdCHyUJAgZ3 R6eLuVcc3IVpZ8cWLltMKP0Pvdmx+OfPbCdtuMPHLqIGzuU1oLqRQ1T7rptyK8q9pwce3sRKFxyp 3lXdQzk4zGOi8jwCivv1q4gFm0PQ4q+8ndsAAAAAAAA= --Apple-Mail=_6E5534A6-0BCE-482C-A92A-5B9011983443-- From nico@cryptonector.com Thu Jun 6 15:32:29 2013 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 C09F921F962A for ; Thu, 6 Jun 2013 15:32:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qrY2VcNVVe8o for ; Thu, 6 Jun 2013 15:32:13 -0700 (PDT) Received: from homiemail-a30.g.dreamhost.com (caiajhbdccac.dreamhost.com [208.97.132.202]) by ietfa.amsl.com (Postfix) with ESMTP id D4EDF21F9424 for ; Thu, 6 Jun 2013 15:32:12 -0700 (PDT) Received: from homiemail-a30.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a30.g.dreamhost.com (Postfix) with ESMTP id C896721DE7D for ; Thu, 6 Jun 2013 15:32:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=plaqhp2TLfXBRv3NYg0W hX8+98g=; b=RT6dcWv3X5IEEXBA4QB//maM0RIUgkU47r1ZC5KorEP0U5jdYWkG AXK/XXO/kOg+MoSNybvMRI+fYviWsxDFKcLsbvk4VDlV5yIulKvhaWMiUaXkptUM DHGKqmTW0bxDS/HzewfcaVq8j+JcZ4UJApGSCycNrXwvMehafWL1ifg= Received: from mail-wg0-f45.google.com (mail-wg0-f45.google.com [74.125.82.45]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a30.g.dreamhost.com (Postfix) with ESMTPSA id 5D61B21DE6F for ; Thu, 6 Jun 2013 15:32:10 -0700 (PDT) Received: by mail-wg0-f45.google.com with SMTP id n12so2562493wgh.0 for ; Thu, 06 Jun 2013 15:32:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=y2SgDwrpHizVy/lNeGpecB1EmWOUHWuZdM/jw+Mg8WM=; b=K1J1jxJoNSk+P6s7eA0VKWyjTwoQtWrABljSxnCbAxIsOU6SXNNaLS2jVD5DCthK2X 333raQ6N/nBVbL13SAHFnkdCCNM67YVycQzmND6LPVUfmDgEUyoFNzM/k8/0Di6UTWVd edUJjAwn4xGsGeML2J4CwQO1n92Jc9KD8+8BhmI7MTg3/0yfffGuq/0v7ludGEGGXddW pSQkhJuLwQT0gztHy88NaxhV9sFI1pDB3l5MUQkfBAjWBnhxyOhGksNty9N1xqtArX0/ RLzeMI/oQmZ/KWrdalUV8rPfxNC9WIdy57506Z46nfUle8Weq/l6dMSgazP2wP6kH/13 mXVg== MIME-Version: 1.0 X-Received: by 10.181.12.1 with SMTP id em1mr151114wid.4.1370557928225; Thu, 06 Jun 2013 15:32:08 -0700 (PDT) Received: by 10.216.63.136 with HTTP; Thu, 6 Jun 2013 15:32:08 -0700 (PDT) In-Reply-To: References: Date: Thu, 6 Jun 2013 17:32:08 -0500 Message-ID: From: Nico Williams To: Paul Hoffman Content-Type: text/plain; charset=UTF-8 Cc: "json@ietf.org" Subject: Re: [Json] Call for real-world examples of how parsers deal with duplicate keys X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 06 Jun 2013 22:32:32 -0000 On Thu, Jun 6, 2013 at 12:41 PM, Paul Hoffman wrote: > {"a":1,"a":2} jq 1.3 returns 2: % echo '{"a":1,"a":2}'|./jq '.a' 2 % Heimdal's parser takes the last value as well (from code inspection). Nico -- From mamille2@cisco.com Thu Jun 6 15:33:51 2013 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 AF3F321F99A8 for ; Thu, 6 Jun 2013 15:33:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oQW3O68YoL6Z for ; Thu, 6 Jun 2013 15:33:45 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 795D121F9424 for ; Thu, 6 Jun 2013 15:33:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9570; q=dns/txt; s=iport; t=1370558025; x=1371767625; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Jexqu3eQNRIej0guEf/BMZQlIYnwl8M9P2pPHx++B7Y=; b=cuQ1Xqd1w3SSBSvrfPlaBYmON8qoeCeVCWYAxJvQkhmskneUTaKYGmJt /y5G+oD+qI7Br4s1Y1uBXGhbOAJEKx551N52qswIRSmroSm4yL60DC1Tj UNgw6MOfzVX3zJP1HpIC14ikFuSplcc9MkESQaMcsCMfUyKi6UOWBSTfN k=; X-Files: smime.p7s : 4136 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAJkNsVGtJV2a/2dsb2JhbABZgwm/IHoWdIIjAQEBAwF5BQsCAQgiJAIwJQIEDgUIBod5BrtIjwExB4J6YQOQAIEsl1ODD4In X-IronPort-AV: E=Sophos;i="4.87,817,1363132800"; d="p7s'?scan'208";a="219884013" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-4.cisco.com with ESMTP; 06 Jun 2013 22:33:45 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r56MXiT2003437 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 6 Jun 2013 22:33:44 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.24]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.02.0318.004; Thu, 6 Jun 2013 17:33:44 -0500 From: "Matt Miller (mamille2)" To: Nico Williams Thread-Topic: [Json] The names within an object SHOULD be unique. Thread-Index: AQHOYhtyBSnxVkBEbkeV6bO5MJr11ZkpmAIAgAADZgA= Date: Thu, 6 Jun 2013 22:33:44 +0000 Message-ID: References: <51AF8479.5080002@crockford.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.129.24.59] Content-Type: multipart/signed; boundary="Apple-Mail=_1C956554-E340-4582-B470-599922587ECE"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Cc: Douglas Crockford , "json@ietf.org" Subject: Re: [Json] The names within an object SHOULD be unique. X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 06 Jun 2013 22:33:52 -0000 --Apple-Mail=_1C956554-E340-4582-B470-599922587ECE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii /me doffs hat inline ... On Jun 6, 2013, at 4:21 PM, Nico Williams wrote: > =46rom a security point of view disparate handling of ambiguities = makes > me very uncomfortable. >=20 > Thinking of encoders that do not have full knowledge of an object as > it is encoded, I'm uncomfortable with saying "MUST NOT send duplicate > keys", since determining whether a given key has already been sent > might require large amounts of state. But note that this concern also > applies to parsers! >=20 > Consider a parser that invokes an application-provided > callback/closure with a {path, value} for each value parsed. How can > such a parser do anything at all about duplicate keys? At best it > could detect (having kept a fair bit of state) duplicate keys. In > this case the responsibility for detecting and handling duplicates > moves onto the application. The application might be a jq-like > filter, in which case there's nothing to do there either and we move > the responsibility for handling dups onto the last parser in the pipe. > Or there might not be a pipe at all and actions might be taken on the > fly. >=20 > Regarding comments, I thought we'd have to accept that JSON does not > have comments, but since there's talk of extensions, and since we > could (and many, many parsers do) have options that can default to off > (unavailable), we might indeed want to consider a comments option. >=20 > [*] The thought occurs that when we speak of duplicate keys we mean in > the memcmp() (byte-wise) sense. We're specifically not speaking of > Unicode equivalence. But depending on whether a *human* must > understand object keys (doubtful in production environments) we might > have to. >=20 > Having thought this far, I propose this text: >=20 Note that so far, the document uses the term "name", not "key". I think = the following needs to substitute "key" with "name" to be consistent. > Encoders SHOULD NOT send duplicate keys. Some encoders might not > be able to prevent duplicate keys. Therefore parsers MUST be prepared > to handle duplicate keys. >=20 > Stateful parsers MUST accept [use?] only the last of any set of > duplicate keys. >=20 I think this still needs to allow for stateful parsers that reject = duplicate keys (for which there are some). Maybe: #### Stateful parsers MAY reject duplicate names. However, if duplicate names = are accepted, it MUST accept only the last value of any set of duplicate = names. #### > Some parsers might not be able to detect duplicate keys, much less > pick only the last of them. Here a "stateful parser" is one that > keeps on hand all of the values it decodes, as it decodes them. Note > that accepting duplicate keys presents potential security risks. Note > that sending duplicate keys risks data loss (that is, the loss of all > but the last of a duplicated key's values). >=20 Can we describe a couple of specific security risks that are incurred? = I think one would be something like overwriting of the original value by = an attacker intercepting the exchange. > For the purposes of the above discussion, two or more keys in the > same object are duplicates of each other if, when expressed as a > sequence of code units, they are byte-wise equivalent. >=20 Other than the suggestions above, I think it's rather good. - m&m Matt Miller < mamille2@cisco.com > Cisco Systems, Inc. --Apple-Mail=_1C956554-E340-4582-B470-599922587ECE Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMezCCBjQw ggQcoAMCAQICAR4wDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDE1NVoX DTE3MTAyNDIxMDE1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMcJg8zOLdgasSmkLhOrlr6KMoOMpohBllVHrdRvEg/q6r8jR+EK 75xCGhR8ToREoqe7zM9/UnC6TS2y9UKTpT1v7RSMzR0t6ndl0TWBuUr/UXBhPk+Kmy7bI4yW4urC +y7P3/1/X7U8ocb8VpH/Clt+4iq7nirMcNh6qJR+xjOhV+VHzQMALuGYn5KZmc1NbJQYclsGkDxD z2UbFqE2+6vIZoL+jb9x4Pa5gNf1TwSDkOkikZB1xtB4ZqtXThaABSONdfmv/Z1pua3FYxnCFmdr /+N2JLKutIxMYqQOJebr/f/h5t95m4JgrM3Y/w7YX9d7YAL9jvN4SydHsU6n65cCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRTcu2SnODaywFc fH6WNU7y1LhRgjAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBAAqDCH14qywG XLhjjF6uHLkjd02hcdh9hrw+VUsv+q1eeQWB21jWj3kJ96AUlPCoEGZ/ynJNScWy6QMVQjbbMXlt UfO4n4bGGdKo3awPWp61tjAFgraLJgDk+DsSvUD6EowjMTNx25GQgyYJ5RPIzKKR9tQW8gGK+2+R HxkUCTbYFnL6kl8Ch507rUdPPipJ9CgJFws3kDS3gOS5WFMxcjO5DwKfKSETEPrHh7p5shuuNktv sv6hxHTLhiMKX893gxdT3XLS9OKmCv87vkINQcNEcIIoFWbP9HORz9v3vQwR4e3ksLc2JZOAFK+s sS5XMEoznzpihEP0PLc4dCBYjbvSD7kxgDwZ+Aj8Q9PkbvE9sIPP7ON0fz095HdThKjiVJe6vofq +n6b1NBc8XdrQvBmunwxD5nvtTW4vtN6VY7mUCmxsCieuoBJ9OlqmsVWQvifIYf40dJPZkk9YgGT zWLpXDSfLSplbY2LL9C9U0ptvjcDjefLTvqSFc7tw1sEhF0n/qpA2r0GpvkLRDmcSwVyPvmjFBGq Up/pNy8ZuPGQmHwFi2/14+xeSUDG2bwnsYJQG2EdJCB6luQ57GEnTA/yKZSTKI8dDQa8Sd3zfXb1 9mOgSF0bBdXbuKhEpuP9wirslFe6fQ1t5j5R0xi72MZ8ikMu1RQZKCyDbMwazlHiMIIGPzCCBSeg AwIBAgIDBoRIMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcN MTMwNDMwMjE1NDQyWhcNMTQwNTAyMDUzOTA0WjBbMRkwFwYDVQQNExBiN2F6NndOY0t0R3JtMEpF MRswGQYDVQQDDBJtYW1pbGxlMkBjaXNjby5jb20xITAfBgkqhkiG9w0BCQEWEm1hbWlsbGUyQGNp c2NvLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJbKBMsG+9UFTx9uq/bhhXgu vJvO8z7cwKaqqwZhVf5z/kHFyCNijtmTOE+YXjA8mWR4aoBwB5SvGypI/cJUofJ+AlBTC4g+RMx/ K0Ab4/jQqTQz9CDzMOB+Wm+rt8ZJ7A8ZzOJmNDAsf/VvB8l2A1SQz1UsAixgH16NTr8SlblAXEKk 4hwpCudUiNjjQokqJ0H686UBKVorcZSgXaza8XMqGtJF/8mNhR9GQYi7Xht1ky+9LFOrto2daZto KJRwMeVusVdHUeKEQSu7jztw8HchH3KEb7Q+r5X+hhDZoddfKE8d5eyPuhiZdrzv7OlNZ0fSLdx7 3AE3nx9/R5YlXucCAwEAAaOCAtgwggLUMAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQW MBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQUxGd+/qrdVudHrIKkw5xOMY7eaLUwHwYD VR0jBBgwFoAUU3Ltkpzg2ssBXHx+ljVO8tS4UYIwHQYDVR0RBBYwFIESbWFtaWxsZTJAY2lzY28u Y29tMIIBTAYDVR0gBIIBQzCCAT8wggE7BgsrBgEEAYG1NwECAzCCASowLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0 Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBp c3N1ZWQgYWNjb3JkaW5nIHRvIHRoZSBDbGFzcyAxIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9m IHRoZSBTdGFydENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBw dXJwb3NlIGluIGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMDYG A1UdHwQvMC0wK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUxLWNybC5jcmwwgY4G CCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIv Y2xhc3MxL2NsaWVudC9jYTBCBggrBgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2Vy dHMvc3ViLmNsYXNzMS5jbGllbnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRz c2wuY29tLzANBgkqhkiG9w0BAQUFAAOCAQEAlDhXbGEI7lbqUcu5r2JHZaMsbRZda/99ZqODzWGX 0llou9jGccsAWDPPwRRe2+ROpXfH4cuJZElTcLDeZSp/qpXKhjYieFSX8+Ml9sKEj5UOSqQLyoLk PtrIJV12Jk3nuG2Jc0UeEnGwK/aqtzy7+bfEVI0ziyVM2gChHh0RH74KyiwYWknbOTRIkZcz/ulE DVFQp63uj6wfmDNvAUHBAdhKVqA1S/rfP1KcDZpf1NfvwXJibiqTRA6K1EOxTJOP41n/XdvHqHXL RWL2xrOUI9/URANr/ok3OrsuZEMFnAAGefS1bWS/hFtUGVkHGiKEBbyDW7da2ULXbuC7umrQnzGC A28wggNrAgEBMIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkG A1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwaESDAJBgUrDgMCGgUA oIIBrzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMzA2MDYyMjMz NDRaMCMGCSqGSIb3DQEJBDEWBBQlKNB16kWz2sxNLVLWIJ21cCqgITCBpQYJKwYBBAGCNxAEMYGX MIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3Mg MSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwaESDCBpwYLKoZIhvcNAQkQAgsxgZeg gZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1 cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAx IFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDBoRIMA0GCSqGSIb3DQEBAQUABIIBAC/I i16CaLlebprxomRF7l5r1N5ANA5OD5KWaqc7uxdgAh0+Fuh9qk9+cxTLdxeB7cAMomz4aP9xIwQ4 cnMDjYO4BPqVvUPHQIC8Rr4NkNDosatZ0xf98DxS4jdCOx+6CIXEVdlO/O0xSgFA42DuPlidsdU1 Jas2nrx7UNQ4oexeLopBj3ReZyJpD1R6ZmbIOOnLKKMmnJWirXKUCHUYvaP5s5ywh6b6bfSU/5/Y l/NaB21DvRlxP1Ez0wp0oL0D1yhVcajtqg3SWut5oIg6/u7+9vpQpnriImkw8PDgMlzThI6ts7EU YWI9S6s5yIkFTeExvbPSGmFUczbZ6JIYoOkAAAAAAAA= --Apple-Mail=_1C956554-E340-4582-B470-599922587ECE-- From nico@cryptonector.com Thu Jun 6 15:35:10 2013 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 6F2E921F99AB for ; Thu, 6 Jun 2013 15:35:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cLmKoQMAOjtZ for ; Thu, 6 Jun 2013 15:35:04 -0700 (PDT) Received: from homiemail-a67.g.dreamhost.com (mailbigip.dreamhost.com [208.97.132.5]) by ietfa.amsl.com (Postfix) with ESMTP id AC3CA21F8956 for ; Thu, 6 Jun 2013 15:35:04 -0700 (PDT) Received: from homiemail-a67.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a67.g.dreamhost.com (Postfix) with ESMTP id 664D327BC061 for ; Thu, 6 Jun 2013 15:35:04 -0700 (PDT) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a67.g.dreamhost.com (Postfix) with ESMTPSA id 123F027BC05D for ; Thu, 6 Jun 2013 15:35:03 -0700 (PDT) Received: by mail-we0-f182.google.com with SMTP id p60so850453wes.27 for ; Thu, 06 Jun 2013 15:35:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=xPdAPxVw4j6DD5WPZ6HU5GjQR+A3eTP8KBdIwUwgbhc=; b=DZy15LDrbGTQBxmJ5BTBaAKztEGlPr57KgLBEOiQcnWxhYRZvRzbR8Nbq23xUNjU4Y FyGZF9pwdagtVYVz0y82DMJRQb9PzvzfH5DjV+LbkA4+PDQbKcTmeMsfpQQddhzd2ILK NHsU+Ph5HADX8M722f6+5iJIznWALkbkdWKy4cXmLSNk5MMRJbhA1Jc6eW6ngJ88BV/g gSKg+vjqavL5p+WkCjBVWbz/rYZyaZts1krZsHCeQHHzodAeV4pUvLtNt6QiOXrQnpTP g6iSQNF+M0N3ujdwZqn++bRY3qPC1RSDcSvL6K6UIWHLkWtQn48CF3lLyyD2o7X9sj27 N8tA== MIME-Version: 1.0 X-Received: by 10.194.79.74 with SMTP id h10mr2423775wjx.84.1370558102860; Thu, 06 Jun 2013 15:35:02 -0700 (PDT) Received: by 10.216.63.136 with HTTP; Thu, 6 Jun 2013 15:35:02 -0700 (PDT) In-Reply-To: References: Date: Thu, 6 Jun 2013 17:35:02 -0500 Message-ID: From: Nico Williams To: Tatu Saloranta Content-Type: text/plain; charset=UTF-8 Cc: Paul Hoffman , "json@ietf.org" Subject: Re: [Json] Call for real-world examples of how parsers deal with duplicate keys X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 06 Jun 2013 22:35:10 -0000 On Thu, Jun 6, 2013 at 2:37 PM, Tatu Saloranta wrote: > On Java, Jackson library: > > - Exposes both entries (key/value pairs) at streaming parsing level I don't think we should disqualify that sort of streaming parser implementation. This leads me to conclude that we should distinguish between streaming and stateful parsers (my terms; please suggest better ones). Stateful parsers MUST accept only the last value, while streaming parsers MAY (and probably always will) accept all duplicate keys' values. Nico -- From cowan@ccil.org Thu Jun 6 15:37:31 2013 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 8122F21F938E for ; Thu, 6 Jun 2013 15:37:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.059 X-Spam-Level: X-Spam-Status: No, score=-3.059 tagged_above=-999 required=5 tests=[AWL=0.540, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bPFCycl-3tjB for ; Thu, 6 Jun 2013 15:37:14 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id 0353221F8F4A for ; Thu, 6 Jun 2013 15:37:13 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1Ukinv-0007Ru-KL; Thu, 06 Jun 2013 18:37:11 -0400 Date: Thu, 6 Jun 2013 18:37:11 -0400 From: John Cowan To: Nico Williams Message-ID: <20130606223711.GN3090@mercury.ccil.org> References: <51AF8479.5080002@crockford.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Cc: Douglas Crockford , "json@ietf.org" Subject: Re: [Json] The names within an object SHOULD be unique. X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 06 Jun 2013 22:37:31 -0000 Nico Williams scripsit: > Thinking of encoders that do not have full knowledge of an object as > it is encoded, I'm uncomfortable with saying "MUST NOT send duplicate > keys", since determining whether a given key has already been sent > might require large amounts of state. But note that this concern also > applies to parsers! The amount of state can be reduced probabilistically by storing hashes of the values rather than the values themselves. -- Kill Gorgun! Kill orc-folk! John Cowan No other words please Wild Men. cowan@ccil.org Drive away bad air and darkness http://www.ccil.org/~cowan with bright iron! --Ghan-buri-Ghan http://www.ccil.org/~cowan From nico@cryptonector.com Thu Jun 6 15:44:13 2013 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 9659921F99EC for ; Thu, 6 Jun 2013 15:44:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lp5ly2Dhywel for ; Thu, 6 Jun 2013 15:44:08 -0700 (PDT) Received: from homiemail-a98.g.dreamhost.com (caiajhbdcbbj.dreamhost.com [208.97.132.119]) by ietfa.amsl.com (Postfix) with ESMTP id A7DA321F99E9 for ; Thu, 6 Jun 2013 15:44:06 -0700 (PDT) Received: from homiemail-a98.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a98.g.dreamhost.com (Postfix) with ESMTP id 6300B2C206E for ; Thu, 6 Jun 2013 15:44:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=brTTKr/yE7rqNZVya9Hq 1KVnDbc=; b=bV9quY/sO1j3Y+XKkD8g33YYVP5tmGHaj/BM+ISROOvcapO1vTgD XuV+yUOgOMkVUiOj25JiB9oC/dc/Qiw4etE4pAqSEOJdmBUIv93JPLPv3vGwPj4p elA8Mo5SyxZaX6pgtMfEL3HPSQ+fBHynkXoAURNkp/JyRpC1awtKEv8= Received: from mail-we0-f171.google.com (mail-we0-f171.google.com [74.125.82.171]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a98.g.dreamhost.com (Postfix) with ESMTPSA id 11EB12C2059 for ; Thu, 6 Jun 2013 15:44:05 -0700 (PDT) Received: by mail-we0-f171.google.com with SMTP id m46so2551706wev.16 for ; Thu, 06 Jun 2013 15:44:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=EueSDYSe102qYtKflL/TkUrkWKVMGVrdhY21vB0s+CQ=; b=deQP0HkXKIJ8iR+gpkm6yf5F9Nk7gTIzrgUzkO2drTCPfa9ijwdCpw1ltuO3vp8Lvv 2KizvdLAiHFO6zVntTtRSx0LuAKXVxYPvjuYnsWDrzM1YOn+qNpcQWYN41WZ1CNnj8Et 8kZ+gNe6gqLD6t1n+Zogg41IAlDmrnNZf0PJew5or/cTw+/oqyQX7s20NRa+uViAAwT0 j09M1y1+c1vH/UorRlrdgp4Z3W3GnJioBXKwbHT/jdBfmr0zlLhfiCmlqBIgZFPvd2S5 L2kzGS9FJ4Jj8hIGTM7BGqrm75FiG5YoElfw8RvjpZ8rW/54ATE1BZg3ZX4mW62zafBU Wgiw== MIME-Version: 1.0 X-Received: by 10.181.12.1 with SMTP id em1mr173974wid.4.1370558644820; Thu, 06 Jun 2013 15:44:04 -0700 (PDT) Received: by 10.216.63.136 with HTTP; Thu, 6 Jun 2013 15:44:04 -0700 (PDT) In-Reply-To: <20130606223711.GN3090@mercury.ccil.org> References: <51AF8479.5080002@crockford.com> <20130606223711.GN3090@mercury.ccil.org> Date: Thu, 6 Jun 2013 17:44:04 -0500 Message-ID: From: Nico Williams To: John Cowan Content-Type: text/plain; charset=UTF-8 Cc: Douglas Crockford , "json@ietf.org" Subject: Re: [Json] The names within an object SHOULD be unique. X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 06 Jun 2013 22:44:14 -0000 On Thu, Jun 6, 2013 at 5:37 PM, John Cowan wrote: > Nico Williams scripsit: > >> Thinking of encoders that do not have full knowledge of an object as >> it is encoded, I'm uncomfortable with saying "MUST NOT send duplicate >> keys", since determining whether a given key has already been sent >> might require large amounts of state. But note that this concern also >> applies to parsers! > > The amount of state can be reduced probabilistically by storing hashes > of the values rather than the values themselves. Or a refinement: Bloom filters. But I don't think that's a good idea. For one the parser would still have to grow the filter (with adaptable Bloom filters) as it gets too big. For another, we have the risk of false positives. Finally, such a parser could at best produce an error on [suspected] duplicate key (excuse me, name) usage -- it could not prevent the *first* value from being used, and if the consumer has already taken some action based on the first value then we suddenly have a conflict vis-a-vis parsers that accept only the last value. I'd rather accept that streaming parsers can do nothing about duplicate names. Nico -- From jsontest@yahoo.com Thu Jun 6 15:44:50 2013 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 A981B21F8F0E for ; Thu, 6 Jun 2013 15:44:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.286 X-Spam-Level: X-Spam-Status: No, score=0.286 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DX4PzG3ZOzc3 for ; Thu, 6 Jun 2013 15:44:45 -0700 (PDT) Received: from nm41-vm3.bullet.mail.bf1.yahoo.com (nm41-vm3.bullet.mail.bf1.yahoo.com [216.109.114.158]) by ietfa.amsl.com (Postfix) with ESMTP id AA6A921F9989 for ; Thu, 6 Jun 2013 15:44:44 -0700 (PDT) Received: from [98.139.212.148] by nm41.bullet.mail.bf1.yahoo.com with NNFMP; 06 Jun 2013 22:44:44 -0000 Received: from [98.139.213.1] by tm5.bullet.mail.bf1.yahoo.com with NNFMP; 06 Jun 2013 22:44:44 -0000 Received: from [127.0.0.1] by smtp101.mail.bf1.yahoo.com with NNFMP; 06 Jun 2013 22:44:44 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1370558684; bh=DDKXgx41ERoKXVeGofwVOmfuo5Sm2ZtQdOoNSdSiGBw=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:References:In-Reply-To:Mime-Version:Content-Transfer-Encoding:Content-Type:Message-Id:Cc:X-Mailer:From:Subject:Date:To; b=j4YElThGT5SfVwx9BHsNuz055g0DJZWDa6KePbmOMVeecM54JeVSfL5JLGsndT2kogXtzx9yfu2suYzpvxN0zgDGG3pRDJP7LdUYfGAmJVDUCU+SuMduDfBW6kfj4abEcysCnv0RDiGJvTrtnixMHUeNPr7/njIvFWd2WYDHIz8= X-Yahoo-Newman-Id: 38191.99401.bm@smtp101.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: 8j0X_iQVM1k_yCE8EnXNjnj.c.dqRIXe9t54KFhMJFR5qB7 E1CB3wIiXHrwsJWYl9Xfi1FGq2XGt_6ST3Hhst5jrfw4MGoXYp_v2czLCFiB W8D2g6soZDxXnw_vmg5Mvj5ra8LBvSobsMnBHocAybYqZIihZc2BkG.vyDZe 8UbIbYmT25QAj0xNjM6p7UI8xRgIwbGHkKXklXKwTRxQtyzHl.WhngmjU0VA 6CskPXgN7fDJitN31c4mF_4nWRqXvsyGnQuROa3heeG6LmaRILHuFSVl5opZ Ltze_eGpijVc.A317IOyNvC0lsR6iOLP_qcV7iO1xLMCH2jLIkQKjnnQhthf i53TrFU2G1yTujNn24mYePizrsv6GXkjbt5n54luRBxMXNIW6sace8Juo2ZU S1bPKDgtMsadBP8ygQizToNkoYyB7YDwQkFfGUtuKQIwb.b1dOVvT3DRacEx pRzdfwA7WwWpt65VnVqTUGrQ4hqpoB72sIxWIVmwkp2qrY4D45TEcxcAlQpy OLDqy2MJyqWWTgBV6_ueMTrQ- X-Yahoo-SMTP: indQcmSswBC8IKsm6t4aCAPskK3T X-Rocket-Received: from [192.168.0.102] (jsontest@76.29.100.42 with ) by smtp101.mail.bf1.yahoo.com with SMTP; 06 Jun 2013 22:44:44 +0000 UTC References: <51AF9D4C.5060403@crockford.com> <60563185-85A8-4696-8B8C-9282256CFA71@vpnc.org> <255B9BB34FB7D647A506DC292726F6E1151B10582A@WSMSG3153V.srv.dir.telstra.com> <19943667-1EC6-427F-9122-EC037BDE47F1@vpnc.org> <51AFEC73.1030904@crockford.com> <2484862A-4DFF-44D7-9D9D-7E44520C5BED@vpnc.org> <51B06A44.1070008@crockford.com> <2E0B8DF9-BF9F-485E-B011-D9864C4DB875@vpnc.org> <67FC4D12-AE76-45AC-A9B1-18FA33D030B4@vpnc.org> In-Reply-To: <67FC4D12-AE76-45AC-A9B1-18FA33D030B4@vpnc.org> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <0CF33649-86EE-4E26-86DC-85831339890C@yahoo.com> X-Mailer: iPod Mail (9B206) From: Vinny A Date: Thu, 6 Jun 2013 17:44:41 -0500 To: Paul Hoffman Cc: Carsten Bormann , "json@ietf.org" Subject: Re: [Json] Update reference for ABNF X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 06 Jun 2013 22:44:50 -0000 On Jun 6, 2013, at 11:54 AM, Paul Hoffman wrote: > Thank you, we have a volunteer! Who will be the second? That's a serious q= uestion: some WGs have passed non-ABNF-compliant documents due to having too= few checkers. I will also volunteer, if you're looking for more. Thanks. -V ----------------- Vinny A www.jsontest.com= From nico@cryptonector.com Thu Jun 6 15:47:14 2013 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 0359821F8528 for ; Thu, 6 Jun 2013 15:47:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CiqbAOWifEML for ; Thu, 6 Jun 2013 15:47:09 -0700 (PDT) Received: from homiemail-a73.g.dreamhost.com (mailbigip.dreamhost.com [208.97.132.5]) by ietfa.amsl.com (Postfix) with ESMTP id 1E2A221F8618 for ; Thu, 6 Jun 2013 15:47:09 -0700 (PDT) Received: from homiemail-a73.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a73.g.dreamhost.com (Postfix) with ESMTP id D07FF1F0081 for ; Thu, 6 Jun 2013 15:46:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=3lbI8QJgZf3Zz12F1JQA KJI6DAk=; b=KP3AYEGEcQ2YPPGdMlLaZ/th02QViClL/jcAu/52+JdhEy6MqJlI hren8BwIRaRoBS4GABgl5Q/5Ge+la0/QfGJg0v0A+TWC0oGGtH0/ADzs5ID5N8hS v6J2T0GK7njlVqVEu7rhdq4tSNrLGNZBySito4TR2e06s7kfSVbuZOQ= Received: from mail-wg0-f54.google.com (mail-wg0-f54.google.com [74.125.82.54]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a73.g.dreamhost.com (Postfix) with ESMTPSA id 754E01F0078 for ; Thu, 6 Jun 2013 15:46:57 -0700 (PDT) Received: by mail-wg0-f54.google.com with SMTP id j13so2653976wgh.9 for ; Thu, 06 Jun 2013 15:46:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=A3EsmK/iF7AHpc9gA5s6xun57hJuD0AeWj/W/4QAPXc=; b=Ir/iXQrj8IYe+5LrZacMrSgWazTMsUFWDed0hssYSRdKdPErxe/uGgT/i/KI9VOMge HVuW4CqHdoYvENgBMWIE45J74NydytbCOJ21CfqFIIgNc5myQ1O5J9MYd45d5JMu8qai MknRQgXuQ/r9GORBV3slT5lwag9h1Ui4+zXmpzNOsmpbj0zGfaSw1Y5fVoXaB5gbwMC6 NYunqAt1KvlJJ1N2oImcd6UDNY+/clZCbyYXfgEFR61Yoscs0RYBCUijr+yFVvZywDNA C7KAmPrW4eNMrJbrdLyRfl+whJH3Vi7WH/5ZaKNA4Db5cegS/96eg/1YlOmwcRE/Kk+m mwGw== MIME-Version: 1.0 X-Received: by 10.194.79.74 with SMTP id h10mr2433796wjx.84.1370558395911; Thu, 06 Jun 2013 15:39:55 -0700 (PDT) Received: by 10.216.63.136 with HTTP; Thu, 6 Jun 2013 15:39:55 -0700 (PDT) In-Reply-To: References: <51AF8479.5080002@crockford.com> Date: Thu, 6 Jun 2013 17:39:55 -0500 Message-ID: From: Nico Williams To: "Matt Miller (mamille2)" Content-Type: text/plain; charset=UTF-8 Cc: Douglas Crockford , "json@ietf.org" Subject: Re: [Json] The names within an object SHOULD be unique. X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 06 Jun 2013 22:47:14 -0000 On Thu, Jun 6, 2013 at 5:33 PM, Matt Miller (mamille2) wrote: > On Jun 6, 2013, at 4:21 PM, Nico Williams > wrote: >> [...] > > Note that so far, the document uses the term "name", not "key". I think the following needs to substitute "key" with "name" to be consistent. Ah, sure. >> Encoders SHOULD NOT send duplicate keys. Some encoders might not >> be able to prevent duplicate keys. Therefore parsers MUST be prepared >> to handle duplicate keys. >> >> Stateful parsers MUST accept [use?] only the last of any set of >> duplicate keys. >> > > I think this still needs to allow for stateful parsers that reject duplicate keys (for which there are some). That's fair. > Maybe: > > #### > > Stateful parsers MAY reject duplicate names. However, if duplicate names are accepted, it MUST accept only the last value of any set of duplicate names. Sure. I think we should define terms like "stateful parser" and "streaming parser". > #### > >> Some parsers might not be able to detect duplicate keys, much less >> pick only the last of them. Here a "stateful parser" is one that >> keeps on hand all of the values it decodes, as it decodes them. Note >> that accepting duplicate keys presents potential security risks. Note >> that sending duplicate keys risks data loss (that is, the loss of all >> but the last of a duplicated key's values). >> > > Can we describe a couple of specific security risks that are incurred? I think one would be something like overwriting of the original value by an attacker intercepting the exchange. I'm not concerned about MITMs and such. I'm concerned about attacks where we have a validator of some sorts as a filter and then a final consumer. The sender might send JSON that the validator accepts as valid, that will be passed on to the final consumer, and where the consumer will receive a different document (from it's p.o.v.) than the validator saw. Nico -- From nico@cryptonector.com Thu Jun 6 15:54:08 2013 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 8806221F96EF for ; Thu, 6 Jun 2013 15:54:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ao1GLvxRaPCd for ; Thu, 6 Jun 2013 15:54:03 -0700 (PDT) Received: from homiemail-a25.g.dreamhost.com (caiajhbdcaid.dreamhost.com [208.97.132.83]) by ietfa.amsl.com (Postfix) with ESMTP id 7267721F9967 for ; Thu, 6 Jun 2013 15:54:03 -0700 (PDT) Received: from homiemail-a25.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a25.g.dreamhost.com (Postfix) with ESMTP id F2B84678063 for ; Thu, 6 Jun 2013 15:54:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:date:message-id:subject:from:to:cc:content-type; s= cryptonector.com; bh=wRPwAuq0c2UushSskq65UODizMQ=; b=w1R1GgWE7Dn GbCx0y3bDbCcBbDGxsC/tTinifaXub9jmid7k2f1Oe44YYP2RcwjCfARl4wGnor+ WDKc1Mvkjqft+aSL6SEhpQ+ad7zAXdQRruLJ51+P6dYoO6QIgE++fSZlULpnF5Ly Z+2IWrI4wb8WiTJFdYiwb7o5eY9N0VPA= Received: from mail-we0-f178.google.com (mail-we0-f178.google.com [74.125.82.178]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a25.g.dreamhost.com (Postfix) with ESMTPSA id A53CF678075 for ; Thu, 6 Jun 2013 15:54:02 -0700 (PDT) Received: by mail-we0-f178.google.com with SMTP id u53so2587778wes.9 for ; Thu, 06 Jun 2013 15:54:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=xnhiDaLH6N5I+Y0aQZ90nnXkh673sfOs77X0Fu8YBm0=; b=YziGu2bsEHlNFVN98/NZ0ratvws0grcFN6KZooDTDURohYqmRfLVA35Pc9zyLTXbUg 0bCLr6a6eQFfDu3xDjDMTBx5w5Q3aqSaYZ4058eorFzQgTEs3MO4HzztHNfxz3g6a8wO Nksm4Fxa31PoIoB0ghVvRy+BGPPi9gXEV9j1YvpHST/xRxZ2dgVisFN8MSjMm6LRnJqk MAK2DF+BltFypR9Zk9jYRBnrEtTrNSGSfRjejct0B8qtTFpOwpCbwrCxU5dPYuBTujIg wtU5qS4pgluJIGc5nTJozZrKGUgkpLN59g5M6Nxv2oAwfGKuUDAV6ffZZi1nmgwzyD3q 9tjA== MIME-Version: 1.0 X-Received: by 10.194.24.8 with SMTP id q8mr2513044wjf.81.1370559241064; Thu, 06 Jun 2013 15:54:01 -0700 (PDT) Received: by 10.216.63.136 with HTTP; Thu, 6 Jun 2013 15:54:01 -0700 (PDT) Date: Thu, 6 Jun 2013 17:54:01 -0500 Message-ID: From: Nico Williams To: Douglas Crockford Content-Type: text/plain; charset=UTF-8 Cc: "json@ietf.org" Subject: [Json] Parser and encoder options (Re: The names within an object SHOULD be unique.) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 06 Jun 2013 22:54:08 -0000 On Thu, Jun 6, 2013 at 5:21 PM, Nico Williams wrote: > Regarding comments, I thought we'd have to accept that JSON does not > have comments, but since there's talk of extensions, and since we > could (and many, many parsers do) have options that can default to off > (unavailable), we might indeed want to consider a comments option. I forgot to finish this thought, which is just as well as this one should have a different Subject line, so now I've an excuse to change it. I could certainly imagine a parser that a) accepts parse options from the application, b) has some of the following options regarding duplicate names: - take first value - take last value - aggregate all the values into an array preserving the order in which they were received - return an error on duplicate names - warn of duplicate names - detect duplicate names (for streaming parsers) - use probabilistic duplicate name detection (also for streaming parsers) I think we should formalize the concept of options for parsers and encoders. For example, it's common to have options for pretty printing JSON. And there's been talk of extensions, so why not have some useful extensions (like comments, or string join, like in C, for pretty-printing purposes)? We should also have a taxonomy for describing an implementation. We've seen the need to distinguish between streaming and non-streaming parsers. (For now that's my only contribution to such a taxonomy.) Nico -- From paul.hoffman@vpnc.org Thu Jun 6 15:58:46 2013 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 BDC3121F99FC for ; Thu, 6 Jun 2013 15:58:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.225 X-Spam-Level: X-Spam-Status: No, score=-102.225 tagged_above=-999 required=5 tests=[AWL=0.374, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n5MXLIbrlYpI for ; Thu, 6 Jun 2013 15:58:45 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 380B221F99FB for ; Thu, 6 Jun 2013 15:58:45 -0700 (PDT) Received: from [10.20.30.90] (50-0-66-165.dsl.dynamic.sonic.net [50.0.66.165]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r56MwiCF046586 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 6 Jun 2013 15:58:44 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Paul Hoffman In-Reply-To: Date: Thu, 6 Jun 2013 15:58:43 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <8DF516C4-109F-487D-84C8-DC1AEF04A324@vpnc.org> References: <51AF8479.5080002@crockford.com> To: "json@ietf.org" X-Mailer: Apple Mail (2.1508) Subject: Re: [Json] The names within an object SHOULD be unique. X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 06 Jun 2013 22:58:46 -0000 Some of the recent comments on this thread have gone down the path of = naming different types of parsers and saying they might have different = rules because of their capabilities. Do we really want to do that for what is supposed to be a minimal update = of the spec? (That is a leading question, but "yes" is an acceptable = answer if it justified.) Proposal: we simply list what we want encoders and parsers to do without = saying what type of encoder, or what type of parser, gets to do what. --Paul Hoffman= From cowan@ccil.org Thu Jun 6 15:59:14 2013 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 7BDC621F99FC for ; Thu, 6 Jun 2013 15:59:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.101 X-Spam-Level: X-Spam-Status: No, score=-3.101 tagged_above=-999 required=5 tests=[AWL=0.498, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y-yj5HieClVf for ; Thu, 6 Jun 2013 15:59:08 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id 10FDF21F99FB for ; Thu, 6 Jun 2013 15:59:08 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1Ukj98-000198-NN; Thu, 06 Jun 2013 18:59:06 -0400 Date: Thu, 6 Jun 2013 18:59:06 -0400 From: John Cowan To: Nico Williams Message-ID: <20130606225906.GO3090@mercury.ccil.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Cc: Douglas Crockford , "json@ietf.org" Subject: Re: [Json] Parser and encoder options (Re: The names within an object SHOULD be unique.) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 06 Jun 2013 22:59:14 -0000 Nico Williams scripsit: > I think we should formalize the concept of options for parsers and encoders. > > For example, it's common to have options for pretty printing JSON. > And there's been talk of extensions, so why not have some useful > extensions (like comments, or string join, like in C, for > pretty-printing purposes)? > > We should also have a taxonomy for describing an implementation. > We've seen the need to distinguish between streaming and non-streaming > parsers. (For now that's my only contribution to such a taxonomy.) While all these things are nice-to-haves, they are why specs balloon up to dozens or even hundreds of pages, and become impossible for anyone but large, well-funded organizations to implement. I do most strongly urge this group NOT to go there. -- We call nothing profound cowan@ccil.org that is not wittily expressed. John Cowan --Northrop Frye (improved) From johnl@iecc.com Thu Jun 6 16:03:09 2013 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 BC20021F9944 for ; Thu, 6 Jun 2013 16:03:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.199 X-Spam-Level: X-Spam-Status: No, score=-111.199 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a0vH9xPeEKdn for ; Thu, 6 Jun 2013 16:03:04 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id DF91B21F93B9 for ; Thu, 6 Jun 2013 16:03:03 -0700 (PDT) Received: (qmail 60755 invoked from network); 6 Jun 2013 23:03:08 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 6 Jun 2013 23:03:08 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=51b11526.xn--3zv.k1306; i=johnl@user.iecc.com; bh=EYjwEBWXWYyCHkybNGSo3iNk4fSyvsjmao3Bor+OBZ8=; b=tFtRFyi+Q+Kvh3CoAVoTzwJlF7mGDRhQB6FwrgrffFSL3N6rXHiCmvqCGTFXSX0ecqvAJ29aAd3wgVFMtL8SW0Swe8MMfEF55O873WXJ1TmFpCYoHMVlejiQfSrXr5uRGooS10dxkPVN0iT9QGvqDfBZH3DzZ9G/LOK5BIR/mZ3jumsqUp7gxzE/72t406tPbRMCczOP7k/Smn2cBeup9nweaGuFXPb3q+2SIBdRLTvxRpEfb4VXrHGlN9KYVKO0 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=51b11526.xn--3zv.k1306; olt=johnl@user.iecc.com; bh=EYjwEBWXWYyCHkybNGSo3iNk4fSyvsjmao3Bor+OBZ8=; b=ND+PmALNPHVwzrh7zw2HGGatqV6QGH47kxRNlHF7Y+vVO0c6+Ss2QsMAZzSIy5G10FoxfGvCs+nMveuXEbMiJwNtBNGUZTpExc+8IGl0vt9L0FhlG7CcJVLK8yJYfnh6aMRtpRnxpRNmmi9alWN/nIx4z9FKqeGPAJBpBh4dN4FE/SGgajHqyRwz9oVdbM6W2yzV93+3T9KMHDltsjyzr+G+LkLToKStFQ6h1ujvYAW8KkZe8WI+0UtpZhiXHqXo Date: 6 Jun 2013 23:02:39 -0000 Message-ID: <20130606230239.24517.qmail@joyce.lan> From: "John Levine" To: json@ietf.org In-Reply-To: <51B0E02E.4070209@crockford.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Cc: douglas@crockford.com Subject: Re: [Json] Security Considerations X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 06 Jun 2013 23:03:09 -0000 I'd suggest also adding some warnings to parser writers along these lines: A string presented to a json parser may be a well formed json object, or it may be anything else. Hence a parser needs to avoid any assumptions that its input is well-formed. Even if an input string is syntactically valid, strings may be longer than the maximum length of an internal string format, numbers may not be representable in an internal numeric format, arrays may be longer than the limits of an internal array format, and an object may include more members than an internal form can represent. Objects and arrays may be more deeply nested than an internal form can represent. From nico@cryptonector.com Thu Jun 6 16:03:27 2013 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 9CAE211E80A4 for ; Thu, 6 Jun 2013 16:03:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Aur6+MpRNTuY for ; Thu, 6 Jun 2013 16:03:17 -0700 (PDT) Received: from homiemail-a31.g.dreamhost.com (caiajhbdcaid.dreamhost.com [208.97.132.83]) by ietfa.amsl.com (Postfix) with ESMTP id 3409D21F998A for ; Thu, 6 Jun 2013 16:03:17 -0700 (PDT) Received: from homiemail-a31.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a31.g.dreamhost.com (Postfix) with ESMTP id DB811202038 for ; Thu, 6 Jun 2013 16:03:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=kK5WAdvif8P21JYdVZtx US9CpEs=; b=bkQvNelShhYwaMmTIu1+L8WDJXs6yHMPw9bmGusiz7F/TnYwzF93 XrdrTRhjl+bgUWCJ/VHUk5xas/Gt0gdEbnUdZbQkbJ54rqz21QrlWoK04rRELIbd POmLiQcG+F9CVdavGhmuRAhV7eYZDbDW/2Q9AgUl2U8S/S6MbUCV6Qc= Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a31.g.dreamhost.com (Postfix) with ESMTPSA id 8475B202022 for ; Thu, 6 Jun 2013 16:03:16 -0700 (PDT) Received: by mail-wi0-f182.google.com with SMTP id cb5so729172wib.9 for ; Thu, 06 Jun 2013 16:03:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ImyhBYgmP/usf9pS/wRV7yj3LEAhoS1JpYXslYRZ1mk=; b=L6SHWlr5YZjIMUNJDVMaYdaRqLxPbEGSUXM0Phli1Zo+KzzItDKjNsIKxi1/2cq2yT 80+mS9H74F/86SXgtmLJlGRuV6FgsvrQzTx45ersE9S1Tev/9gl133XC77c5fMnzaw+r SawQ2/brNI1PfdkTHpEQ5FrRMimbHwWK6Hu9nCQP0tedG54ekIruMpv6uqMhWVgUHd63 lwWZhfcYsVoBT+s9Y5yEn4XweiHn5ssnTeMOVWKCmpdY77qIjDlF/c8J0tVU8JED0nlH c3CY/H8+MA9ierHZ8PXMNxSS8Rg9zbc4xzaynT1WQCXn07jEg6LhL60xJFDQglR6ud6e 7mug== MIME-Version: 1.0 X-Received: by 10.194.79.74 with SMTP id h10mr2478195wjx.84.1370559795341; Thu, 06 Jun 2013 16:03:15 -0700 (PDT) Received: by 10.216.63.136 with HTTP; Thu, 6 Jun 2013 16:03:15 -0700 (PDT) In-Reply-To: <8DF516C4-109F-487D-84C8-DC1AEF04A324@vpnc.org> References: <51AF8479.5080002@crockford.com> <8DF516C4-109F-487D-84C8-DC1AEF04A324@vpnc.org> Date: Thu, 6 Jun 2013 18:03:15 -0500 Message-ID: From: Nico Williams To: Paul Hoffman Content-Type: text/plain; charset=UTF-8 Cc: "json@ietf.org" Subject: Re: [Json] The names within an object SHOULD be unique. X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 06 Jun 2013 23:03:27 -0000 On Thu, Jun 6, 2013 at 5:58 PM, Paul Hoffman wrote: > > > Some of the recent comments on this thread have gone down the path of naming different types of parsers and saying they might have different rules because of their capabilities. > > Do we really want to do that for what is supposed to be a minimal update of the spec? (That is a leading question, but "yes" is an acceptable answer if it justified.) So far I think there's only two types of encoders and decoders: streaming and non-streaming. I don't think we'll see more types. If the list stays short, then "yes". > Proposal: we simply list what we want encoders and parsers to do without saying what type of encoder, or what type of parser, gets to do what. I would like to say that those parsers than can MUST accept only the last value. I would also like to not preclude parsers that can't even detect duplicates keys (streaming parsers). I would like to say that encoders that can MUST NOT send duplicate keys. I would also like to not preclude encoders that can't even detect that they are sending duplicate keys. Nico -- From paul.hoffman@vpnc.org Thu Jun 6 16:04:29 2013 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 CBA6721F998B for ; Thu, 6 Jun 2013 16:04:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.244 X-Spam-Level: X-Spam-Status: No, score=-102.244 tagged_above=-999 required=5 tests=[AWL=0.355, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4tpYg5HO5941 for ; Thu, 6 Jun 2013 16:04:29 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 4BEFD21F998A for ; Thu, 6 Jun 2013 16:04:29 -0700 (PDT) Received: from [10.20.30.90] (50-0-66-165.dsl.dynamic.sonic.net [50.0.66.165]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r56N4QXn046844 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 6 Jun 2013 16:04:26 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Paul Hoffman In-Reply-To: <51B0E02E.4070209@crockford.com> Date: Thu, 6 Jun 2013 16:04:25 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <1BD0044B-D7A6-4C7F-899E-5D3E72C62956@vpnc.org> References: <51B0E02E.4070209@crockford.com> To: Douglas Crockford X-Mailer: Apple Mail (2.1508) Cc: "json@ietf.org" Subject: Re: [Json] Security Considerations X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 06 Jun 2013 23:04:29 -0000 On Jun 6, 2013, at 12:17 PM, Douglas Crockford = wrote: > Proposal: >=20 > With any data format, it is important to encode correctly. Care = must > be taken when constructing JSON texts by concatenation. For = example: >=20 > account =3D 4627; > comment =3D "\",\"account\":262"; // provided by attacker > json_text =3D "(\"account\":" + account + ",\"comment\":\"" + = comment + "\"}"; >=20 > The result will be >=20 > {"account":4627,"comment":"","account":262} >=20 > which some parsers MAY see as being the same as >=20 > {"comment":"","account":262} >=20 > This confusion allows an attacker to modify the account property or > any other property. >=20 > It is much wiser to use JSON generators, which are available in many > forms for most programming languages, to do the encoding, avoiding > the confusion hazard. The example is language-specific and, due to the escaping, hard to read. = Proposed replacement: Programs that construct JSON texts by concatenating text from user input = need to take care that the result is unsurprising. For example, when = creating an object, a user might be able to inject a value that would = override another value that is being put into the object. JSON's = escaping rules for text make such attacks particularly difficult to = prevent. > JSON is so similar to some programming languages that the native > parsing ability of the language processors can be used to parse JSON > texts. This should be avoided because the native parser will accept > code which is not JSON. >=20 > For example, JavaScript's eval() function is able parse JSON text, > but is can also parse programs. If an attacker can inject code into > the JSON text (as we saw above), then it can compromise the system. > JSON parsers should always be used instead. Much better than what we have now. --Paul Hoffman= From nico@cryptonector.com Thu Jun 6 16:06:44 2013 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 54F7E21E8050 for ; Thu, 6 Jun 2013 16:06:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LVpT6iIcoVJN for ; Thu, 6 Jun 2013 16:06:39 -0700 (PDT) Received: from homiemail-a30.g.dreamhost.com (caiajhbdcahe.dreamhost.com [208.97.132.74]) by ietfa.amsl.com (Postfix) with ESMTP id 6D3F221E8053 for ; Thu, 6 Jun 2013 16:06:39 -0700 (PDT) Received: from homiemail-a30.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a30.g.dreamhost.com (Postfix) with ESMTP id 21CA021DE65 for ; Thu, 6 Jun 2013 16:06:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=0USFgpbLr3RqxEHPKlXe i7Ysf5c=; b=rEHWcGOHS3+ywiV6TOH2yT1mNn8+59Qih8Vb37xTR4NTuedbisIS 4bzDh2bPq/5U7hZIRbfAl8AwKcY8dv60Crl8QTtbhA4zAXDT0tKdD/dX7IeXp+Xb DHOaTt5LeTzHRX9z1U2r5GcY35EfNJ70omXZd+51Lr1LMx1wiRF/JB8= Received: from mail-wi0-f173.google.com (mail-wi0-f173.google.com [209.85.212.173]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a30.g.dreamhost.com (Postfix) with ESMTPSA id B44BD21DE59 for ; Thu, 6 Jun 2013 16:06:38 -0700 (PDT) Received: by mail-wi0-f173.google.com with SMTP id hi5so844666wib.0 for ; Thu, 06 Jun 2013 16:06:37 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=iF8O+yUInE3gLoQXJyvgPBtC9GohNO3BZnt5UJvaHrk=; b=c2h/yYfoSCz4KIjxcaBocKGVrwVB9XcL1zPdd+2GLqK4+vA0S+Op+g9EN9KklI3mp8 mhCpUddvizYpOTOa64LoUOh0k91pcdakBjqJ0bTvDdcIlTEYHPn8XBFlQHNEhN2dv6CS WvsTxtkwlAZLM3SX9WEdpogQDTyc4oOGJdNfw7iD5+EuuLOnrnY01xPoODa4MizBbp70 HxiL3jG0Q9REtxVrGxVPpshJoEqxyPDoxfexgzaAuxZ4Zp0CLhKfJz9/drLqPhuU4yb7 WPxc7d/I7upxY+rU6Zhv8mlL0OSAk26vBFuRC5f5K0G/IgnfBq0PQOA2KTRpM6HkfNvv orpg== MIME-Version: 1.0 X-Received: by 10.180.185.225 with SMTP id ff1mr150657wic.36.1370559997447; Thu, 06 Jun 2013 16:06:37 -0700 (PDT) Received: by 10.216.63.136 with HTTP; Thu, 6 Jun 2013 16:06:37 -0700 (PDT) In-Reply-To: <20130606225906.GO3090@mercury.ccil.org> References: <20130606225906.GO3090@mercury.ccil.org> Date: Thu, 6 Jun 2013 18:06:37 -0500 Message-ID: From: Nico Williams To: John Cowan Content-Type: text/plain; charset=UTF-8 Cc: Douglas Crockford , "json@ietf.org" Subject: Re: [Json] Parser and encoder options (Re: The names within an object SHOULD be unique.) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 06 Jun 2013 23:06:44 -0000 On Thu, Jun 6, 2013 at 5:59 PM, John Cowan wrote: > While all these things are nice-to-haves, they are why specs balloon up > to dozens or even hundreds of pages, and become impossible for anyone > but large, well-funded organizations to implement. I do most strongly > urge this group NOT to go there. I agree with the sentiment. Many parsers I've seen (hmm, *every* parser I've seen) has encoding/parsing options. One of the things we should want to do here is describe reality as it relates to interoperability. If that means adding text, so be it. Not every option will be relevant to interoperability, and if we're careful maybe none are (I've not made an inventory, so I don't yet know myself). From markus.lanthaler@gmx.net Thu Jun 6 16:08:58 2013 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 8499521E805A for ; Thu, 6 Jun 2013 16:08:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.15 X-Spam-Level: X-Spam-Status: No, score=-1.15 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sAZSHIN4s8iu for ; Thu, 6 Jun 2013 16:08:52 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) by ietfa.amsl.com (Postfix) with ESMTP id 4CC8921E8050 for ; Thu, 6 Jun 2013 16:08:52 -0700 (PDT) Received: from mailout-de.gmx.net ([10.1.76.27]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0Lkmks-1UClSY4AAG-00aRZb for ; Fri, 07 Jun 2013 01:08:51 +0200 Received: (qmail invoked by alias); 06 Jun 2013 23:08:50 -0000 Received: from 84-115-182-43.dynamic.surfer.at (EHLO Vostro3500) [84.115.182.43] by mail.gmx.net (mp027) with SMTP; 07 Jun 2013 01:08:50 +0200 X-Authenticated: #419883 X-Provags-ID: V01U2FsdGVkX186M+18yYk6c51ccyL2Bj3NaieOXr8ToW+YoHWI0c YXi83416/U0F8M From: "Markus Lanthaler" To: References: <51AF8479.5080002@crockford.com> In-Reply-To: Date: Fri, 7 Jun 2013 01:08:45 +0200 Message-ID: <01ef01ce630a$cbdb4210$6391c630$@lanthaler@gmx.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 thread-index: Ac5jBD3ou/vHtJKxT7aGqkfAzPtMwAABhTvg Content-Language: de X-Y-GMX-Trusted: 0 Subject: Re: [Json] The names within an object SHOULD be unique. X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 06 Jun 2013 23:08:58 -0000 On Sent: Friday, June 07, 2013 12:22 AM, Nico Williams wrote: > Having thought this far, I propose this text: > > Encoders SHOULD NOT send duplicate keys. Some encoders might not > be able to prevent duplicate keys. Therefore parsers MUST be prepared > to handle duplicate keys. -1, it is very reasonable to reject such JSON. -- Markus Lanthaler @markuslanthaler From douglas@crockford.com Thu Jun 6 16:11:16 2013 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 5C70021E8063 for ; Thu, 6 Jun 2013 16:11:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.112 X-Spam-Level: X-Spam-Status: No, score=-2.112 tagged_above=-999 required=5 tests=[AWL=0.487, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PrRzu+zmDuw5 for ; Thu, 6 Jun 2013 16:11:10 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id 7197C21E805F for ; Thu, 6 Jun 2013 16:11:10 -0700 (PDT) Received: from [192.168.0.108] (173-228-7-202.dsl.static.sonic.net [173.228.7.202]) by mrelay.perfora.net (node=mrus0) with ESMTP (Nemesis) id 0M6T2Z-1UROy239aN-00yQSv; Thu, 06 Jun 2013 19:11:08 -0400 Message-ID: <51B116FE.9050406@crockford.com> Date: Thu, 06 Jun 2013 16:10:54 -0700 From: Douglas Crockford User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Paul Hoffman References: <51B0E02E.4070209@crockford.com> <1BD0044B-D7A6-4C7F-899E-5D3E72C62956@vpnc.org> In-Reply-To: <1BD0044B-D7A6-4C7F-899E-5D3E72C62956@vpnc.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V02:K0:/FzGrn9zCsMr1NAis5yn2sX7xHv/iY6nVcHBnovBsrW aTyryegTPz7XPmzDw8X5OpDE1rWrND7tWMWY2GdRoFujPVYVbX ffAfJgVYf/11oLtCLX+lFoYwj57meL17qfm8Opc69FA0uhHryM Xsh+Tg6rlIFs90iKwMOk7GaL/rYWYeLpjcC+Ei9z2itXiTsGGQ iydpeYiC28bCWm/DmCcLeqtkiqCGG7okwdEV41WYXSS4LtiOj/ l78J0D9R05w2hvphbh4BRfus4NaBdp6eZYFG6xXYo2lBJoahn4 Fl9ejJd0gvr4c18+Wd+LJuAjRKl+mizHdscUgzMf3D174W5U/C J1F2KHjlGac7GA4HPXbA= Cc: "json@ietf.org" Subject: Re: [Json] Security Considerations X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 06 Jun 2013 23:11:16 -0000 On 6/6/2013 4:04 PM, Paul Hoffman wrote: > > On Jun 6, 2013, at 12:17 PM, Douglas Crockford wrote: > >> Proposal: >> >> With any data format, it is important to encode correctly. Care must >> be taken when constructing JSON texts by concatenation. For example: >> >> account = 4627; >> comment = "\",\"account\":262"; // provided by attacker >> json_text = "(\"account\":" + account + ",\"comment\":\"" + comment + "\"}"; > The example is language-specific and, due to the escaping, hard to read. Which specific language would you say it is? Confusion attacks are often hard to read. That is why they work. From tsaloranta@gmail.com Thu Jun 6 16:12:14 2013 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 9DCC321E8053 for ; Thu, 6 Jun 2013 16:12:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[AWL=0.427, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PecP6qSok1rU for ; Thu, 6 Jun 2013 16:12:14 -0700 (PDT) Received: from mail-wg0-x234.google.com (mail-wg0-x234.google.com [IPv6:2a00:1450:400c:c00::234]) by ietfa.amsl.com (Postfix) with ESMTP id A13D021E8050 for ; Thu, 6 Jun 2013 16:12:13 -0700 (PDT) Received: by mail-wg0-f52.google.com with SMTP id z12so1967870wgg.19 for ; Thu, 06 Jun 2013 16:12:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=y+ZyAtoffNxkRRvc6UqwDMXNuiFOX+pO3PB7Ht+pH3Y=; b=0T6ivVKZOD67NKm/gDH9nNYc6W7E6p+DmTYFqfKIaHheBXd82f4T/sm0UKKSm0BsAd XSo2fKkgBYB85bBwIyB++QjMe2lleoCZLVW3MHIgPf/VM5oAUQ/Wv3Kq75NEXgS8UX5q OhIKx8a+ZKRcvqGBeLuBcyCejaUJxJrAT4xSKUCVREBbgY9P4svHg9SrK0mkALfNo2DI QHirQmCQzUgb+LkIcZiwZeJCjlDHUm8AditNkrk34Dmm35Ij2ocLI7yi/DlsxdX7hPgP LwrI4MbN7Vh/0ePoJC0gI2YwPHj8Qpm5JkPd7ZD1SUwVa0eFokkj5tyyEqWSdD/gwVnv yOCA== MIME-Version: 1.0 X-Received: by 10.180.185.44 with SMTP id ez12mr213235wic.7.1370560332804; Thu, 06 Jun 2013 16:12:12 -0700 (PDT) Received: by 10.227.97.6 with HTTP; Thu, 6 Jun 2013 16:12:12 -0700 (PDT) In-Reply-To: References: Date: Thu, 6 Jun 2013 16:12:12 -0700 Message-ID: From: Tatu Saloranta To: Nico Williams Content-Type: multipart/alternative; boundary=001a11c22574c7b84304de847141 Cc: Paul Hoffman , "json@ietf.org" Subject: Re: [Json] Call for real-world examples of how parsers deal with duplicate keys X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 06 Jun 2013 23:12:14 -0000 --001a11c22574c7b84304de847141 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Jun 6, 2013 at 3:35 PM, Nico Williams wrote: > On Thu, Jun 6, 2013 at 2:37 PM, Tatu Saloranta > wrote: > > On Java, Jackson library: > > > > - Exposes both entries (key/value pairs) at streaming parsing level > > I don't think we should disqualify that sort of streaming parser > implementation. > > This leads me to conclude that we should distinguish between streaming > and stateful parsers (my terms; please suggest better ones). Stateful > parsers MUST accept only the last value, while streaming parsers MAY > (and probably always will) accept all duplicate keys' values. > > Nico > -- > I agree with this. It also goes to terminology: term "parser" is being used quite liberally, meaning anything from tokenizer, to the thing that builds higher level object representation (JSON-centrics trees, or host language objects), or combination of the whole thing. In this respect, related thread that tries to divide specification into different sections makes sense; physical structure and serialization are most related to low-level tokenization/generation, and then optional logical model(s) more to builders/serializers. Same is true for encoding aspects: at logical model level, underlying character encoding is irrelevant. But for low-level tokenization it matters: question like how encoding is obtained; or if no encoding information is available, what are possible encodings (only UTF-8? UTF-8 and UTF-16 since two can be auto-detected?). To me separation of physical and logical layers makes sense, even if most users are not aware of separation of the two: implementors can not ignore this. -+ Tatu +- --001a11c22574c7b84304de847141 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Jun 6, 2013 at 3:35 PM, Nico Williams <nico@c= ryptonector.com> wrote:
On Thu, Jun 6, 2013 at 2:3= 7 PM, Tatu Saloranta <tsaloranta= @gmail.com> wrote:
> On Java, Jackson library:
>
> - Exposes both entries (key/value pairs) at streaming parsing level
I don't think we should disqualify that sort of streaming parser = implementation.

This leads me to conclude that we should distinguish between streaming
and stateful parsers (my terms; please suggest better ones). =A0Stateful parsers MUST accept only the last value, while streaming parsers MAY
(and probably always will) accept all duplicate keys' values.

Nico
--

I agree with = this.

It also goes to terminology: term "parser" is being u= sed quite liberally, meaning anything from tokenizer, to the thing that bui= lds higher level object representation (JSON-centrics trees, or host langua= ge objects), or combination of the whole thing.
In this respect, related thread that tries= to divide specification into different sections makes sense; physical stru= cture and serialization are most related to low-level tokenization/generati= on, and then optional logical model(s) more to builders/serializers.

Same is true for encoding aspects: at logical model level, underlying char= acter encoding is irrelevant. But for low-level tokenization it matters: qu= estion like how encoding is obtained; or if no encoding information is avai= lable, what are possible encodings (only UTF-8? UTF-8 and UTF-16 since two = can be auto-detected?).

To me separation of physical and logical layers makes sense, even if most = users are not aware of separation of the two: implementors can not ignore t= his.

-+ Tatu +-

--001a11c22574c7b84304de847141-- From tsaloranta@gmail.com Thu Jun 6 16:17:14 2013 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 A0FD721F971F for ; Thu, 6 Jun 2013 16:17:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.243 X-Spam-Level: X-Spam-Status: No, score=-2.243 tagged_above=-999 required=5 tests=[AWL=0.356, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JIbxneWennJp for ; Thu, 6 Jun 2013 16:17:14 -0700 (PDT) Received: from mail-we0-x231.google.com (mail-we0-x231.google.com [IPv6:2a00:1450:400c:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id 8F37521F9927 for ; Thu, 6 Jun 2013 16:17:04 -0700 (PDT) Received: by mail-we0-f177.google.com with SMTP id m19so2460596wev.8 for ; Thu, 06 Jun 2013 16:17:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=P9o8rv0qrbIbgUPOWn6G0yVsjjRXp6VdnpBl23Of7Sg=; b=Sm6HWKNCtN0XstgJXygPLsETbGyEXqJg0Jwb/RvEefNhRo75dNaVlGzbOpj+eQifJp g1OHHa5UqnfLJKL4t5kMl9ZHjepEr3LkvmwaZocE+4g5NFu3di80MzJm7f0Dtde5f9gD dbHCi1Uzvo8dAblI6l+VjtA+o81IaKp115CxBWII9Ix+n2s5Zm0BGPsOkBFlMCeBfyYb ivXkNSif6tCJyyaAI/vA8qKPEk8r7Arwv1a+vIVn0/Dnb9IUGlXwPKMmH8gleMpNK04J x9L1TW2nC+HoXAjifGoNugVP9z+rMXjPdHu+TIJMjFkotAtOnWJmfhWrnhI9FrKey9IY 1IKg== MIME-Version: 1.0 X-Received: by 10.194.90.244 with SMTP id bz20mr2574120wjb.69.1370560624346; Thu, 06 Jun 2013 16:17:04 -0700 (PDT) Received: by 10.227.97.6 with HTTP; Thu, 6 Jun 2013 16:17:04 -0700 (PDT) In-Reply-To: <20130606223711.GN3090@mercury.ccil.org> References: <51AF8479.5080002@crockford.com> <20130606223711.GN3090@mercury.ccil.org> Date: Thu, 6 Jun 2013 16:17:04 -0700 Message-ID: From: Tatu Saloranta To: John Cowan Content-Type: multipart/alternative; boundary=047d7bfd090a28518f04de8483df Cc: Nico Williams , Douglas Crockford , "json@ietf.org" Subject: Re: [Json] The names within an object SHOULD be unique. X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 06 Jun 2013 23:17:14 -0000 --047d7bfd090a28518f04de8483df Content-Type: text/plain; charset=ISO-8859-1 On Thu, Jun 6, 2013 at 3:37 PM, John Cowan wrote: > Nico Williams scripsit: > > > Thinking of encoders that do not have full knowledge of an object as > > it is encoded, I'm uncomfortable with saying "MUST NOT send duplicate > > keys", since determining whether a given key has already been sent > > might require large amounts of state. But note that this concern also > > applies to parsers! > > The amount of state can be reduced probabilistically by storing hashes > of the values rather than the values themselves > But hashes would only allow finding potential duplicates, and one still has to verify with real Strings. I don't see a way around false positives. -+ Tatu +- --047d7bfd090a28518f04de8483df Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Jun 6, 2013 at 3:37 PM, John Cowan <cowan@me= rcury.ccil.org> wrote:
Nico Williams scripsit:

> Thinking of encoders that do not have full knowledge of an object as > it is encoded, I'm uncomfortable with saying "MUST NOT send d= uplicate
> keys", since determining whether a given key has already been sen= t
> might require large amounts of state. =A0But note that this concern al= so
> applies to parsers!

The amount of state can be reduced probabilistically by storing hashe= s
of the values rather than the values themselves


But hashes would only allow finding pot= ential duplicates, and one still has to verify with real Strings. I don'= ;t see a way around false positives.

-+ Tatu +-

= =A0
--047d7bfd090a28518f04de8483df-- From markus.lanthaler@gmx.net Thu Jun 6 16:19:07 2013 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 A822521E8050 for ; Thu, 6 Jun 2013 16:19:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.15 X-Spam-Level: X-Spam-Status: No, score=-1.15 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yj-Ov1llx1YY for ; Thu, 6 Jun 2013 16:19:01 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by ietfa.amsl.com (Postfix) with ESMTP id 159E621F98AC for ; Thu, 6 Jun 2013 16:19:00 -0700 (PDT) Received: from mailout-de.gmx.net ([10.1.76.10]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0MRhah-1UvYHM29cX-00T0Hi for ; Fri, 07 Jun 2013 01:18:53 +0200 Received: (qmail invoked by alias); 06 Jun 2013 23:18:53 -0000 Received: from 84-115-182-43.dynamic.surfer.at (EHLO Vostro3500) [84.115.182.43] by mail.gmx.net (mp010) with SMTP; 07 Jun 2013 01:18:53 +0200 X-Authenticated: #419883 X-Provags-ID: V01U2FsdGVkX19mO5FeIAhmG+xP5bCBslYx1AqJZxZIjNx/aJXxum AnQT66tADFMMaG From: "Markus Lanthaler" To: References: In-Reply-To: Date: Fri, 7 Jun 2013 01:18:47 +0200 Message-ID: <01f601ce630c$32ff90d0$98feb270$@lanthaler@gmx.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 thread-index: Ac5jCMI9BsWtcbcxTkOqI0QHyRn4ZAAAvQCw Content-Language: de X-Y-GMX-Trusted: 0 Subject: Re: [Json] Parser and encoder options (Re: The names within an object SHOULD be unique.) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 06 Jun 2013 23:19:07 -0000 On Friday, June 07, 2013 12:54 AM, Nico Williams wrote: > I could certainly imagine a parser that a) accepts parse options from > the application, b) has some of the following options regarding > duplicate names: > > - take first value > - take last value > - aggregate all the values into an array preserving the order in > which they were received > - return an error on duplicate names > - warn of duplicate names > - detect duplicate names (for streaming parsers) > - use probabilistic duplicate name detection (also for streaming > parsers) > > I think we should formalize the concept of options for parsers and > encoders. I disagree. We are primarily defining a data format. Specific implementations can support whatever options they want. It just doesn't matter for the data format. What does matter is that different implementations are able to talk to each other *without* knowing about the other ends settings. Specifying options as the ones you list above would thus be counterproductive. > For example, it's common to have options for pretty printing JSON. > And there's been talk of extensions, so why not have some useful > extensions (like comments, or string join, like in C, for > pretty-printing purposes)? Anyone is free to do that in his implementation but the spec doesn't need to talk about this. -- Markus Lanthaler @markuslanthaler From tsaloranta@gmail.com Thu Jun 6 16:19:22 2013 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 7785F21F99AF for ; Thu, 6 Jun 2013 16:19:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.294 X-Spam-Level: X-Spam-Status: No, score=-2.294 tagged_above=-999 required=5 tests=[AWL=0.305, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QRylY-zZ9Ji5 for ; Thu, 6 Jun 2013 16:19:22 -0700 (PDT) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) by ietfa.amsl.com (Postfix) with ESMTP id B62CA21F98AC for ; Thu, 6 Jun 2013 16:19:21 -0700 (PDT) Received: by mail-wi0-f177.google.com with SMTP id ey16so846276wid.4 for ; Thu, 06 Jun 2013 16:19:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=e1uoNWC/Bhn9dVVUpdI103bPnmhy6zFLaMUqNFqsmNs=; b=WCSXAa2PafRcb+nBO9z4Z/qv0zbLRQAzVuxRZOfIsQrPJXrgBpNdTj0+asEMd1UqmF Odalb98mjTfFwKyJC0jYBytT0xvIcrp3eAjpkk9dV7pMgq0oAI+E0tpNU25K24sDqdo7 M0QJV6KNz1cmcPjy5UXhrtf3T7WoSMRvSIgCt2JEtPMffKI3daR766DAF1O4CQABPlks c4XxlNHUY4aTF5/kKadNjsfHIwmtxfyLCPi+lEZ4YKtYwhCMkblGwBm98v/Szfi/yFXX O/xCQjjIfGwUz1nDfZEHn1QmwvHRU6CTDYX21yxkAcsq6q6RMmUWMyHOlJfVO91nvz0w 19Yw== MIME-Version: 1.0 X-Received: by 10.194.134.73 with SMTP id pi9mr34125952wjb.38.1370560760942; Thu, 06 Jun 2013 16:19:20 -0700 (PDT) Received: by 10.227.97.6 with HTTP; Thu, 6 Jun 2013 16:19:20 -0700 (PDT) In-Reply-To: <8DF516C4-109F-487D-84C8-DC1AEF04A324@vpnc.org> References: <51AF8479.5080002@crockford.com> <8DF516C4-109F-487D-84C8-DC1AEF04A324@vpnc.org> Date: Thu, 6 Jun 2013 16:19:20 -0700 Message-ID: From: Tatu Saloranta To: Paul Hoffman Content-Type: multipart/alternative; boundary=e89a8f3ba28b4c95eb04de848bbb Cc: "json@ietf.org" Subject: Re: [Json] The names within an object SHOULD be unique. X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 06 Jun 2013 23:19:22 -0000 --e89a8f3ba28b4c95eb04de848bbb Content-Type: text/plain; charset=ISO-8859-1 On Thu, Jun 6, 2013 at 3:58 PM, Paul Hoffman wrote: > > > Some of the recent comments on this thread have gone down the path of > naming different types of parsers and saying they might have different > rules because of their capabilities. > > Do we really want to do that for what is supposed to be a minimal update > of the spec? (That is a leading question, but "yes" is an acceptable answer > if it justified.) > > Proposal: we simply list what we want encoders and parsers to do without > saying what type of encoder, or what type of parser, gets to do what. I think mention of different modes of operation would only be relevant to explain why certain limits (MUST not write duplicates, MUST report error for duplicates) can not be imposed. So they could be mentioned as rationale; explain why SHOULD instead of MUST. -+ Tatu +- --e89a8f3ba28b4c95eb04de848bbb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Jun 6, 2013 at 3:58 PM, Paul Hoffman <paul.ho= ffman@vpnc.org> wrote:
<co-chair hat on>

Some of the recent comments on this thread have gone down the path of namin= g different types of parsers and saying they might have different rules bec= ause of their capabilities.

Do we really want to do that for what is supposed to be a minimal update of= the spec? (That is a leading question, but "yes" is an acceptabl= e answer if it justified.)

Proposal: we simply list what we want encoders and parsers to do without sa= ying what type of encoder, or what type of parser, gets to do what.


I think mention of different = modes of operation would only be relevant to explain why certain limits (MU= ST not write duplicates, MUST report error for duplicates) can not be impos= ed. So they could be mentioned as rationale; explain why SHOULD instead of = MUST.

-+ Tatu +-
=A0
<= /div> --e89a8f3ba28b4c95eb04de848bbb-- From cowan@ccil.org Thu Jun 6 16:27:27 2013 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 72D4921F8FB6 for ; Thu, 6 Jun 2013 16:27:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.136 X-Spam-Level: X-Spam-Status: No, score=-3.136 tagged_above=-999 required=5 tests=[AWL=0.463, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GpXImo3eymVM for ; Thu, 6 Jun 2013 16:27:23 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id ED9D821F8FA3 for ; Thu, 6 Jun 2013 16:27:15 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1UkjaM-0004OA-3s; Thu, 06 Jun 2013 19:27:14 -0400 Date: Thu, 6 Jun 2013 19:27:14 -0400 From: John Cowan To: Tatu Saloranta Message-ID: <20130606232713.GP3090@mercury.ccil.org> References: <51AF8479.5080002@crockford.com> <20130606223711.GN3090@mercury.ccil.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Cc: Nico Williams , Douglas Crockford , "json@ietf.org" Subject: Re: [Json] The names within an object SHOULD be unique. X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 06 Jun 2013 23:27:27 -0000 Tatu Saloranta scripsit: > But hashes would only allow finding potential duplicates, and one still has > to verify with real Strings. I don't see a way around false positives. That's the point of probabilistic algorithms: you can reduce the probability of a false positive below any value you are willing to accept. -- Values of beeta will give rise to dom! John Cowan (5th/6th edition 'mv' said this if you tried http://www.ccil.org/~cowan to rename '.' or '..' entries; see cowan@ccil.org http://cm.bell-labs.com/cm/cs/who/dmr/odd.html) From nico@cryptonector.com Thu Jun 6 16:53:39 2013 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 9FBDF21F9953 for ; Thu, 6 Jun 2013 16:53:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WkfE0Qp-6H5j for ; Thu, 6 Jun 2013 16:53:33 -0700 (PDT) Received: from homiemail-a95.g.dreamhost.com (caiajhbdcahe.dreamhost.com [208.97.132.74]) by ietfa.amsl.com (Postfix) with ESMTP id 525E521F9950 for ; Thu, 6 Jun 2013 16:53:33 -0700 (PDT) Received: from homiemail-a95.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a95.g.dreamhost.com (Postfix) with ESMTP id EECA11E0E9 for ; Thu, 6 Jun 2013 16:53:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=o45tpuzzOv1LvuniRLlL23Rsw+s=; b=m2SSoaGDwHZ nNt9/+M9b1w/X2G2Z5UweB67/fHP8h8kE+0dAW5bLgKJAtKyjH5ui/P/lLHmeHEb LzNW5P4YpKjCDEkd7kIvoUqUbBFTOGxLowNmuBqtfFQ9g5BxTBHfeg3zyW/jjHck pPI9WLHZOaCGO34yBooV0kH7h8j8bzoA= Received: from mail-we0-f181.google.com (mail-we0-f181.google.com [74.125.82.181]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a95.g.dreamhost.com (Postfix) with ESMTPSA id B65CE22E0B0 for ; Thu, 6 Jun 2013 15:59:44 -0700 (PDT) Received: by mail-we0-f181.google.com with SMTP id p58so2518881wes.40 for ; Thu, 06 Jun 2013 15:59:30 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=MUArcTeIZ2K7HvgFPJA0L3V74uMVG7nWaWTEWHbdoKI=; b=Jyvcp0cswQaRAl4NwULAqofGVz/F8rxI6crV2LHxLS6stonpiyKmAjzrvDdJEzneMI FOchl9adxmkj5XL7HRxjzce0n7soO3/5LRk8/DWFpx+J3XKgQZfWQuGaCyz9iFpF4sdr tBu/O4+S0DMdGM86cgxslEm+p9MvX/r6LEckI5oMi3eEWGimIRISmvD25bPyTrYoJ0XS SXE98O7tHg7XKbmth4qv9VpPL8c9ULKSe9OPSBiNdB+8CPUmwnXVjwjMeUbWnaNfreg/ t4dqZ/nTbGdUQ0A3i5LmoVmSJBytdVWkjUE/dR6ScmH89f0KDBFByHavZ8sRaaW677tg lK9g== MIME-Version: 1.0 X-Received: by 10.180.109.195 with SMTP id hu3mr179197wib.13.1370559569980; Thu, 06 Jun 2013 15:59:29 -0700 (PDT) Received: by 10.216.63.136 with HTTP; Thu, 6 Jun 2013 15:59:29 -0700 (PDT) In-Reply-To: References: <38C1C408-3AF4-4CF2-96E1-9544C54B0531@vpnc.org> Date: Thu, 6 Jun 2013 17:59:29 -0500 Message-ID: From: Nico Williams To: Tim Bray Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "json@ietf.org" , Paul Hoffman , "Joe Hildebrand \(jhildebr\)" , "Matt Miller \(mamille2\)" Subject: Re: [Json] Strings X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 06 Jun 2013 23:53:39 -0000 On Thu, Jun 6, 2013 at 11:48 AM, Tim Bray wrote: > If keys are unicode strings, the proper languagee is: > > =E2=80=9CFor purpose of establishing key equality, comparisons MUST be co= nducted, > after all escaping is done, on a character-by-character basis by comparin= g and after unescaping unnecessarily-escaped characters. > numeric character codepoints. There is to be no modification of any kind = to > the characters in keys, including case-changing or combining-form > normalization.=E2=80=9D This works, and stronly implies (as I would like to have it) that the only reliably comparable strings (for the purposes of object keys [names]) are those where normalization to any normalization form would have no effect on the codepoints making up the string. Nico -- From nico@cryptonector.com Thu Jun 6 17:13:56 2013 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 0D0D021F9408 for ; Thu, 6 Jun 2013 17:13:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A4jg2qGf51xX for ; Thu, 6 Jun 2013 17:13:51 -0700 (PDT) Received: from homiemail-a74.g.dreamhost.com (caiajhbdccah.dreamhost.com [208.97.132.207]) by ietfa.amsl.com (Postfix) with ESMTP id 2936521F8F6D for ; Thu, 6 Jun 2013 17:13:51 -0700 (PDT) Received: from homiemail-a74.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a74.g.dreamhost.com (Postfix) with ESMTP id 9AC6967C072 for ; Thu, 6 Jun 2013 17:13:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=lLkskfI3EKkgKdclp0Zw 8NZKc8c=; b=Jk9gfDZ0l1Yr39Nx+DmlUlenpeewpljB486xeY6W/1Ya5jvYfde4 EBuExvm8+H2/heWxEX6kV2JWX39QMdN3vIxJ+tQzFOJ9bju5jv+2U7JH8YgL0GJG UW3Rv7oGuvmbEjIaTghwHwsaVlpmTh9vc6ORCAfM45fSdBmpqLr46uo= Received: from mail-wg0-f47.google.com (mail-wg0-f47.google.com [74.125.82.47]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a74.g.dreamhost.com (Postfix) with ESMTPSA id 4F58367C06E for ; Thu, 6 Jun 2013 17:13:50 -0700 (PDT) Received: by mail-wg0-f47.google.com with SMTP id e11so2648293wgh.14 for ; Thu, 06 Jun 2013 17:13:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=g7zWewMd8ZWMKyfHiSf4zBUEiHCsW9/gj0XJ0tX/RHE=; b=Btxt23DlHrCJXNquXoJ1YwiP5P50YcrcPd7NAJgb2t1Tf37FSYNZndhG5nUDDxULF2 jwwvn1PSiCGDFZXrG6Erao2MSwoMPx62ISGS3BtCQyJWQ1eIK9mYGqHZOyJDIziyKap+ gOoiIVymkoe/zTJQoP2s/yOHAhY0U7Je8zzIn85tsxkWnWYmcNGsjW1h3KKjVRdQkXP3 0jWlfd66WjYr3TuynZxcjFqXG/e8rf5tQQAxrBAwBEBj2fGFVg8V1mNjJ72Mmz+unTnu QGsN7+OtJBMBmiHk0uBxPEYK/4YCJba4qdDXGyBz8X466FQrNPagizWVh6WND0MTa70P 3Z9w== MIME-Version: 1.0 X-Received: by 10.180.185.225 with SMTP id ff1mr262333wic.36.1370564028718; Thu, 06 Jun 2013 17:13:48 -0700 (PDT) Received: by 10.216.63.136 with HTTP; Thu, 6 Jun 2013 17:13:48 -0700 (PDT) Received: by 10.216.63.136 with HTTP; Thu, 6 Jun 2013 17:13:48 -0700 (PDT) In-Reply-To: <51b1168c.e686440a.5339.5fc4SMTPIN_ADDED_BROKEN@mx.google.com> References: <51AF8479.5080002@crockford.com> <51b1168c.e686440a.5339.5fc4SMTPIN_ADDED_BROKEN@mx.google.com> Date: Thu, 6 Jun 2013 19:13:48 -0500 Message-ID: From: Nico Williams To: Markus Lanthaler Content-Type: multipart/alternative; boundary=001a11c34ed212e7d804de854e82 Cc: json@ietf.org Subject: Re: [Json] The names within an object SHOULD be unique. X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 07 Jun 2013 00:13:56 -0000 --001a11c34ed212e7d804de854e82 Content-Type: text/plain; charset=UTF-8 On Jun 6, 2013 6:09 PM, "Markus Lanthaler" wrote: > > On Sent: Friday, June 07, 2013 12:22 AM, Nico Williams wrote: > > Having thought this far, I propose this text: > > > > Encoders SHOULD NOT send duplicate keys. Some encoders might not > > be able to prevent duplicate keys. Therefore parsers MUST be prepared > > to handle duplicate keys. > > -1, it is very reasonable to reject such JSON. I wrote "handle", not "accept". --001a11c34ed212e7d804de854e82 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Jun 6, 2013 6:09 PM, "Markus Lanthaler" <markus.lanthaler@gmx.net> wrote:
>
> On Sent: Friday, June 07, 2013 12:22 AM, Nico Williams wrote:
> > Having thought this far, I propose this text:
> >
> > =C2=A0 =C2=A0Encoders SHOULD NOT send duplicate keys. =C2=A0Some = encoders might not
> > be able to prevent duplicate keys. =C2=A0Therefore parsers MUST b= e prepared
> > to handle duplicate keys.
>
> -1, it is very reasonable to reject such JSON.

I wrote "handle", not "accept".

--001a11c34ed212e7d804de854e82-- From jhildebr@cisco.com Thu Jun 6 17:46:31 2013 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 0C25B21F885A for ; Thu, 6 Jun 2013 17:46:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iMjZoy8y1Lsx for ; Thu, 6 Jun 2013 17:46:25 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 1805721F8616 for ; Thu, 6 Jun 2013 17:46:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=407; q=dns/txt; s=iport; t=1370565984; x=1371775584; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=jVuhAedkEJuHPVU9cZyhFv75sWZFMuttclBCWJih4P8=; b=mVBDx94xIdVBSo+Iw4nIlzLI2K4sQ1ZON3se/DXC4IA/PVQc7x4SRRrE n5XoA4cKx4GhJgOkrKOlIeV7uNJH8492Dy5TBIQE2J5C31JKunVkA6cqq C1qPgaxDzhqJqQyB86FBAZb33Elj7RcPQTe7hg6Y56IXC1eUNk8G0yhhP s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApQGALEssVGtJV2Z/2dsb2JhbABZgwm/IXsWbQeCJQEEOlEBKhRCDxgEG4gFmxCgQI8BgzJhA6h/gw+CJw X-IronPort-AV: E=Sophos;i="4.87,818,1363132800"; d="scan'208";a="216852576" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-9.cisco.com with ESMTP; 07 Jun 2013 00:46:23 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r570kNDQ001480 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 7 Jun 2013 00:46:23 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.56]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.02.0318.004; Thu, 6 Jun 2013 19:46:22 -0500 From: "Joe Hildebrand (jhildebr)" To: "json@ietf.org" Thread-Topic: ABNF nits Thread-Index: AQHOYxhuLNPlu69CpUeh/eSpf1GKTQ== Date: Fri, 7 Jun 2013 00:46:22 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [10.21.88.234] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [Json] ABNF nits X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 07 Jun 2013 00:46:31 -0000 Some things I found futzing with the ABNF: - normalize the indentation (makes it easier to pull out) - Hex literals need to be uppercase. The false and null rules are wrong. - DIGIT and HEXDIG are neither defined nor imported, as far as I can tell. I suggest: DIGIT =3D %x30-39 ; 0-9 HEXDIG =3D %x30-39 / %x41-46 / %x61-66 ; 0-9, A-F, or a-f --=20 Joe Hildebrand From jhildebr@cisco.com Thu Jun 6 18:02:19 2013 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 4C75821F9330 for ; Thu, 6 Jun 2013 18:02:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sDXSGGGm2Fo7 for ; Thu, 6 Jun 2013 18:02:13 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id B13EB21F8F6D for ; Thu, 6 Jun 2013 18:02:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=641; q=dns/txt; s=iport; t=1370566933; x=1371776533; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=DxXC1yniO0EP1qe8c/AQatojVjSCu0Rh/jgyLVO+hM0=; b=aLvyIPKTQZCtWnWzoYfFgq5FCjMzCdrAzSh4U53yUWyDCOpeLmEcaBTx cgOPD1qc9fPLtYGBUsDVSiGMLa9FuRP1ImcsJ9t181Ko3qUEWNb6HCSH/ fRpn8S53so8J61UtvxkmfntgHLZiosoqslDnzj3km5YzLBSJdpDzCyxEt Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiQFAGMwsVGtJV2Z/2dsb2JhbABZgwmDJbt8exZ0giUBBHkSAQgiViUCBAENBQiIBbtNjwExB4J6YQOIaKAXgw+CJw X-IronPort-AV: E=Sophos;i="4.87,818,1363132800"; d="scan'208";a="219839868" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-6.cisco.com with ESMTP; 07 Jun 2013 01:02:13 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r5712C09013034 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 7 Jun 2013 01:02:12 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.56]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.02.0318.004; Thu, 6 Jun 2013 20:02:12 -0500 From: "Joe Hildebrand (jhildebr)" To: Nico Williams , Tim Bray Thread-Topic: [Json] Strings Thread-Index: AQHOYks3qXYMVZxHuUK8pIRm8dGJzZkn+HmAgAEjmgCAABz3AIAAAaCAgABnkID//72xgA== Date: Fri, 7 Jun 2013 01:02:11 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [10.21.88.234] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <4E60F25A76B346429989B3400722DC07@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "json@ietf.org" , Paul Hoffman , "Matt Miller \(mamille2\)" Subject: Re: [Json] Strings X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 07 Jun 2013 01:02:19 -0000 On 6/6/13 4:59 PM, "Nico Williams" wrote: >>numeric character codepoints. There is to be no modification of any kind >>to >> the characters in keys, including case-changing or combining-form >> normalization.=B2 > >This works, and stronly implies (as I would like to have it) that the >only reliably comparable strings (for the purposes of object keys >[names]) are those where normalization to any normalization form would >have no effect on the codepoints making up the string. Why is that implied? We're not suggesting normalizing names in any way, other than unescaping. --=20 Joe Hildebrand From James.H.Manger@team.telstra.com Thu Jun 6 18:04:04 2013 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 066C521F9298 for ; Thu, 6 Jun 2013 18:04:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.096 X-Spam-Level: X-Spam-Status: No, score=-0.096 tagged_above=-999 required=5 tests=[AWL=0.805, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sf-jxlN9MJJI for ; Thu, 6 Jun 2013 18:03:57 -0700 (PDT) Received: from ipxavo.tcif.telstra.com.au (ipxavo.tcif.telstra.com.au [203.35.135.200]) by ietfa.amsl.com (Postfix) with ESMTP id 5063D21F8895 for ; Thu, 6 Jun 2013 18:03:57 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.87,818,1363093200"; d="scan'208";a="139626037" Received: from unknown (HELO ipccvi.tcif.telstra.com.au) ([10.97.217.208]) by ipoavi.tcif.telstra.com.au with ESMTP; 07 Jun 2013 11:03:55 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,7098"; a="136967100" Received: from wsmsg3701.srv.dir.telstra.com ([172.49.40.169]) by ipccvi.tcif.telstra.com.au with ESMTP; 07 Jun 2013 11:03:55 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3701.srv.dir.telstra.com ([172.49.40.169]) with mapi; Fri, 7 Jun 2013 11:03:54 +1000 From: "Manger, James H" To: Tim Bray Date: Fri, 7 Jun 2013 11:03:53 +1000 Thread-Topic: [Json] Strings Thread-Index: Ac5i1cRum6V6C4WjRDSVjzsantkkkQAREtYQ Message-ID: <255B9BB34FB7D647A506DC292726F6E1151B21F57F@WSMSG3153V.srv.dir.telstra.com> References: <38C1C408-3AF4-4CF2-96E1-9544C54B0531@vpnc.org> In-Reply-To: Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "json@ietf.org" Subject: Re: [Json] Strings X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 07 Jun 2013 01:04:04 -0000 PiBJZiBrZXlzIGFyZSB1bmljb2RlIHN0cmluZ3MsIHRoZSBwcm9wZXIgbGFuZ3VhZ2VlIGlzOg0K PiDigJxGb3IgcHVycG9zZSBvZiBlc3RhYmxpc2hpbmcga2V5IGVxdWFsaXR5LCBjb21wYXJpc29u cyBNVVNUIGJlIGNvbmR1Y3RlZCwgYWZ0ZXIgYWxsIGVzY2FwaW5nIGlzIGRvbmUsIG9uIGEgY2hh cmFjdGVyLWJ5LWNoYXJhY3RlciBiYXNpcyBieSBjb21wYXJpbmcgbnVtZXJpYyBjaGFyYWN0ZXIg Y29kZXBvaW50cy4gVGhlcmUgaXMgdG8gYmUgbm8gbW9kaWZpY2F0aW9uIG9mIGFueSBraW5kIHRv IHRoZSBjaGFyYWN0ZXJzIGluIGtleXMsIGluY2x1ZGluZyBjYXNlLWNoYW5naW5nIG9yIGNvbWJp bmluZy1mb3JtIG5vcm1hbGl6YXRpb24u4oCdDQoNCgkNCnMvYWZ0ZXIgYWxsIGVzY2FwaW5nIGlz IGRvbmUvYWZ0ZXIgYWxsIHVuZXNjYXBpbmcgaXMgZG9uZS8NCg0Kb3Igc2hvdWxkIHRoYXQgYmUg DQoNCnMvYWZ0ZXIgYWxsIGVzY2FwaW5nIGlzIGRvbmUvYWZ0ZXIgYWxsIGVzY2FwaW5nIGlzIHVu ZG9uZS8NCg0KLS0NCkphbWVzIE1hbmdlcg0K From James.H.Manger@team.telstra.com Thu Jun 6 18:11:51 2013 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 D9DD421F869F for ; Thu, 6 Jun 2013 18:11:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.211 X-Spam-Level: X-Spam-Status: No, score=-0.211 tagged_above=-999 required=5 tests=[AWL=0.690, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mOToq7hXGgRb for ; Thu, 6 Jun 2013 18:11:46 -0700 (PDT) Received: from ipxcno.tcif.telstra.com.au (ipxcno.tcif.telstra.com.au [203.35.82.208]) by ietfa.amsl.com (Postfix) with ESMTP id 21F6521F8D10 for ; Thu, 6 Jun 2013 18:11:41 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.87,818,1363093200"; d="scan'208";a="134106051" Received: from unknown (HELO ipcbni.tcif.telstra.com.au) ([10.97.216.204]) by ipocni.tcif.telstra.com.au with ESMTP; 07 Jun 2013 11:11:41 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,7098"; a="138083292" Received: from wsmsg3756.srv.dir.telstra.com ([172.49.40.84]) by ipcbni.tcif.telstra.com.au with ESMTP; 07 Jun 2013 11:11:41 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3756.srv.dir.telstra.com ([172.49.40.84]) with mapi; Fri, 7 Jun 2013 11:11:40 +1000 From: "Manger, James H" To: "json@ietf.org" Date: Fri, 7 Jun 2013 11:11:39 +1000 Thread-Topic: issues tracker? Thread-Index: Ac5jG/b7q8QrMd+RT3eBoTz0CnrKDw== Message-ID: <255B9BB34FB7D647A506DC292726F6E1151B21F5B6@WSMSG3153V.srv.dir.telstra.com> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: [Json] issues tracker? X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 07 Jun 2013 01:11:52 -0000 U2hvdWxkIHdlIGxpc3QgaXNzdWVzIGluIHRoZSB0cmFja2VyIDxodHRwOi8vdG9vbHMuaWV0Zi5v cmcvd2cvanNvbi90cmFjL3JlcG9ydC8xPj8NClBhcnRpY3VsYXJseSBzaW5jZSBpc3N1ZXMgd2ls bCBub3QgYmUgcmVmbGVjdGVkIGluIGEgZHJhZnQgdW50aWwgYSBjb25zZW5zdXMgY2FsbC4NCiAN Ci0tDQpKYW1lcyBNYW5nZXINCg0KDQo= From duerst@it.aoyama.ac.jp Thu Jun 6 18:41:04 2013 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 7057821F93D4 for ; Thu, 6 Jun 2013 18:41:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.79 X-Spam-Level: X-Spam-Status: No, score=-101.79 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YMXPNmPGrxzl for ; Thu, 6 Jun 2013 18:40:59 -0700 (PDT) Received: from scintmta01.scbb.aoyama.ac.jp (scintmta01.scbb.aoyama.ac.jp [133.2.253.33]) by ietfa.amsl.com (Postfix) with ESMTP id B869721F93C4 for ; Thu, 6 Jun 2013 18:40:57 -0700 (PDT) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta01.scbb.aoyama.ac.jp (secret/secret) with SMTP id r571eop0017613; Fri, 7 Jun 2013 10:40:50 +0900 Received: from (unknown [133.2.206.134]) by scmse02.scbb.aoyama.ac.jp with smtp id 3a18_151e_48c74822_cf13_11e2_aaec_001e6722eec2; Fri, 07 Jun 2013 10:40:50 +0900 Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id 1070BBF521; Fri, 7 Jun 2013 10:39:43 +0900 (JST) Message-ID: <51B13A11.2020809@it.aoyama.ac.jp> Date: Fri, 07 Jun 2013 10:40:33 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: Tim Bray References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Cc: Stephan Beal , "json@ietf.org" Subject: Re: [Json] Introduction X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 07 Jun 2013 01:41:04 -0000 On 2013/06/07 6:36, Tim Bray wrote: > Overthinking. In the introduction, the key thing to get across is that= a > string contains unicode characters. The details of how it=E2=80=99s de= limited and > escaped, and the few characters that are excluded and so on, can go in = the > String section. Assuming we are excluding naked surrogates: > > =E2=80=9CA string is a sequence of Unicode characters.=E2=80=9D We can add in "zero or more" as Douglas proposed. That would make it: "A string is a sequence of zero or more Unicode characters." I think we don't need anything more in the Introduction. Regards, Martin. > > On Thu, Jun 6, 2013 at 2:23 PM, Stephan Beal wr= ote: > >> On Thu, Jun 6, 2013 at 10:24 PM, Joe Hildebrand (jhildebr)< >> jhildebr@cisco.com> wrote: >> >>> A string is a sequence of code points for almost any Unicode characte= r >>> enclosed by double-quotes (QUOTATION MARK, U+0022). >>> >> >> We forgot "... any Unicode character or a JSON character escape >> sequence..." >> >> though that sounds somewhat awkward. >> >> -- >> ----- stephan beal >> http://wanderinghorse.net/home/stephan/ >> http://gplus.to/sgbeal >> >> _______________________________________________ >> json mailing list >> json@ietf.org >> https://www.ietf.org/mailman/listinfo/json >> >> > > > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json From tbray@textuality.com Thu Jun 6 19:06:01 2013 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 ADC651F0D35 for ; Thu, 6 Jun 2013 19:06:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lg6oMtVFijfc for ; Thu, 6 Jun 2013 19:05:57 -0700 (PDT) Received: from mail-vc0-f175.google.com (mail-vc0-f175.google.com [209.85.220.175]) by ietfa.amsl.com (Postfix) with ESMTP id D588D21F9424 for ; Thu, 6 Jun 2013 19:05:56 -0700 (PDT) Received: by mail-vc0-f175.google.com with SMTP id hr11so2412668vcb.20 for ; Thu, 06 Jun 2013 19:05:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=iQjH7B7VBA5yFTAoaN6uGNNskO+nw6mktMBwZ/SH75g=; b=loksNdq6DFgruwivRL+VlWNocv6u0vOOHCSC6smjTR6U1KVMCmTXJoPg/mII+3v2KW tyclVNvDeFFVH+ErYdl5tIw60DP3GlVUwamJp4oKoquIgG/tbkAPMrTlRyxJRR5QUJ7z KHmnzBHETsjF2b7YctK5miDb/PGM/FH4zrlbVQQ8zAqzOx1XpeXjqMgUhoUY/KcTwfyV 4+cMhOhr3+D0f2osN6oDqw+fZSNg2Qzu8wFwtDLJm2dtyJahrl15geboUC0dqbVmiNLr M7R1u73wWVeR020mbSa0fNljNb0z7isM66KspV+dxKyAOzqZzXFidadQjDvQaDygW9zo aOLQ== MIME-Version: 1.0 X-Received: by 10.52.89.234 with SMTP id br10mr19414873vdb.103.1370570755995; Thu, 06 Jun 2013 19:05:55 -0700 (PDT) Received: by 10.220.48.14 with HTTP; Thu, 6 Jun 2013 19:05:55 -0700 (PDT) X-Originating-IP: [209.52.105.121] In-Reply-To: <255B9BB34FB7D647A506DC292726F6E1151B21F57F@WSMSG3153V.srv.dir.telstra.com> References: <38C1C408-3AF4-4CF2-96E1-9544C54B0531@vpnc.org> <255B9BB34FB7D647A506DC292726F6E1151B21F57F@WSMSG3153V.srv.dir.telstra.com> Date: Thu, 6 Jun 2013 19:05:55 -0700 Message-ID: From: Tim Bray To: "Manger, James H" Content-Type: multipart/alternative; boundary=20cf307f37d60d232604de86df43 X-Gm-Message-State: ALoCoQl5XhWRXsYfsrl13OhCS44ieZmNpsdyT8j+0XH8vHu+wQALcChwqYSp7nM4OWGLlwNWCqsg Cc: "json@ietf.org" Subject: Re: [Json] Strings X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 07 Jun 2013 02:06:01 -0000 --20cf307f37d60d232604de86df43 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable +1 to either, I had it backward On Thu, Jun 6, 2013 at 6:03 PM, Manger, James H < James.H.Manger@team.telstra.com> wrote: > > If keys are unicode strings, the proper languagee is: > > =E2=80=9CFor purpose of establishing key equality, comparisons MUST be > conducted, after all escaping is done, on a character-by-character basis = by > comparing numeric character codepoints. There is to be no modification of > any kind to the characters in keys, including case-changing or > combining-form normalization.=E2=80=9D > > > s/after all escaping is done/after all unescaping is done/ > > or should that be > > s/after all escaping is done/after all escaping is undone/ > > -- > James Manger > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > --20cf307f37d60d232604de86df43 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
+1 to either, I had it backward


On Thu, Jun 6, 2013 at 6:03 PM= , Manger, James H <James.H.Manger@team.telstra.com> wrote:
> If keys are unicode s= trings, the proper languagee is:
> =E2=80=9CFor purpose of establishing key equality, comparisons MUST be= conducted, after all escaping is done, on a character-by-character basis b= y comparing numeric character codepoints. There is to be no modification of= any kind to the characters in keys, including case-changing or combining-f= orm normalization.=E2=80=9D


s/after all escaping is done/after all unescaping is done/

or should that be

s/after all escaping is done/after all escaping is undone/

--
James Manger
___________________________________= ____________
json mailing list
json@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/json

--20cf307f37d60d232604de86df43-- From paul.hoffman@vpnc.org Thu Jun 6 19:12:19 2013 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 725F221F9193 for ; Thu, 6 Jun 2013 19:12:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.261 X-Spam-Level: X-Spam-Status: No, score=-102.261 tagged_above=-999 required=5 tests=[AWL=0.338, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jP44xwQgvvwm for ; Thu, 6 Jun 2013 19:12:19 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id F372521F8C38 for ; Thu, 6 Jun 2013 19:12:18 -0700 (PDT) Received: from [10.20.30.90] (50-0-66-165.dsl.dynamic.sonic.net [50.0.66.165]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r572CH2m053526 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 6 Jun 2013 19:12:18 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Paul Hoffman In-Reply-To: <255B9BB34FB7D647A506DC292726F6E1151B21F5B6@WSMSG3153V.srv.dir.telstra.com> Date: Thu, 6 Jun 2013 19:12:17 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <7389C161-04C8-432F-B229-A25765894737@vpnc.org> References: <255B9BB34FB7D647A506DC292726F6E1151B21F5B6@WSMSG3153V.srv.dir.telstra.com> To: "Manger, James H" X-Mailer: Apple Mail (2.1508) Cc: "json@ietf.org" Subject: Re: [Json] issues tracker? X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 07 Jun 2013 02:12:19 -0000 On Jun 6, 2013, at 6:11 PM, "Manger, James H" = wrote: > Should we list issues in the tracker = ? > Particularly since issues will not be reflected in a draft until a = consensus call. See the first message after we became a WG. The chairs are tracking (as = best we can) the threads and will watch for them to calm down, then we = will reignite them before the consensus call. If we miss stuff, we're = sure you'll tell us. My experience with WGs with trackers is that they split the focus = between the mailing list and the tracker. That would suck here, given = the active back-and-forth we are seeing. Matt and I are open to changing the process, but give us a few weeks and = a few consensus calls before you decide we can't handle this. --Paul Hoffman= From James.H.Manger@team.telstra.com Thu Jun 6 19:24:57 2013 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 6A8BB21F8D10 for ; Thu, 6 Jun 2013 19:24:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.297 X-Spam-Level: X-Spam-Status: No, score=-0.297 tagged_above=-999 required=5 tests=[AWL=0.604, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Uy8aL+BoYZY for ; Thu, 6 Jun 2013 19:24:51 -0700 (PDT) Received: from ipxavo.tcif.telstra.com.au (ipxavo.tcif.telstra.com.au [203.35.135.200]) by ietfa.amsl.com (Postfix) with ESMTP id E97C821F8D16 for ; Thu, 6 Jun 2013 19:24:50 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.87,818,1363093200"; d="scan'208";a="139646852" Received: from unknown (HELO ipccvi.tcif.telstra.com.au) ([10.97.217.208]) by ipoavi.tcif.telstra.com.au with ESMTP; 07 Jun 2013 12:24:49 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,7098"; a="136984922" Received: from wsmsg3756.srv.dir.telstra.com ([172.49.40.84]) by ipccvi.tcif.telstra.com.au with ESMTP; 07 Jun 2013 12:24:49 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3756.srv.dir.telstra.com ([172.49.40.84]) with mapi; Fri, 7 Jun 2013 12:24:48 +1000 From: "Manger, James H" To: "Joe Hildebrand (jhildebr)" , "json@ietf.org" Date: Fri, 7 Jun 2013 12:24:47 +1000 Thread-Topic: ABNF nits Thread-Index: AQHOYxhuLNPlu69CpUeh/eSpf1GKTZkpg97A Message-ID: <255B9BB34FB7D647A506DC292726F6E1151B21F79E@WSMSG3153V.srv.dir.telstra.com> References: In-Reply-To: Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [Json] ABNF nits X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 07 Jun 2013 02:24:57 -0000 PiBTb21lIHRoaW5ncyBJIGZvdW5kIGZ1dHppbmcgd2l0aCB0aGUgQUJORjoNCj4gDQo+IC0gbm9y bWFsaXplIHRoZSBpbmRlbnRhdGlvbiAobWFrZXMgaXQgZWFzaWVyIHRvIHB1bGwgb3V0KQ0KPiAt IEhleCBsaXRlcmFscyBuZWVkIHRvIGJlIHVwcGVyY2FzZS4gIFRoZSBmYWxzZSBhbmQgbnVsbCBy dWxlcyBhcmUNCj4gd3JvbmcuDQoNCkxvd2VyY2FzZSBpcyBhbGxvd2VkIGluIGhleCBsaXRlcmFs cy4NCkl0IGxpbmtzIGJhY2sgdG8gSEVYRElHIGluIFJGQzUyMzQgKG9yIFJGQyA0MjM0KS4NCllv dSBoYXZlIHRvIHJlbWVtYmVyIHRoZSBzbmVha3kgQUJORiBydWxlIHRoYXQgcXVvdGVkIHN0cmlu Z3MgKGVnICJBIikgYXJlIGNhc2UgaW5zZW5zaXRpdmUuICJBIiBpcyBlcXVpdmFsZW50IHRvICV4 NDEgLyAleDYxLg0KDQo+IC0gRElHSVQgYW5kIEhFWERJRyBhcmUgbmVpdGhlciBkZWZpbmVkIG5v ciBpbXBvcnRlZCwgYXMgZmFyIGFzIEkgY2FuDQo+IHRlbGwuDQo+ICBJIHN1Z2dlc3Q6DQo+IA0K PiBESUdJVCA9ICV4MzAtMzkgICAgICAgICAgICAgICAgICAgICAgICA7IDAtOQ0KPiBIRVhESUcg PSAleDMwLTM5IC8gJXg0MS00NiAvICV4NjEtNjYgICA7IDAtOSwgQS1GLCBvciBhLWYNCg0K From jhildebr@cisco.com Thu Jun 6 19:39:31 2013 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 6C6AA21F91B1 for ; Thu, 6 Jun 2013 19:39:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fZssLThNQ92z for ; Thu, 6 Jun 2013 19:39:25 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id CCAEF21F9121 for ; Thu, 6 Jun 2013 19:39:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=987; q=dns/txt; s=iport; t=1370572765; x=1371782365; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=LhiIQUa5+1l+EZYg5+gv++iXkZbMPPUlGmm7IQfkCcw=; b=iqV44Pi9k1eqZT8VOFhfXdB9P0FXvRfLmRBXBxJn8DTH1lP2WXp/h4jD irfbq7PN1vl8KFK/bKmrQJAuW5hW4sTnk6y+955ZyTR+vO+woJWm0GS9n SgcAWyr4qwHS2RokLF0aqvjWqZBrnJY9p6OZqJgt7hd2k4PWqufr9KuQA Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiQFAGdHsVGtJV2a/2dsb2JhbABZgwmDJbt8fBZ0giMBAQEDATpRAQgiFEIlAgQBEgiHcwMJBrMAHYhCjwE4gnphA6h/gw+CJw X-IronPort-AV: E=Sophos;i="4.87,818,1363132800"; d="scan'208";a="219935555" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-4.cisco.com with ESMTP; 07 Jun 2013 02:39:25 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r572dPZK005101 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 7 Jun 2013 02:39:25 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.56]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.02.0318.004; Thu, 6 Jun 2013 21:39:24 -0500 From: "Joe Hildebrand (jhildebr)" To: "Manger, James H" , "json@ietf.org" Thread-Topic: ABNF nits Thread-Index: AQHOYxhuLNPlu69CpUeh/eSpf1GKTZkpg97A///1nAA= Date: Fri, 7 Jun 2013 02:39:24 +0000 Message-ID: In-Reply-To: <255B9BB34FB7D647A506DC292726F6E1151B21F79E@WSMSG3153V.srv.dir.telstra.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [10.21.88.234] Content-Type: text/plain; charset="us-ascii" Content-ID: <48B4847B79ECC540A3F7678EC1DA8045@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Json] ABNF nits X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 07 Jun 2013 02:39:31 -0000 On 6/6/13 8:24 PM, "Manger, James H" wrote: >> Some things I found futzing with the ABNF: >>=20 >> - normalize the indentation (makes it easier to pull out) >> - Hex literals need to be uppercase. The false and null rules are >> wrong. > >Lowercase is allowed in hex literals. >It links back to HEXDIG in RFC5234 (or RFC 4234). >You have to remember the sneaky ABNF rule that quoted strings (eg "A") >are case insensitive. "A" is equivalent to %x41 / %x61. Crap. I didn't see that because it's in a "Note:" in section 2.3. Regardless, we should change both of those rules for consistency with the rest of the doc. >> - DIGIT and HEXDIG are neither defined nor imported, as far as I can >> tell. >> I suggest: >>=20 >> DIGIT =3D %x30-39 ; 0-9 >> HEXDIG =3D %x30-39 / %x41-46 / %x61-66 ; 0-9, A-F, or a-f I still recommend being explicit about this, like the rule for e. --=20 Joe Hildebrand From sayrer@gmail.com Thu Jun 6 19:59:39 2013 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 AF8E611E80C5 for ; Thu, 6 Jun 2013 19:59:39 -0700 (PDT) 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=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7X0PlpqmvhbA for ; Thu, 6 Jun 2013 19:59:39 -0700 (PDT) Received: from mail-qa0-x22c.google.com (mail-qa0-x22c.google.com [IPv6:2607:f8b0:400d:c00::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 1D64111E80A4 for ; Thu, 6 Jun 2013 19:59:39 -0700 (PDT) Received: by mail-qa0-f44.google.com with SMTP id j8so781009qah.3 for ; Thu, 06 Jun 2013 19:59:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=yCcUT7mWQQIyFqVnOuzyLZplaUGRDUtZdPPAy96HFwc=; b=xcNTia23lT4qoB+PJRoPrJ6Lrp1goe/htof0qlAnlcZebUD1qMYLKcxBPgYogql825 pAofjYqgRSGeZs1cpJ1oUVJLRK2McTy+cke2DB4dQvYT1g1w0WOtvk5h49Xb8NCI9YLn EBoaX2GQWWSd8HjwTodnsX9o7Mi4RIxs0e5FsEdJ9qesnNVwaapCR+sZMK9FLdlqEt5Y lPjB1tTAc+mn0s/Nbjlu6VUxW+4iwBbHeAuay0j5FFqIOal/64eCntCeUjUJB1PWqqY8 TqZUkg/mxRj6i95r6f4kGJp3CIoNPN7bE2TyfkZgaSoSNhwlXGsHM4f0OE1urMso65Ec KqxA== MIME-Version: 1.0 X-Received: by 10.224.189.194 with SMTP id df2mr536568qab.97.1370573978590; Thu, 06 Jun 2013 19:59:38 -0700 (PDT) Received: by 10.224.178.1 with HTTP; Thu, 6 Jun 2013 19:59:38 -0700 (PDT) In-Reply-To: References: <51AF8479.5080002@crockford.com> <51b1168c.e686440a.5339.5fc4SMTPIN_ADDED_BROKEN@mx.google.com> Date: Thu, 6 Jun 2013 19:59:38 -0700 Message-ID: From: R S To: Nico Williams Content-Type: multipart/alternative; boundary=20cf300fb40121e54304de879f07 Cc: Markus Lanthaler , "json@ietf.org" Subject: Re: [Json] The names within an object SHOULD be unique. X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 07 Jun 2013 02:59:39 -0000 --20cf300fb40121e54304de879f07 Content-Type: text/plain; charset=ISO-8859-1 JSON is sometimes produced by naive string concatenation, which will probably never change. It is consumed by browsers, which will probably never change their duplicate key handling. The text from RFC 4627 should stay unchanged. The suggestions for requirements on encoders are prescriptive and therefore inaccurate at this stage in JSON's adoption. - Rob On Thu, Jun 6, 2013 at 5:13 PM, Nico Williams wrote: > > On Jun 6, 2013 6:09 PM, "Markus Lanthaler" > wrote: > > > > On Sent: Friday, June 07, 2013 12:22 AM, Nico Williams wrote: > > > Having thought this far, I propose this text: > > > > > > Encoders SHOULD NOT send duplicate keys. Some encoders might not > > > be able to prevent duplicate keys. Therefore parsers MUST be prepared > > > to handle duplicate keys. > > > > -1, it is very reasonable to reject such JSON. > > I wrote "handle", not "accept". > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > > --20cf300fb40121e54304de879f07 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
JSON is sometimes produced by naive string concatenation, = which will probably never change. It is consumed by browsers, which will pr= obably never change their duplicate key handling.

The te= xt from RFC 4627 should stay unchanged. The suggestions for requirements on= encoders are prescriptive and therefore inaccurate at this stage in JSON&#= 39;s adoption.

- Rob
=A0


On Thu, Jun 6, 2013 at 5:13 PM, Nico = Williams <nico@cryptonector.com> wrote:


On Jun 6, 2013 6:09 PM, "Markus Lanthaler" <markus.lanthaler@gmx.net>= ; wrote:
>
> On Sent: Friday, June 07, 2013 12:22 AM, Nico Williams wrote:
> > Having thought this far, I propose this text:
> >
> > =A0 =A0Encoders SHOULD NOT send duplicate keys. =A0Some encoders = might not
> > be able to prevent duplicate keys. =A0Therefore parsers MUST be p= repared
> > to handle duplicate keys.
>
> -1, it is very reasonable to reject such JSON.

I wrote "handle", not "accept".


_______________________________________________
json mailing list
json@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/json


--20cf300fb40121e54304de879f07-- From tbray@textuality.com Thu Jun 6 20:08:08 2013 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 5E02C21F8F69 for ; Thu, 6 Jun 2013 20:08:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nhgrdAL68tkJ for ; Thu, 6 Jun 2013 20:08:03 -0700 (PDT) Received: from mail-vc0-f175.google.com (mail-vc0-f175.google.com [209.85.220.175]) by ietfa.amsl.com (Postfix) with ESMTP id B15F521F8F61 for ; Thu, 6 Jun 2013 20:08:00 -0700 (PDT) Received: by mail-vc0-f175.google.com with SMTP id hr11so2436115vcb.20 for ; Thu, 06 Jun 2013 20:07:59 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=qKmiAnrs+HyyCmC8Zc4QJ99+N1AW6WZ0qQ9Yt/VkZ2U=; b=FpOyytihow2XCZTTfWT7fybmhMXUCbc1rHPdzZnvc4YKbXsZkJ5C7FVnV7IkEhj1q6 hj6I8/+c7t7cGBZnSiwuv1GRluQ13PkUJWx4ShrCvmqmLVwDwAX+H23XjQm3T3igRltX UQC1MXbRG4ew2RnSpYTEnxOVwBwchTjIqXmAe/A92v+UUwxUUknwyJVEavGZvVLhiqcp 0xs6krtOUndnORY8dpqXtfavqiaxDenYgc5gT4O+ufPJYJsorhVwCmL3pal7LEoSk9J9 KuQo6ULQnNQPwv1npOdCfpfoZORMGLC01IlSuIX27i9JuTH4sNn2XCul4CIFfBPHmi+B 1Cpw== MIME-Version: 1.0 X-Received: by 10.58.248.39 with SMTP id yj7mr22628065vec.53.1370574045300; Thu, 06 Jun 2013 20:00:45 -0700 (PDT) Received: by 10.220.48.14 with HTTP; Thu, 6 Jun 2013 20:00:45 -0700 (PDT) X-Originating-IP: [209.52.105.121] In-Reply-To: References: <51AF8479.5080002@crockford.com> <51b1168c.e686440a.5339.5fc4SMTPIN_ADDED_BROKEN@mx.google.com> Date: Thu, 6 Jun 2013 20:00:45 -0700 Message-ID: From: Tim Bray To: R S Content-Type: multipart/alternative; boundary=047d7bdc85241bf7d204de87a305 X-Gm-Message-State: ALoCoQmzH3OknpQ7gBir584JPp9EK1Xo8Y1v7lYJ4HfvDmfkGy06aEMKTL2rqCEjBNRjtC8/ymNK Cc: Nico Williams , Markus Lanthaler , "json@ietf.org" Subject: Re: [Json] The names within an object SHOULD be unique. X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 07 Jun 2013 03:08:08 -0000 --047d7bdc85241bf7d204de87a305 Content-Type: text/plain; charset=UTF-8 +1. I am highly unconvinced that this -bis effort really has anything useful to add in this area. -T On Thu, Jun 6, 2013 at 7:59 PM, R S wrote: > JSON is sometimes produced by naive string concatenation, which will > probably never change. It is consumed by browsers, which will probably > never change their duplicate key handling. > > The text from RFC 4627 should stay unchanged. The suggestions for > requirements on encoders are prescriptive and therefore inaccurate at this > stage in JSON's adoption. > > - Rob > > > > On Thu, Jun 6, 2013 at 5:13 PM, Nico Williams wrote: > >> >> On Jun 6, 2013 6:09 PM, "Markus Lanthaler" >> wrote: >> > >> > On Sent: Friday, June 07, 2013 12:22 AM, Nico Williams wrote: >> > > Having thought this far, I propose this text: >> > > >> > > Encoders SHOULD NOT send duplicate keys. Some encoders might not >> > > be able to prevent duplicate keys. Therefore parsers MUST be prepared >> > > to handle duplicate keys. >> > >> > -1, it is very reasonable to reject such JSON. >> >> I wrote "handle", not "accept". >> >> _______________________________________________ >> 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 > > --047d7bdc85241bf7d204de87a305 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
+1. I am highly unconvinced that this -bis effort really h= as anything useful to add in this area.=C2=A0 -T


On Thu, Jun 6, 2013 at 7:59 PM= , R S <sayrer@gmail.com> wrote:
JSON is sometimes produced = by naive string concatenation, which will probably never change. It is cons= umed by browsers, which will probably never change their duplicate key hand= ling.

The text from RFC 4627 should stay unchanged. The suggestion= s for requirements on encoders are prescriptive and therefore inaccurate at= this stage in JSON's adoption.

- Rob
=C2=A0


On Thu, Jun 6, 2013 at 5:13 PM, Ni= co Williams <nico@cryptonector.com> wrote:


On Jun 6, 2013 6:09 PM, "Markus Lanthaler" <markus.lanthaler@gmx.net>= ; wrote:
>
> On Sent: Friday, June 07, 2013 12:22 AM, Nico Williams wrote:
> > Having thought this far, I propose this text:
> >
> > =C2=A0 =C2=A0Encoders SHOULD NOT send duplicate keys. =C2=A0Some = encoders might not
> > be able to prevent duplicate keys. =C2=A0Therefore parsers MUST b= e prepared
> > to handle duplicate keys.
>
> -1, it is very reasonable to reject such JSON.

I wrote "handle", not "accept".


_______________________________________________
json mailing list
json@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/json



_______________________________________________
json mailing list
json@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/json


--047d7bdc85241bf7d204de87a305-- From jsontest@yahoo.com Thu Jun 6 20:15:20 2013 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 367DD21F909A for ; Thu, 6 Jun 2013 20:15:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u9L6wKOr8xoe for ; Thu, 6 Jun 2013 20:15:14 -0700 (PDT) Received: from nm7-vm2.bullet.mail.gq1.yahoo.com (nm7-vm2.bullet.mail.gq1.yahoo.com [98.136.218.209]) by ietfa.amsl.com (Postfix) with ESMTP id 7FD8221F90A5 for ; Thu, 6 Jun 2013 20:15:14 -0700 (PDT) Received: from [98.137.12.175] by nm7.bullet.mail.gq1.yahoo.com with NNFMP; 07 Jun 2013 03:15:13 -0000 Received: from [208.71.42.207] by tm14.bullet.mail.gq1.yahoo.com with NNFMP; 07 Jun 2013 03:15:13 -0000 Received: from [127.0.0.1] by smtp218.mail.gq1.yahoo.com with NNFMP; 07 Jun 2013 03:15:13 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1370574913; bh=4hFXKHIH7B4IF2s80nqlS6ViE7UB8K1e7KHkeXvlr8c=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:References:In-Reply-To:Mime-Version:Content-Transfer-Encoding:Content-Type:Message-Id:Cc:X-Mailer:From:Subject:Date:To; b=rIB77QvGcSLBBjuO1Io2DABak03Rs8gFaj+Bxf6k+7HQoa026FqKDC0/mnubInZSNiy9QmBbbEYT9pg+KFERXwTltkeNJ/0CWzin1llA5WsOqoPVfMVf1y3bSwk9qcaPi7wHkpTPhCMHnM3FScXbIZ8QA6DECINfQbgnAFDT4uA= X-Yahoo-Newman-Id: 280900.29204.bm@smtp218.mail.gq1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: Jdrlr1cVM1kphU6ImcqR8vbucmuNpvfAb0Cp9jteNK6n6mA rQq84AgOs0j7PUj0Fey9uDzREC3mRvV_xk1pr7wLxcSjAc7ekc3WAZfw1_VY tKPCR7atS5wE5x9Cb6B.tK3Fb1vFPRw58X7d8GtZ9sYTKfxO7OvMVzts36lz JLvwUzVXw_qEai0Ob_vWsdfdKVnAqhCIb6e5vfQiiZDxjNZd0Tj0UqHeq87h 8oDD1qBTI3D_p5_MhanaHiVPHEvgO0RO3Wjk5hj35iqLKV15Cnap5qvo7pmr 3BLcHF_gqw52Ff0MGKPlctrFU1lGF6FPBPtGJPa.eZDQXtF_hoHH3aH4teLm dHLfpXS1cCYACV3oCZn.pklmvFQRVRNN0ueuhAGUPw7cwGgOQHY3d2Bjcs.v AgcRfjxD3qF.XailophkMfQauV7ffcZUrvNCIoufZd8P7_sIRXOFslzbbx2p j02fbeyEFD3n1d0w4ye8xwfHLlfXxS8yWp0_k6BQlMCchIwd4ASxkUTXihti hrxJGpaSAaWi3FetuV7a59u6n X-Yahoo-SMTP: indQcmSswBC8IKsm6t4aCAPskK3T X-Rocket-Received: from [192.168.0.102] (jsontest@76.29.100.42 with ) by smtp218.mail.gq1.yahoo.com with SMTP; 07 Jun 2013 03:15:13 +0000 UTC References: <51AF8479.5080002@crockford.com> <8DF516C4-109F-487D-84C8-DC1AEF04A324@vpnc.org> In-Reply-To: <8DF516C4-109F-487D-84C8-DC1AEF04A324@vpnc.org> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPod Mail (9B206) From: Vinny A Date: Thu, 6 Jun 2013 22:15:07 -0500 To: Paul Hoffman Cc: "json@ietf.org" Subject: Re: [Json] The names within an object SHOULD be unique. X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 07 Jun 2013 03:15:20 -0000 On Jun 6, 2013, at 5:58 PM, Paul Hoffman wrote: > > Proposal: we simply list what we want encoders and parsers to do without s= aying what type of encoder, or what type of parser, gets to do what. +1, while also saying that I would like to revisit this discussion (and also= the discussion on comments) when writing the best practices doc. ----------------- Vinny www.jsontest.com= From James.H.Manger@team.telstra.com Thu Jun 6 20:16:08 2013 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 B826021F9050 for ; Thu, 6 Jun 2013 20:16:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.364 X-Spam-Level: X-Spam-Status: No, score=-0.364 tagged_above=-999 required=5 tests=[AWL=0.537, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w6+VB19lfWEJ for ; Thu, 6 Jun 2013 20:16:02 -0700 (PDT) Received: from ipxbvo.tcif.telstra.com.au (ipxbvo.tcif.telstra.com.au [203.35.135.204]) by ietfa.amsl.com (Postfix) with ESMTP id D217E21F90A5 for ; Thu, 6 Jun 2013 20:15:54 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.87,819,1363093200"; d="scan'208";a="140016758" Received: from unknown (HELO ipcavi.tcif.telstra.com.au) ([10.97.217.200]) by ipobvi.tcif.telstra.com.au with ESMTP; 07 Jun 2013 13:15:50 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,7098"; a="189240457" Received: from wsmsg3703.srv.dir.telstra.com ([172.49.40.171]) by ipcavi.tcif.telstra.com.au with ESMTP; 07 Jun 2013 13:15:50 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3703.srv.dir.telstra.com ([172.49.40.171]) with mapi; Fri, 7 Jun 2013 13:15:49 +1000 From: "Manger, James H" To: "Joe Hildebrand (jhildebr)" , "json@ietf.org" Date: Fri, 7 Jun 2013 13:15:48 +1000 Thread-Topic: ABNF nits Thread-Index: AQHOYxhuLNPlu69CpUeh/eSpf1GKTZkpg97A///1nACAABksoA== Message-ID: <255B9BB34FB7D647A506DC292726F6E1151B21F8CA@WSMSG3153V.srv.dir.telstra.com> References: <255B9BB34FB7D647A506DC292726F6E1151B21F79E@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [Json] ABNF nits X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 07 Jun 2013 03:16:09 -0000 PiA+PiBTb21lIHRoaW5ncyBJIGZvdW5kIGZ1dHppbmcgd2l0aCB0aGUgQUJORjoNCj4gPj4NCj4g Pj4gLSBub3JtYWxpemUgdGhlIGluZGVudGF0aW9uIChtYWtlcyBpdCBlYXNpZXIgdG8gcHVsbCBv dXQpDQo+ID4+IC0gSGV4IGxpdGVyYWxzIG5lZWQgdG8gYmUgdXBwZXJjYXNlLiAgVGhlIGZhbHNl IGFuZCBudWxsIHJ1bGVzIGFyZQ0KPiA+PiB3cm9uZy4NCj4gPg0KPiA+TG93ZXJjYXNlIGlzIGFs bG93ZWQgaW4gaGV4IGxpdGVyYWxzLg0KPiA+SXQgbGlua3MgYmFjayB0byBIRVhESUcgaW4gUkZD NTIzNCAob3IgUkZDIDQyMzQpLg0KPiA+WW91IGhhdmUgdG8gcmVtZW1iZXIgdGhlIHNuZWFreSBB Qk5GIHJ1bGUgdGhhdCBxdW90ZWQgc3RyaW5ncyAoZWcgIkEiKQ0KPiA+YXJlIGNhc2UgaW5zZW5z aXRpdmUuICJBIiBpcyBlcXVpdmFsZW50IHRvICV4NDEgLyAleDYxLg0KPiANCj4gQ3JhcC4gIEkg ZGlkbid0IHNlZSB0aGF0IGJlY2F1c2UgaXQncyBpbiBhICJOb3RlOiIgaW4gc2VjdGlvbiAyLjMu DQoNCkkgZGlkbid0IGNhbGwgaXQgInNuZWFreSIgZm9yIG5vdGhpbmcgOykNCg0KPiBSZWdhcmRs ZXNzLCB3ZSBzaG91bGQgY2hhbmdlICBib3RoIG9mIHRob3NlIHJ1bGVzIGZvciBjb25zaXN0ZW5j eSB3aXRoDQo+IHRoZSByZXN0IG9mIHRoZSBkb2MuDQo+IA0KPiA+PiAtIERJR0lUIGFuZCBIRVhE SUcgYXJlIG5laXRoZXIgZGVmaW5lZCBub3IgaW1wb3J0ZWQsIGFzIGZhciBhcyBJIGNhbg0KPiA+ PiB0ZWxsLg0KPiA+PiAgSSBzdWdnZXN0Og0KPiA+Pg0KPiA+PiBESUdJVCA9ICV4MzAtMzkgICAg ICAgICAgICAgICAgICAgICAgICA7IDAtOQ0KPiA+PiBIRVhESUcgPSAleDMwLTM5IC8gJXg0MS00 NiAvICV4NjEtNjYgICA7IDAtOSwgQS1GLCBvciBhLWYNCj4gDQo+IEkgc3RpbGwgcmVjb21tZW5k IGJlaW5nIGV4cGxpY2l0IGFib3V0IHRoaXMsIGxpa2UgdGhlIHJ1bGUgZm9yIGUuDQoNCkkgYWdy ZWUuDQpBZGQgRElHSVQgYW5kIEhFWERJRyB0byB0aGUgZG9jIHNvIGFsbCB0aGUgQUJORiBpcyBw cmVzZW50Lg0KVXNlIHlvdXIgZGVmaW5pdGlvbiBvZiBIRVhESUcgYWJvdmUsIG5vdCB0aGUgUkZD NTIzNCBvbmUsIHRvIGF2b2lkIHRoZSBzbmVha3kgQUJORiBydWxlLg0KT3B0aW9uYWxseSBhZGQg YSBub3RlICI7IERJR0lUIGFuZCBIRVhESUcgYXJlIGVxdWl2YWxlbnQgdG8gcnVsZXMgd2l0aCB0 aGUgc2FtZSBuYW1lcyBpbiBbUkZDNTIzNF0iLg0KDQotLQ0KSmFtZXMgTWFuZ2VyDQo= From James.H.Manger@team.telstra.com Thu Jun 6 20:51:26 2013 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 157AD21F9285 for ; Thu, 6 Jun 2013 20:51:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.418 X-Spam-Level: X-Spam-Status: No, score=-0.418 tagged_above=-999 required=5 tests=[AWL=0.483, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zIG1Exnb11RV for ; Thu, 6 Jun 2013 20:51:17 -0700 (PDT) Received: from ipxavo.tcif.telstra.com.au (ipxavo.tcif.telstra.com.au [203.35.135.200]) by ietfa.amsl.com (Postfix) with ESMTP id 0602321F848A for ; Thu, 6 Jun 2013 20:51:12 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.87,819,1363093200"; d="scan'208";a="139662322" Received: from unknown (HELO ipccvi.tcif.telstra.com.au) ([10.97.217.208]) by ipoavi.tcif.telstra.com.au with ESMTP; 07 Jun 2013 13:51:12 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,7098"; a="137000694" Received: from wsmsg3753.srv.dir.telstra.com ([172.49.40.174]) by ipccvi.tcif.telstra.com.au with ESMTP; 07 Jun 2013 13:51:11 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3753.srv.dir.telstra.com ([172.49.40.174]) with mapi; Fri, 7 Jun 2013 13:51:11 +1000 From: "Manger, James H" To: "json@ietf.org" Date: Fri, 7 Jun 2013 13:51:09 +1000 Thread-Topic: Allow any JSON value at the top level Thread-Index: Ac5jMj7wK5i9s5prS+2npykXIGILbg== Message-ID: <255B9BB34FB7D647A506DC292726F6E1151B21F9A9@WSMSG3153V.srv.dir.telstra.com> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: [Json] Allow any JSON value at the top level X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 07 Jun 2013 03:51:26 -0000 VGhlIGN1cnJlbnQgc3BlYyBvbmx5IGFsbG93cyBhIEpTT04gdGV4dCB0byBiZSBhbiBvYmplY3Qg b3IgYXJyYXkuIFNlY3Rpb24gMi4gIkpTT04gR3JhbW1hciIgc2F5czoNCg0KICAgQSBKU09OIHRl eHQgaXMgYSBzZXJpYWxpemVkIG9iamVjdCBvciBhcnJheS4NCg0KICAgSlNPTi10ZXh0ID0gb2Jq ZWN0IC8gYXJyYXkNCg0KDQpJIHByb3Bvc2UgYWxsb3dpbmcgYSBKU09OIHRleHQgdG8gYmUgYW55 IEpTT04gdmFsdWUuDQoNCiAgIEEgSlNPTiB0ZXh0IGlzIGEgc2VyaWFsaXphdGlvbiBvZiBhbnkg SlNPTiB2YWx1ZS4NCg0KICAgSlNPTi10ZXh0ID0gdmFsdWUNCg0KICAgdmFsdWUgPSBmYWxzZSAv IG51bGwgLyB0cnVlIC8gb2JqZWN0IC8gYXJyYXkgLyBudW1iZXIgLyBzdHJpbmcNCg0KDQpFQ01B U2NyaXB0IGFscmVhZHkgYWxsb3dzIHRoaXMuIGh0dHA6Ly93d3cuZWNtYS1pbnRlcm5hdGlvbmFs Lm9yZy9lY21hLTI2Mi81LjEvI3NlYy0xNS4xMg0KDQogICAqIFRoZSB0b3AgbGV2ZWwgSlNPTlRl eHQgcHJvZHVjdGlvbiBvZiB0aGUgRUNNQVNjcmlwdCBKU09OIGdyYW1tYXINCiAgICAgbWF5IGNv bnNpc3Qgb2YgYW55IEpTT05WYWx1ZSByYXRoZXIgdGhhbiBiZWluZyByZXN0cmljdGVkIHRvIGJl aW5nDQogICAgIGEgSlNPTk9iamVjdCBvciBhIEpTT05BcnJheSBhcyBzcGVjaWZpZWQgYnkgUkZD IDQ2MjcuDQoNCi0tDQpKYW1lcyBNYW5nZXINCg0KDQo= From sayrer@gmail.com Thu Jun 6 20:54:45 2013 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 240C021F8DDD for ; Thu, 6 Jun 2013 20:54:45 -0700 (PDT) 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=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0cFUoNADKMw3 for ; Thu, 6 Jun 2013 20:54:39 -0700 (PDT) Received: from mail-qa0-x236.google.com (mail-qa0-x236.google.com [IPv6:2607:f8b0:400d:c00::236]) by ietfa.amsl.com (Postfix) with ESMTP id 65AF11F0D37 for ; Thu, 6 Jun 2013 20:54:22 -0700 (PDT) Received: by mail-qa0-f54.google.com with SMTP id n20so799961qaj.20 for ; Thu, 06 Jun 2013 20:54:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=4JN50hZHYTj3YXHazAdPzT4nVZtjgmwJl1Yhf8zq548=; b=WKOHOu3zfGzBVHri7O0cQ5I98hBZd77k5MWrciUg89sMs8Zo7TODq1ubN1PR7gY4TR 2NOA9dNyHfVSUEtuDbk51ML1/81okH06W796NTtzHrJc5BKgU1y4y/ws6+MEs38l0iyY rAVCsYX7CWMJlrBnH5y7qvUW7H0R1tFhjRDkh5DrlpIbfPXp/MXPEwCLeJnYCmpGbs+e yhaYmC0i1Onh/jKJRD5Xrnezjhkl6dz5YmwlFc+ddodYEdIUc6Sg2yZEQe60Tp9hlB7W nhI1bbAJCTQHajwtvYczvk/yJ1jabO0mbDsCFpGFeM5EcWca/0UccOGBI7gQfCjX56a9 +u/Q== MIME-Version: 1.0 X-Received: by 10.229.69.34 with SMTP id x34mr14481226qci.75.1370577259897; Thu, 06 Jun 2013 20:54:19 -0700 (PDT) Received: by 10.224.178.1 with HTTP; Thu, 6 Jun 2013 20:54:19 -0700 (PDT) In-Reply-To: <255B9BB34FB7D647A506DC292726F6E1151B21F9A9@WSMSG3153V.srv.dir.telstra.com> References: <255B9BB34FB7D647A506DC292726F6E1151B21F9A9@WSMSG3153V.srv.dir.telstra.com> Date: Thu, 6 Jun 2013 20:54:19 -0700 Message-ID: From: R S To: "Manger, James H" Content-Type: multipart/alternative; boundary=00032557fa1eb6b34404de8862c3 Cc: "json@ietf.org" Subject: Re: [Json] Allow any JSON value at the top level X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 07 Jun 2013 03:54:45 -0000 --00032557fa1eb6b34404de8862c3 Content-Type: text/plain; charset=ISO-8859-1 I support this change. It is required in interoperable implementations. On Thu, Jun 6, 2013 at 8:51 PM, Manger, James H < James.H.Manger@team.telstra.com> wrote: > The current spec only allows a JSON text to be an object or array. Section > 2. "JSON Grammar" says: > > A JSON text is a serialized object or array. > > JSON-text = object / array > > > I propose allowing a JSON text to be any JSON value. > > A JSON text is a serialization of any JSON value. > > JSON-text = value > > value = false / null / true / object / array / number / string > > > ECMAScript already allows this. > http://www.ecma-international.org/ecma-262/5.1/#sec-15.12 > > * The top level JSONText production of the ECMAScript JSON grammar > may consist of any JSONValue rather than being restricted to being > a JSONObject or a JSONArray as specified by RFC 4627. > > -- > James Manger > > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > --00032557fa1eb6b34404de8862c3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I support this change. It is required in interoperable imp= lementations.


On Thu, Jun 6, 2013 at 8:51 PM, Manger, James H <= ;James= .H.Manger@team.telstra.com> wrote:
The current spec only allows a JSON text to = be an object or array. Section 2. "JSON Grammar" says:

=A0 =A0A JSON text is a serialized object or array.

=A0 =A0JSON-text =3D object / array


I propose allowing a JSON text to be any JSON value.

=A0 =A0A JSON text is a serialization of any JSON value.

=A0 =A0JSON-text =3D value

=A0 =A0value =3D false / null / true / object / array / number / string


ECMAScript already allows this. http://www.ecma-international.= org/ecma-262/5.1/#sec-15.12

=A0 =A0* The top level JSONText production of the ECMAScript JSON grammar =A0 =A0 =A0may consist of any JSONValue rather than being restricted to bei= ng
=A0 =A0 =A0a JSONObject or a JSONArray as specified by RFC 4627.

--
James Manger


_______________________________________________
json mailing list
json@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/json

--00032557fa1eb6b34404de8862c3-- From peter.h.m.brooks@gmail.com Thu Jun 6 23:23:11 2013 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 791BC21F91B7 for ; Thu, 6 Jun 2013 23:23:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8JIUom1yniZA for ; Thu, 6 Jun 2013 23:23:06 -0700 (PDT) Received: from mail-qe0-f53.google.com (mail-qe0-f53.google.com [209.85.128.53]) by ietfa.amsl.com (Postfix) with ESMTP id B69BA21F90F4 for ; Thu, 6 Jun 2013 23:23:02 -0700 (PDT) Received: by mail-qe0-f53.google.com with SMTP id 1so2482737qee.40 for ; Thu, 06 Jun 2013 23:23:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=i3rPYso+cNW3i+ccPlAFu1b6pRwSHV19EMz1weLdk/U=; b=oE6tBoUEvsn19Xqj8/fh1s085A0ns5Kt3CoMzSF4IkUlTuJlWAPQeCBt8S7bFEimGu 6W3YHIM0tia9OxIPFznoqLXyJBcFpJzzykyDF1i70aXGAhYocCCf8cc3J5a34eq5P2Qo pgcEYmkNKmCA2cNHGr6yLW/69ajPMfjyGfYL/Dy3RJ8T+HoOoPUlVLT791sRE13uhpg0 UoZ7l+RpOK/B6NYjxt40srTI9yt3+Zd01xVn0ammD8fwkdI2uRZ2JR1FERnwDqVYLu89 Cx8QO5LDa5IVViJecVfN8+F9esuu5weDFke05el7pV31OhieXKfRyEdZkU7EC6KEc+wV morw== X-Received: by 10.49.75.73 with SMTP id a9mr45352870qew.30.1370586182099; Thu, 06 Jun 2013 23:23:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.118.68 with HTTP; Thu, 6 Jun 2013 23:22:21 -0700 (PDT) In-Reply-To: <51B116FE.9050406@crockford.com> References: <51B0E02E.4070209@crockford.com> <1BD0044B-D7A6-4C7F-899E-5D3E72C62956@vpnc.org> <51B116FE.9050406@crockford.com> From: Peter Brooks Date: Fri, 7 Jun 2013 08:22:21 +0200 Message-ID: To: Douglas Crockford Content-Type: text/plain; charset=UTF-8 Cc: Paul Hoffman , "json@ietf.org" Subject: Re: [Json] Security Considerations X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 07 Jun 2013 06:23:11 -0000 I see two quite separate issues here. 1. The security of JSON itself as a data exchange mechanism 2. The ability for organisations to exercise good governance by having their defined security policy reflected transparently in the access controls of objects The first issue applies only where JSON is exchanged in cleartext. If JSON messages are exchanged through secure, encrypted channels, such as SSL, then the chance of any successful interception and modification of the message without detection is very small and more the responsibility of the security software than the structure of JSON itself. If JSON messages are exchanged in cleartext, that, itself, is an indication that they are public and unimportant, so the risk, even if they are intercepted and modified, is low. The second issue matters even if the JSON messages are encrypted. If the software fails to enforce corporate security policy, objects can be revealed to unauthorised parties without detection being easy, or even possible, as the logic is in the application, not the data, the JSON object itself. It is possible to secure JSON at the moment by adding fields that do one of two things: - Apply a corporate confidentiality level to an object ('Public','Private','Company Confidential','Internal Only','Board Members Only', for example). The names of the fields are not defined, though, so a scheme set up by one company would not be compatible with one set up by another, which would cause problems if the two merged. This inconsistency also makes it more difficult to validate the security mechanism. - Define the roles that are allowed to have, or are denied, access to an object. Again, this is possible today, but there is no agreement as to what syntax the access controls should follow or how the roles should be defined. If a system for security control was added to JSON in this way, it would have to be backwards compatible by having any object without a confidentiality level or access control being treated as PUBLIC. The virtue of embedding this in the objects, not the application, is: - applications can be tested and validated against access controls, in detail, and proved to be complying with the JSON security. - security staff, auditors and others can validate the security of objects against policy by examining only the JSON schema and JSON data with no requirement (once they have been tested and validated as above) to examine the applications themselves. Both of these would lead to JSON being recommended as an acceptable data exchange method for organisations requiring good security governance. Obviously, securing the JSON objects would not prevent JSON files being exchanged with the secure data exposed, but, again, the security of files or databases is the responsibility of other security matters, not the definition of JSON. From stefan@drees.name Thu Jun 6 23:32:03 2013 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 C244D21F85D1 for ; Thu, 6 Jun 2013 23:32:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t0+kdUsK5u3v for ; Thu, 6 Jun 2013 23:31:58 -0700 (PDT) Received: from mout.web.de (mout.web.de [212.227.15.4]) by ietfa.amsl.com (Postfix) with ESMTP id 6CB1821F83EF for ; Thu, 6 Jun 2013 23:31:56 -0700 (PDT) Received: from newyork.local.box ([93.129.186.5]) by smtp.web.de (mrweb004) with ESMTPSA (Nemesis) id 0MWNHW-1UrrLg45Qw-00Xebe; Fri, 07 Jun 2013 08:31:51 +0200 Message-ID: <51B17E54.9030107@drees.name> Date: Fri, 07 Jun 2013 08:31:48 +0200 From: Stefan Drees User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "Manger, James H" References: <255B9BB34FB7D647A506DC292726F6E1151B21F79E@WSMSG3153V.srv.dir.telstra.com> <255B9BB34FB7D647A506DC292726F6E1151B21F8CA@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: <255B9BB34FB7D647A506DC292726F6E1151B21F8CA@WSMSG3153V.srv.dir.telstra.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:WLlURlnf/qgTZbMyoasIloLkZi2lw1x/mLgkD2W4uTl8wR2WhaL v7QT+K+dgWspz5cj9PC/jQy0OOYSxIjyI6p6Xc311J1w5LID2ZlzF05onfPO23Uu3AO4yV8 RvB6rMq85n0sHh4cYTOcON+zoBS6w/WNdse3TyLimOImnfnOLSoufftmfivshs6M/9ZLy1G v5eTSIxP5+Y9UY+Fi4cOQ== Cc: "Joe Hildebrand \(jhildebr\)" , "json@ietf.org" Subject: Re: [Json] ABNF nits X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stefan@drees.name List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2013 06:32:03 -0000 On 2013-06-07 05:15, James H. Manger wrote: >>>> Some things I found futzing with the ABNF: >>>> >>>> - normalize the indentation (makes it easier to pull out) >>>> - Hex literals need to be uppercase. The false and null rules are >>>> wrong. >>> >>> Lowercase is allowed in hex literals. >>> It links back to HEXDIG in RFC5234 (or RFC 4234). >>> You have to remember the sneaky ABNF rule that quoted strings (eg "A") >>> are case insensitive. "A" is equivalent to %x41 / %x61. >> >> Crap. I didn't see that because it's in a "Note:" in section 2.3. > > I didn't call it "sneaky" for nothing ;) ... lucky JSON, it only needs short tokens (cowardly avoiding the word single character here ;-) If defining a grammar with real case-sensitive "word"-ish tokens in it, ABNF is IMO barely usable, unless you extend it with say single quotes as case-sensitve string delimiters. But then dealing with two kinds of strings also has it's catches =( >> Regardless, we should change both of those rules for consistency with >> the rest of the doc. >> >>>> - DIGIT and HEXDIG are neither defined nor imported, as far as I can >>>> tell. >>>> I suggest: >>>> >>>> DIGIT = %x30-39 ; 0-9 >>>> HEXDIG = %x30-39 / %x41-46 / %x61-66 ; 0-9, A-F, or a-f >> >> I still recommend being explicit about this, like the rule for e. > > I agree. > Add DIGIT and HEXDIG to the doc so all the ABNF is present. > Use your definition of HEXDIG above, not the RFC5234 one, to avoid the sneaky ABNF rule. > Optionally add a note "; DIGIT and HEXDIG are equivalent to rules with the same names in [RFC5234]". +1 on your proposal James (including the ABNF comment). Stefan. From stefan@drees.name Thu Jun 6 23:45:44 2013 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 ABAB021F91BC for ; Thu, 6 Jun 2013 23:45:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KU891rPyRFyg for ; Thu, 6 Jun 2013 23:45:39 -0700 (PDT) Received: from mout.web.de (mout.web.de [212.227.15.14]) by ietfa.amsl.com (Postfix) with ESMTP id 97E6B21F8FDC for ; Thu, 6 Jun 2013 23:45:39 -0700 (PDT) Received: from newyork.local.box ([93.129.186.5]) by smtp.web.de (mrweb102) with ESMTPSA (Nemesis) id 0LwqFo-1UIEni3eh6-016MTB; Fri, 07 Jun 2013 08:45:32 +0200 Message-ID: <51B1818A.7080100@drees.name> Date: Fri, 07 Jun 2013 08:45:30 +0200 From: Stefan Drees User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: R S References: <255B9BB34FB7D647A506DC292726F6E1151B21F9A9@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Provags-ID: V02:K0:XTq3Lzzpu2zjUV2en3DFgGf8/JL9e/AhVP+RFnBtdov xgPoKvEPykkTltvcnhlkiXC+qhb793XlV88QJzvXOFp0xd0cyo 89Um6no503jQqHLdB1tIvauqr7DtTt7FTvs+41/0y/JXtskZQB QENJR4b6/XxHjof/nvzH8KpK1+PW93x36+6cPefl/ucv7DPs+f xYRKt7T+UH+RHT8HnednA== Cc: "Manger, James H" , "json@ietf.org" Subject: Re: [Json] Allow any JSON value at the top level X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stefan@drees.name List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2013 06:45:44 -0000 On 07.06.13 05:54, "R S" wrote: > On Thu, Jun 6, 2013 at 8:51 PM, Manger, James H ... wrote: >> The current spec only allows a JSON text to be an object or array. Section 2. "JSON Grammar" says: >> >> A JSON text is a serialized object or array. >> >> JSON-text = object / array >> >> >> I propose allowing a JSON text to be any JSON value. >> >> A JSON text is a serialization of any JSON value. >> >> JSON-text = value >> >> value = false / null / true / object / array / number / string >> >> >> ECMAScript already allows this. http://www.ecma-international.org/ecma-262/5.1/#sec-15.12 >> >> * The top level JSONText production of the ECMAScript JSON grammar >> may consist of any JSONValue rather than being restricted to being >> a JSONObject or a JSONArray as specified by RFC 4627. >> ... > I support this change. It is required in interoperable implementations. +0 from me, but I expect a lot of discussion on this one, due to encoding detection tricks depending on the first character (or whatever you may call that) c.f. section 3. Encoding second paragraph in current revision: """ Since the first two characters of a JSON text will always be ASCII characters [RFC0020], it is possible to determine whether an octet stream is UTF-8, UTF-16 (BE or LE), or UTF-32 (BE or LE) by looking at the pattern of nulls in the first four octets. """ So proposing '{"Äther":null}' could be transmitted as '"Äther"' is nice, but not compatible with the above "trick/hack", is it? (The single quotes are of course not part of the JSON samples, but shall only delimit the latter inside this text ;-) Stefan. From stefan@drees.name Thu Jun 6 23:52:51 2013 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 7664221F90EE for ; Thu, 6 Jun 2013 23:52:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZEGs5mhVwM3A for ; Thu, 6 Jun 2013 23:52:45 -0700 (PDT) Received: from mout.web.de (mout.web.de [212.227.15.3]) by ietfa.amsl.com (Postfix) with ESMTP id 58B5421F90A5 for ; Thu, 6 Jun 2013 23:52:43 -0700 (PDT) Received: from newyork.local.box ([93.129.186.5]) by smtp.web.de (mrweb101) with ESMTPSA (Nemesis) id 0LvBV8-1UKxiU2eLy-010Pco; Fri, 07 Jun 2013 08:52:33 +0200 Message-ID: <51B1832E.4000303@drees.name> Date: Fri, 07 Jun 2013 08:52:30 +0200 From: Stefan Drees User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Paul Hoffman References: <255B9BB34FB7D647A506DC292726F6E1151B21F5B6@WSMSG3153V.srv.dir.telstra.com> <7389C161-04C8-432F-B229-A25765894737@vpnc.org> In-Reply-To: <7389C161-04C8-432F-B229-A25765894737@vpnc.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:5cKcrO8IwkY+Q2zDCiuSOwbtqZVSwjUcftxsG2rIPIvrs+g9JzM ZPozstm6DAMLAc7Yssq14KhWE+CNoON35dtfUvfAFXGJZwO0uA7ol9M7ctPuLJ6ahG6W2p/ UkhegHZxvydJGiVcYP1V3hMM/xYk/oN+JDglElftq56SAlc7AL6gCfSZrRS3iLCCKpDbVJ9 8USoDmpej1HX6vLPeMA0g== Cc: "Manger, James H" , "json@ietf.org" Subject: Re: [Json] issues tracker? X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stefan@drees.name List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2013 06:52:51 -0000 On 2013-06-07 04:12, Paul Hoffman wrote: > On Jun 6, 2013, at 6:11 PM, "Manger, James H" wrote: > >> Should we list issues in the tracker ...? >> Particularly since issues will not be reflected in a draft until a consensus call. > > See the first message after we became a WG. The chairs are tracking > (as best we can) the threads and will watch for them to calm down, then > we will reignite them before the consensus call. If we miss stuff, we're > sure you'll tell us. > > My experience with WGs with trackers is that they split the focus > between the mailing list and the tracker. That would suck here, given > the active back-and-forth we are seeing. > > Matt and I are open to changing the process, but give us a few weeks > and a few consensus calls before you decide we can't handle this. ... Please do not change the process. I think Paul and Matt are doing a terrific job here keeping us all on a single vivid discussing lane. A channel split would in my experience be a killer as many real (content) issues (!=tickets) then might slip the attention of experts with good ideas for resolution. Stefan. From stefan@drees.name Thu Jun 6 23:59:00 2013 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 69AB321F9488 for ; Thu, 6 Jun 2013 23:59:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jp6kPcF9M3DX for ; Thu, 6 Jun 2013 23:58:56 -0700 (PDT) Received: from mout.web.de (mout.web.de [212.227.17.12]) by ietfa.amsl.com (Postfix) with ESMTP id 759FB21F8F69 for ; Thu, 6 Jun 2013 23:58:52 -0700 (PDT) Received: from newyork.local.box ([93.129.186.5]) by smtp.web.de (mrweb103) with ESMTPSA (Nemesis) id 0LsyRS-1UNAwI1Fuc-012K3y; Fri, 07 Jun 2013 08:58:45 +0200 Message-ID: <51B184A3.1070607@drees.name> Date: Fri, 07 Jun 2013 08:58:43 +0200 From: Stefan Drees User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: R S References: <255B9BB34FB7D647A506DC292726F6E1151B21F9A9@WSMSG3153V.srv.dir.telstra.com> <51B1818A.7080100@drees.name> In-Reply-To: <51B1818A.7080100@drees.name> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Provags-ID: V02:K0:xcwgcBHa9f9DsLcliumGhVJ907nDnD9j1hNKTL1ZgXC Pss2GMK0XGApWCgXtXNzrAzg5SZeKHHpPRT2va7cIBN8ydwmDN 0+BNy4ZnA+zhNmTn8CIYwB6ACGD7t4lnhwmGOr2NvbAYsXPNia Owo5K3g/hWk+fUJ2alX/6gYXHVARqeBoUDtqIdAVIwsl/G6E4u zBN3+nBlo0hMzJThvzQjQ== Cc: "Manger, James H" , "json@ietf.org" Subject: Re: [Json] Allow any JSON value at the top level X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stefan@drees.name List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2013 06:59:00 -0000 consistency correction below, sorry for the inconvenience. On 07.06.13 08:45, Stefan Drees hastily wrote: > On 07.06.13 05:54, "R S" wrote: >> On Thu, Jun 6, 2013 at 8:51 PM, Manger, James H ... wrote: >>> The current spec only allows a JSON text to be an object or array. >>> Section 2. "JSON Grammar" says: >>> >>> A JSON text is a serialized object or array. >>> >>> JSON-text = object / array >>> >>> >>> I propose allowing a JSON text to be any JSON value. >>> >>> A JSON text is a serialization of any JSON value. >>> >>> JSON-text = value >>> >>> value = false / null / true / object / array / number / string >>> >>> >>> ECMAScript already allows this. >>> http://www.ecma-international.org/ecma-262/5.1/#sec-15.12 >>> >>> * The top level JSONText production of the ECMAScript JSON grammar >>> may consist of any JSONValue rather than being restricted to being >>> a JSONObject or a JSONArray as specified by RFC 4627. >>> ... > >> I support this change. It is required in interoperable implementations. > > > +0 from me, but I expect a lot of discussion on this one, due to > encoding detection tricks depending on the first character (or whatever sorry, of course "first two characters" instead of "first character". > you may call that) c.f. section 3. Encoding second paragraph in current > revision: > """ > Since the first two characters of a JSON text will always be ASCII > characters [RFC0020], it is possible to determine whether an octet > stream is UTF-8, UTF-16 (BE or LE), or UTF-32 (BE or LE) by looking > at the pattern of nulls in the first four octets. > """ > > So proposing '{"Äther":null}' could be transmitted as '"Äther"' is nice, > but not compatible with the above "trick/hack", is it? (The single > quotes are of course not part of the JSON samples, but shall only > delimit the latter inside this text ;-) > > Stefan. > > > > > > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json From James.H.Manger@team.telstra.com Fri Jun 7 00:04:40 2013 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 2816821F9310 for ; Fri, 7 Jun 2013 00:04:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.499 X-Spam-Level: X-Spam-Status: No, score=-0.499 tagged_above=-999 required=5 tests=[AWL=0.402, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9K+qZmuSMWhI for ; Fri, 7 Jun 2013 00:04:24 -0700 (PDT) Received: from ipxbvo.tcif.telstra.com.au (ipxbvo.tcif.telstra.com.au [203.35.135.204]) by ietfa.amsl.com (Postfix) with ESMTP id DCC1621F9420 for ; Fri, 7 Jun 2013 00:04:21 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.87,820,1363093200"; d="scan'208";a="140063810" Received: from unknown (HELO ipcdvi.tcif.telstra.com.au) ([10.97.217.212]) by ipobvi.tcif.telstra.com.au with ESMTP; 07 Jun 2013 17:04:19 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,7098"; a="136654590" Received: from wsmsg3702.srv.dir.telstra.com ([172.49.40.170]) by ipcdvi.tcif.telstra.com.au with ESMTP; 07 Jun 2013 17:04:19 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3702.srv.dir.telstra.com ([172.49.40.170]) with mapi; Fri, 7 Jun 2013 17:04:19 +1000 From: "Manger, James H" To: "stefan@drees.name" , R S Date: Fri, 7 Jun 2013 17:04:17 +1000 Thread-Topic: [Json] Allow any JSON value at the top level Thread-Index: Ac5jSp7UUHIefUjXSCikzc3HH8FUIAAABS5Q Message-ID: <255B9BB34FB7D647A506DC292726F6E1151B21FE35@WSMSG3153V.srv.dir.telstra.com> References: <255B9BB34FB7D647A506DC292726F6E1151B21F9A9@WSMSG3153V.srv.dir.telstra.com> <51B1818A.7080100@drees.name> In-Reply-To: <51B1818A.7080100@drees.name> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "json@ietf.org" Subject: Re: [Json] Allow any JSON value at the top level X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 07 Jun 2013 07:04:40 -0000 PiArMCBmcm9tIG1lLCBidXQgSSBleHBlY3QgYSBsb3Qgb2YgZGlzY3Vzc2lvbiBvbiB0aGlzIG9u ZSwgZHVlIHRvDQo+IGVuY29kaW5nIGRldGVjdGlvbiB0cmlja3MgZGVwZW5kaW5nIG9uIHRoZSBm aXJzdCBjaGFyYWN0ZXIgKG9yIHdoYXRldmVyDQo+IHlvdSBtYXkgY2FsbCB0aGF0KSBjLmYuIHNl Y3Rpb24gMy4gRW5jb2Rpbmcgc2Vjb25kIHBhcmFncmFwaCBpbiBjdXJyZW50DQo+IHJldmlzaW9u Og0KPiAiIiINCj4gICAgIFNpbmNlIHRoZSBmaXJzdCB0d28gY2hhcmFjdGVycyBvZiBhIEpTT04g dGV4dCB3aWxsIGFsd2F5cyBiZSBBU0NJSQ0KPiAgICAgY2hhcmFjdGVycyBbUkZDMDAyMF0sIGl0 IGlzIHBvc3NpYmxlIHRvIGRldGVybWluZSB3aGV0aGVyIGFuIG9jdGV0DQo+ICAgICBzdHJlYW0g aXMgVVRGLTgsIFVURi0xNiAoQkUgb3IgTEUpLCBvciBVVEYtMzIgKEJFIG9yIExFKSBieSBsb29r aW5nDQo+ICAgICBhdCB0aGUgcGF0dGVybiBvZiBudWxscyBpbiB0aGUgZmlyc3QgZm91ciBvY3Rl dHMuDQo+ICIiIg0KPiANCj4gU28gcHJvcG9zaW5nICd7IsOEdGhlciI6bnVsbH0nIGNvdWxkIGJl IHRyYW5zbWl0dGVkIGFzICciw4R0aGVyIicgaXMNCj4gbmljZSwgYnV0IG5vdCBjb21wYXRpYmxl IHdpdGggdGhlIGFib3ZlICJ0cmljay9oYWNrIiwgaXMgaXQ/IChUaGUNCj4gc2luZ2xlIHF1b3Rl cyBhcmUgb2YgY291cnNlIG5vdCBwYXJ0IG9mIHRoZSBKU09OIHNhbXBsZXMsIGJ1dCBzaGFsbA0K PiBvbmx5IGRlbGltaXQgdGhlIGxhdHRlciBpbnNpZGUgdGhpcyB0ZXh0IDstKQ0KDQoNCkVuY29k aW5nIGRldGVjdGlvbiBpcyBzdGlsbCBwb3NzaWJsZSwgZXZlbiB0aG91Z2ggdGhlIGZpcnN0IDIg Y2hhcmFjdGVycyB3aWxsIG5vdCBhbHdheXMgYnkgQVNDSUkuIFNpbmNlIFUrMDAwMCBNVVNUIGJl IGVzY2FwZWQgaW4gYSBKU09OIHN0cmluZyB0aGF0IGNhbm5vdCBpbnRyb2R1Y2UgMHgwMCBieXRl cyB0byBjb25mdXNlIHRoaW5ncy4NCg0KQWRqdXN0IHRoZSBzZW50ZW5jZSB0byBzdGFydDoNCg0K ICAgIFNpbmNlIHRoZSBmaXJzdCBjaGFyYWN0ZXIgb2YgYSBKU09OIHRleHQgd2lsbCBhbHdheXMg YmUgQVNDSUkgW1JGQzAwMjBdDQogICAgYW5kIGEgVSswMDAwIGNoYXJhY3RlciBpcyBub3QgYWxs b3dlZCBpbiB1bmVzY2FwZWQgZm9ybSwgaXQgaXMgcG9zc2libGUuLi4NCg0KQWRqdXN0IHRoZSBV VEYtMTYgcGF0dGVybnMgdG86DQoNCiAgICAwMCB4eCB4eCB4eCAgVVRGLTE2QkUNCiAgICB4eCAw MCB4eCB4eCAgVVRGLTE2TEUNCg0KLS0NCkphbWVzIE1hbmdlcg0K From James.H.Manger@team.telstra.com Fri Jun 7 00:12:31 2013 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 291D621F8F6E for ; Fri, 7 Jun 2013 00:12:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.53 X-Spam-Level: X-Spam-Status: No, score=-0.53 tagged_above=-999 required=5 tests=[AWL=0.372, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zwm9MuCV+JEO for ; Fri, 7 Jun 2013 00:12:25 -0700 (PDT) Received: from ipxbvo.tcif.telstra.com.au (ipxbvo.tcif.telstra.com.au [203.35.135.204]) by ietfa.amsl.com (Postfix) with ESMTP id 6ABF921F85E0 for ; Fri, 7 Jun 2013 00:12:24 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.87,820,1363093200"; d="scan'208";a="140065309" Received: from unknown (HELO ipcbvi.tcif.telstra.com.au) ([10.97.217.204]) by ipobvi.tcif.telstra.com.au with ESMTP; 07 Jun 2013 17:12:24 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,7098"; a="137081528" Received: from wsmsg3755.srv.dir.telstra.com ([172.49.40.196]) by ipcbvi.tcif.telstra.com.au with ESMTP; 07 Jun 2013 17:12:23 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3755.srv.dir.telstra.com ([172.49.40.196]) with mapi; Fri, 7 Jun 2013 17:12:23 +1000 From: "Manger, James H" To: "stefan@drees.name" , R S Date: Fri, 7 Jun 2013 17:12:22 +1000 Thread-Topic: [Json] Allow any JSON value at the top level Thread-Index: Ac5jSp7UUHIefUjXSCikzc3HH8FUIAAABS5QAADDlVA= Message-ID: <255B9BB34FB7D647A506DC292726F6E1151B21FE4F@WSMSG3153V.srv.dir.telstra.com> References: <255B9BB34FB7D647A506DC292726F6E1151B21F9A9@WSMSG3153V.srv.dir.telstra.com> <51B1818A.7080100@drees.name> <255B9BB34FB7D647A506DC292726F6E1151B21FE35@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: <255B9BB34FB7D647A506DC292726F6E1151B21FE35@WSMSG3153V.srv.dir.telstra.com> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "json@ietf.org" Subject: Re: [Json] Allow any JSON value at the top level X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 07 Jun 2013 07:12:31 -0000 PiBFbmNvZGluZyBkZXRlY3Rpb24gaXMgc3RpbGwgcG9zc2libGUsIGV2ZW4gdGhvdWdoIHRoZSBm aXJzdCAyDQo+IGNoYXJhY3RlcnMgd2lsbCBub3QgYWx3YXlzIGJ5IEFTQ0lJLiBTaW5jZSBVKzAw MDAgTVVTVCBiZSBlc2NhcGVkIGluIGENCj4gSlNPTiBzdHJpbmcgdGhhdCBjYW5ub3QgaW50cm9k dWNlIDB4MDAgYnl0ZXMgdG8gY29uZnVzZSB0aGluZ3MuDQo+IA0KPiBBZGp1c3QgdGhlIHNlbnRl bmNlIHRvIHN0YXJ0Og0KPiANCj4gICAgIFNpbmNlIHRoZSBmaXJzdCBjaGFyYWN0ZXIgb2YgYSBK U09OIHRleHQgd2lsbCBhbHdheXMgYmUgQVNDSUkNCj4gW1JGQzAwMjBdDQo+ICAgICBhbmQgYSBV KzAwMDAgY2hhcmFjdGVyIGlzIG5vdCBhbGxvd2VkIGluIHVuZXNjYXBlZCBmb3JtLCBpdCBpcw0K PiBwb3NzaWJsZS4uLg0KPiANCj4gQWRqdXN0IHRoZSBVVEYtMTYgcGF0dGVybnMgdG86DQo+IA0K PiAgICAgMDAgeHggeHggeHggIFVURi0xNkJFDQo+ICAgICB4eCAwMCB4eCB4eCAgVVRGLTE2TEUN Cg0KQWRkIHRob3NlIHBhdHRlcm5zLCBkb24ndCByZXBsYWNlIHRoZSBleGlzdGluZyBvbmVzLiBU aGUgdGFibGUgYmVjb21lczoNCg0KICAgMDAgMDAgMDAgeHggIFVURi0zMkJFDQogICAwMCB4eCAw MCB4eCAgVVRGLTE2QkUNCiAgIDAwIHh4IHh4IHh4ICBVVEYtMTZCRQ0KICAgeHggMDAgMDAgMDAg IFVURi0zMkxFDQogICB4eCAwMCB4eCAwMCAgVVRGLTE2TEUNCiAgIHh4IDAwIHh4IHh4ICBVVEYt MTZMRQ0KICAgeHggeHggeHggeHggIFVURi04DQoNCg0KIm9sZCIgcGFyc2VycyBtaWdodCByZWpl Y3QgIm5ldyIgSlNPTiBtYXRjaGluZyBvbmUgb2YgdGhlIDIgbmV3IHBhdHRlcm5zLCBidXQgdGhl ICJvbGQiIHBhcnNlciB3b3VsZCBoYXZlIHJlamVjdGVkIHRoZSBuZXcgc3RyaW5nLWF0LXRvcC1s ZXZlbCBhbnl3YXkuDQoNCi0tDQpKYW1lcyBNYW5nZXINCg== From stefan@drees.name Fri Jun 7 00:15:01 2013 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 8BF8721F94BA for ; Fri, 7 Jun 2013 00:15:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UHGw2ah4MEIw for ; Fri, 7 Jun 2013 00:14:55 -0700 (PDT) Received: from mout.web.de (mout.web.de [212.227.15.3]) by ietfa.amsl.com (Postfix) with ESMTP id 75EB221F8CB5 for ; Fri, 7 Jun 2013 00:14:55 -0700 (PDT) Received: from newyork.local.box ([93.129.186.5]) by smtp.web.de (mrweb101) with ESMTPSA (Nemesis) id 0MKa6N-1UmEat20nv-001xDu; Fri, 07 Jun 2013 09:14:41 +0200 Message-ID: <51B1885F.3080908@drees.name> Date: Fri, 07 Jun 2013 09:14:39 +0200 From: Stefan Drees User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Douglas Crockford References: <51B0E02E.4070209@crockford.com> <1BD0044B-D7A6-4C7F-899E-5D3E72C62956@vpnc.org> <51B116FE.9050406@crockford.com> In-Reply-To: <51B116FE.9050406@crockford.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:9jBhMFOFpQ6VLCpbeX7M2EDg9LIggWHAUJHmsJu1If2ri05IWCU NVRbnPzpT4dBO6V9aTAvcjhE2fwP6VRO+YCg23MT+risTzNilHs11gxMq294q/hpcoQV1Ps uu3ntXqg8dByL/ErSJN0klqA7TblsMnJBH/iok2ObYsTLsLS/aFLPIhqqgX5yzUG2fArUjC VMjEpfNArBURiJiyzRv1g== Cc: Paul Hoffman , "json@ietf.org" Subject: Re: [Json] Security Considerations X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stefan@drees.name List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2013 07:15:01 -0000 On 07.06.13 01:10, Douglas Crockford wrote: > On 6/6/2013 4:04 PM, Paul Hoffman wrote: >> >> On Jun 6, 2013, at 12:17 PM, Douglas Crockford >> wrote: >> >>> Proposal: >>> >>> With any data format, it is important to encode correctly. Care must >>> be taken when constructing JSON texts by concatenation. For example: >>> >>> account = 4627; >>> comment = "\",\"account\":262"; // provided by attacker >>> json_text = "(\"account\":" + account + ",\"comment\":\"" + >>> comment + "\"}"; >> The example is language-specific and, due to the escaping, hard to read. > Which specific language would you say it is? Confusion attacks are often > hard to read. That is why they work. ... I propose to keep the example, but remove the need for quoting by switching to single quotes where needed: """ account = 4627; comment = '","account":262'; // provided by attacker json_text = '("account":' + account + ',"comment":"' + comment + '"}'; """ this is valid (Java|ECMA)Script, right and also much more readable, isn't it? All the best, Stefan. From stefan@drees.name Fri Jun 7 00:26:30 2013 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 66E0321F93F8 for ; Fri, 7 Jun 2013 00:26:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id im8JqKGvWqad for ; Fri, 7 Jun 2013 00:26:24 -0700 (PDT) Received: from mout.web.de (mout.web.de [212.227.15.14]) by ietfa.amsl.com (Postfix) with ESMTP id 44F3321F9473 for ; Fri, 7 Jun 2013 00:26:24 -0700 (PDT) Received: from newyork.local.box ([93.129.186.5]) by smtp.web.de (mrweb103) with ESMTPSA (Nemesis) id 0M1GAG-1UVNZv0CIy-00tbNY; Fri, 07 Jun 2013 09:26:23 +0200 Message-ID: <51B18B1E.30805@drees.name> Date: Fri, 07 Jun 2013 09:26:22 +0200 From: Stefan Drees User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Douglas Crockford References: <51B0E02E.4070209@crockford.com> In-Reply-To: <51B0E02E.4070209@crockford.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V02:K0:w2zcjuSynolS7zL91evVsjdPa1xj1nQ0p5SDU4nkNk1 bQIUaiWYq05CBOSbnBcIJeLzz9DLOW6Lq0fXy2TVY8MV+pOAch kaQ8wwT1f6o5HaGhLhXx2P+i5kcDV8VVMhziHhTfOyCasg6GoW tVhBiuDHToGH3vnz2eLR+GDjgiiauWdDOFKEOHjLa9pX5bIJhD q2UH/owzIOV0necXhefvg== Cc: "json@ietf.org" Subject: Re: [Json] Security Considerations X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stefan@drees.name List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2013 07:26:30 -0000 On 06.06.13 21:17, Douglas Crockford wrote: > Proposal: > > ... > > JSON is so similar to some programming languages that the native > parsing ability of the language processors can be used to parse JSON > texts. This should be avoided because the native parser will accept > code which is not JSON. > > For example, JavaScript's eval() function is able parse JSON text, > but is can also parse programs. If an attacker can inject code into > the JSON text (as we saw above), then it can compromise the system. > JSON parsers should always be used instead. as JSON allows '{"\/":null}' this already forbids any native parsing ability of C like (or "based") languages including Python ;-) I think these paragraphs are a very good change, but might ripen even more through discussions. For me the main points of data interchange and in sequence are: 1. Do not parse any untrusted data without preconditioning 2. Do not excecute/eval untrusted data and trust is sometimes hard to establish ... As long as these two points stand out and are not burried inside sample language terms, I am happy with any re-phrasing. Stefan. From duerst@it.aoyama.ac.jp Fri Jun 7 01:15:22 2013 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 B797221F9485 for ; Fri, 7 Jun 2013 01:15:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.79 X-Spam-Level: X-Spam-Status: No, score=-102.79 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uJgyWjhrswBz for ; Fri, 7 Jun 2013 01:15:16 -0700 (PDT) Received: from scintmta02.scbb.aoyama.ac.jp (scintmta02.scbb.aoyama.ac.jp [133.2.253.34]) by ietfa.amsl.com (Postfix) with ESMTP id DCCA821F9310 for ; Fri, 7 Jun 2013 01:15:10 -0700 (PDT) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id r578F03g028436; Fri, 7 Jun 2013 17:15:00 +0900 Received: from (unknown [133.2.206.134]) by scmse02.scbb.aoyama.ac.jp with smtp id 3a18_da10_59103446_cf4a_11e2_aaec_001e6722eec2; Fri, 07 Jun 2013 17:14:59 +0900 Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id 6A819BF521; Fri, 7 Jun 2013 17:13:52 +0900 (JST) Message-ID: <51B19672.8040706@it.aoyama.ac.jp> Date: Fri, 07 Jun 2013 17:14:42 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: stefan@drees.name References: <255B9BB34FB7D647A506DC292726F6E1151B21F79E@WSMSG3153V.srv.dir.telstra.com> <255B9BB34FB7D647A506DC292726F6E1151B21F8CA@WSMSG3153V.srv.dir.telstra.com> <51B17E54.9030107@drees.name> In-Reply-To: <51B17E54.9030107@drees.name> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "Manger, James H" , "Joe Hildebrand \(jhildebr\)" , "json@ietf.org" Subject: Re: [Json] ABNF nits X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 07 Jun 2013 08:15:22 -0000 On 2013/06/07 15:31, Stefan Drees wrote: > If defining a grammar with real case-sensitive "word"-ish tokens in it, > ABNF is IMO barely usable, unless you extend it with say single quotes > as case-sensitve string delimiters. But then dealing with two kinds of > strings also has it's catches =( Another way to do this is to just note that you are using ABNF *except that literals are case-sensitive*. I'm sure there's an RFC or two which have done so. Regards, Martin. From petejson@codalogic.com Fri Jun 7 01:22:52 2013 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 C0FA521F964C for ; Fri, 7 Jun 2013 01:22:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.018 X-Spam-Level: * X-Spam-Status: No, score=1.018 tagged_above=-999 required=5 tests=[AWL=-0.650, BAYES_50=0.001, SARE_HEAD_XUNSENT=1.666, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WyLjlbn5CGwh for ; Fri, 7 Jun 2013 01:22:45 -0700 (PDT) Received: from codalogic.com (codalogic.com [94.136.60.219]) by ietfa.amsl.com (Postfix) with ESMTP id 96B5921F9007 for ; Fri, 7 Jun 2013 01:22:44 -0700 (PDT) Received: (qmail 10019 invoked from network); 7 Jun 2013 09:22:42 +0100 Received: from host86-132-241-164.range86-132.btcentralplus.com (HELO codalogic) (86.132.241.164) by codalogic.com with (RC4-MD5 encrypted) SMTP; 7 Jun 2013 09:22:42 +0100 Message-ID: From: "Pete Cordell" To: "Manger, James H" , , "R S" References: <255B9BB34FB7D647A506DC292726F6E1151B21F9A9@WSMSG3153V.srv.dir.telstra.com><51B1818A.7080100@drees.name><255B9BB34FB7D647A506DC292726F6E1151B21FE35@WSMSG3153V.srv.dir.telstra.com> <255B9BB34FB7D647A506DC292726F6E1151B21FE4F@WSMSG3153V.srv.dir.telstra.com> X-Unsent: 1 Date: Fri, 7 Jun 2013 09:22:37 +0100 x-vipre-scanned: 0073D8FB00483A0073DA48 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Cc: json@ietf.org Subject: Re: [Json] Allow any JSON value at the top level - Encoding detection X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 07 Jun 2013 08:22:52 -0000 Original Message From: "Manger, James H" >> Adjust the UTF-16 patterns to: >> >> 00 xx xx xx UTF-16BE >> xx 00 xx xx UTF-16LE > > Add those patterns, don't replace the existing ones. The table becomes: > > 00 00 00 xx UTF-32BE > 00 xx 00 xx UTF-16BE > 00 xx xx xx UTF-16BE > xx 00 00 00 UTF-32LE > xx 00 xx 00 UTF-16LE > xx 00 xx xx UTF-16LE > xx xx xx xx UTF-8 If xx means non-zero, then I think we also have to include the following for characters like U+2c00: xx 00 00 xx UTF-16LE giving: 00 00 00 xx UTF-32BE 00 xx 00 xx UTF-16BE 00 xx xx xx UTF-16BE xx 00 00 00 UTF-32LE xx 00 00 xx UTF-16LE xx 00 xx 00 UTF-16LE xx 00 xx xx UTF-16LE xx xx xx xx UTF-8 That can be reduced a bit if we use "--" to indicate "not-tested": 00 00 -- -- UTF-32BE 00 xx -- -- UTF-16BE xx 00 00 00 UTF-32LE xx 00 00 xx UTF-16LE xx 00 xx -- UTF-16LE xx xx -- -- UTF-8 Pete Cordell Codalogic Ltd C++ tools for C++ programmers, http://codalogic.com Read & write XML in C++, http://www.xml2cpp.com From petejson@codalogic.com Fri Jun 7 01:41:45 2013 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 475B921F9473 for ; Fri, 7 Jun 2013 01:41:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.679 X-Spam-Level: X-Spam-Status: No, score=0.679 tagged_above=-999 required=5 tests=[AWL=0.122, BAYES_05=-1.11, SARE_HEAD_XUNSENT=1.666, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3qkEYQlZ22-m for ; Fri, 7 Jun 2013 01:41:39 -0700 (PDT) Received: from codalogic.com (codalogic.com [94.136.60.219]) by ietfa.amsl.com (Postfix) with ESMTP id D98D021F93DA for ; Fri, 7 Jun 2013 01:41:35 -0700 (PDT) Received: (qmail 10239 invoked from network); 7 Jun 2013 09:41:34 +0100 Received: from host86-132-241-164.range86-132.btcentralplus.com (HELO codalogic) (86.132.241.164) by codalogic.com with (RC4-MD5 encrypted) SMTP; 7 Jun 2013 09:41:34 +0100 Message-ID: From: "Pete Cordell" To: "John Cowan" , "Nico Williams" References: <20130606225906.GO3090@mercury.ccil.org> X-Unsent: 1 Date: Fri, 7 Jun 2013 09:41:25 +0100 x-vipre-scanned: 00850F5A00483A008510A7 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Cc: Douglas Crockford , json@ietf.org Subject: Re: [Json] Parser and encoder options (Re: The names within an object SHOULD be unique.) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 07 Jun 2013 08:41:45 -0000 Original Message From: "John Cowan" > Nico Williams scripsit: > >> I think we should formalize the concept of options for parsers and >> encoders. >> >> For example, it's common to have options for pretty printing JSON. >> And there's been talk of extensions, so why not have some useful >> extensions (like comments, or string join, like in C, for >> pretty-printing purposes)? >> >> We should also have a taxonomy for describing an implementation. >> We've seen the need to distinguish between streaming and non-streaming >> parsers. (For now that's my only contribution to such a taxonomy.) > > While all these things are nice-to-haves, they are why specs balloon up > to dozens or even hundreds of pages, and become impossible for anyone > but large, well-funded organizations to implement. I do most strongly > urge this group NOT to go there. +1 Surely we don't want to go down the path of protocol specs say "This protocol requires a JSON streaming parser" or "This protocol requires a JSON non-streaming parser" etc. We just want to use JSON. Douglas said the text "The names within an object SHOULD be unique" should have been "The names within an object MUST be unique". IMO by defining a fall-back mechanism we're justifying having non-unique names and we're actually weakening the requirement to something like "The names within an object MAY be unique". Is that the direction we want to go in? Pete Cordell Codalogic Ltd C++ tools for C++ programmers, http://codalogic.com Easily read & write XML in C++, http://www.xml2cpp.com From petejson@codalogic.com Fri Jun 7 01:47:37 2013 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 E1E3621F9473 for ; Fri, 7 Jun 2013 01:47:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.204 X-Spam-Level: * X-Spam-Status: No, score=1.204 tagged_above=-999 required=5 tests=[AWL=-0.464, BAYES_50=0.001, SARE_HEAD_XUNSENT=1.666, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id meDad8s52VXQ for ; Fri, 7 Jun 2013 01:47:31 -0700 (PDT) Received: from codalogic.com (codalogic.com [94.136.60.219]) by ietfa.amsl.com (Postfix) with ESMTP id 5C31F21F9248 for ; Fri, 7 Jun 2013 01:47:31 -0700 (PDT) Received: (qmail 11384 invoked from network); 7 Jun 2013 09:47:30 +0100 Received: from host86-132-241-164.range86-132.btcentralplus.com (HELO codalogic) (86.132.241.164) by codalogic.com with (RC4-MD5 encrypted) SMTP; 7 Jun 2013 09:47:30 +0100 Message-ID: <8FB1F7E3211045C3964C4CE88E668987@codalogic> From: "Pete Cordell" To: "Joe Hildebrand \(jhildebr\)" , "Tim Bray" , "Stephan Beal" References: X-Unsent: 1 Date: Fri, 7 Jun 2013 09:47:09 +0100 x-vipre-scanned: 008A4D4600483A008A4E93 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Cc: json@ietf.org Subject: Re: [Json] Introduction - Zero or more X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 07 Jun 2013 08:47:38 -0000 Original Message From: "Joe Hildebrand (jhildebr)" >On 6/6/13 3:44 PM, "Pete Cordell" wrote: >>Does this allow for empty strings? Maybe that's another detail that can >>be >>left to the string section. I guess most people know that strings can be >>empty. > The empty sequence is a sequence. OK. But in that case, for consistency, "zero or more" should probably be removed from the descriptions of object and array also. Pete Cordell Codalogic Ltd C++ tools for C++ programmers, http://codalogic.com Read & write XML in C++, http://www.xml2cpp.com From stefan@drees.name Fri Jun 7 01:48:54 2013 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 A440021F9649 for ; Fri, 7 Jun 2013 01:48:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DgVMr-QJLWlc for ; Fri, 7 Jun 2013 01:48:48 -0700 (PDT) Received: from mout.web.de (mout.web.de [212.227.15.4]) by ietfa.amsl.com (Postfix) with ESMTP id 0FC2321F939E for ; Fri, 7 Jun 2013 01:48:48 -0700 (PDT) Received: from newyork.local.box ([93.129.186.5]) by smtp.web.de (mrweb004) with ESMTPSA (Nemesis) id 0LePBV-1U1N7G0mSr-00q91R; Fri, 07 Jun 2013 10:48:44 +0200 Message-ID: <51B19E6A.3070105@drees.name> Date: Fri, 07 Jun 2013 10:48:42 +0200 From: Stefan Drees User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Pete Cordell References: <255B9BB34FB7D647A506DC292726F6E1151B21F9A9@WSMSG3153V.srv.dir.telstra.com><51B1818A.7080100@drees.name><255B9BB34FB7D647A506DC292726F6E1151B21FE35@WSMSG3153V.srv.dir.telstra.com> <255B9BB34FB7D647A506DC292726F6E1151B21FE4F@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:nbJzoe0t2PIQfJpm+3op6elLYZHNiwtd1EYJpRZbS818JNztvT+ Q4Y6mTOwF3Oz06PCdMyYPW/jchA1kJHTp8uVGvtvc262axMw6BVhyGP+oHyBnBD1jvXm/I3 C63hm2Gak0XdiYFmLlvoF5pVqGncbv2cLahB6jXaoB2HHl76zlTzhSZh0qq0EvBN5OHSOuI 80qZjrMQ707qYNBEXlk2A== Cc: json@ietf.org, "Manger, James H" , R S Subject: Re: [Json] Allow any JSON value at the top level - Encoding detection X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stefan@drees.name List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2013 08:48:54 -0000 On 2013-06-07 10:22, Pete Cordell wrote: > Original Message From: "Manger, James H" >>> Adjust the UTF-16 patterns to: >>> >>> 00 xx xx xx UTF-16BE >>> xx 00 xx xx UTF-16LE >> >> Add those patterns, don't replace the existing ones. The table becomes: >> ... {"content":"snipped"} > > If xx means non-zero, then I think we also have to include the following > for characters like U+2c00: ... > ... {"content":"snipped"} > > That can be reduced a bit if we use "--" to indicate "not-tested": > > 00 00 -- -- UTF-32BE > 00 xx -- -- UTF-16BE > xx 00 00 00 UTF-32LE > xx 00 00 xx UTF-16LE > xx 00 xx -- UTF-16LE > xx xx -- -- UTF-8 +1 for this reduced display. Stefan. From cabo@tzi.org Fri Jun 7 01:59:56 2013 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 0F8B421F8E9D for ; Fri, 7 Jun 2013 01:59:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w-SdW32IGgsv for ; Fri, 7 Jun 2013 01:59:50 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id E26E221F8F2F for ; Fri, 7 Jun 2013 01:59:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r578xha4017829; Fri, 7 Jun 2013 10:59:43 +0200 (CEST) Received: from [192.168.20.16] (unknown [84.88.52.198]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 100313140; Fri, 7 Jun 2013 10:59:43 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <255B9BB34FB7D647A506DC292726F6E1151B21F9A9@WSMSG3153V.srv.dir.telstra.com> Date: Fri, 7 Jun 2013 10:59:42 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <255B9BB34FB7D647A506DC292726F6E1151B21F9A9@WSMSG3153V.srv.dir.telstra.com> To: "Manger, James H" X-Mailer: Apple Mail (2.1503) Cc: "json@ietf.org" Subject: Re: [Json] Allow any JSON value at the top level X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 07 Jun 2013 08:59:56 -0000 On Jun 7, 2013, at 05:51, "Manger, James H" = wrote: > I propose allowing a JSON text to be any JSON value. >=20 > A JSON text is a serialization of any JSON value. >=20 > JSON-text =3D value Apart from the (intellectually nicely challenging, but practically = irrelevant) auto-detection thing, one other result is that JSON texts no = longer stream. RFC 4627 texts are self-delimiting, the new ones = wouldn't always be. Of course, if you want to stream sequences of JSON = texts, you could always limit those back to arrays or maps ("objects"). Gr=FC=DFe, Carsten From duerst@it.aoyama.ac.jp Fri Jun 7 02:04:00 2013 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 A406121F9485 for ; Fri, 7 Jun 2013 02:04:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.123 X-Spam-Level: X-Spam-Status: No, score=-103.123 tagged_above=-999 required=5 tests=[AWL=0.667, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n9+Xqol6Qzjl for ; Fri, 7 Jun 2013 02:03:54 -0700 (PDT) Received: from scintmta02.scbb.aoyama.ac.jp (scintmta02.scbb.aoyama.ac.jp [133.2.253.34]) by ietfa.amsl.com (Postfix) with ESMTP id DC66F21F8F6E for ; Fri, 7 Jun 2013 02:03:53 -0700 (PDT) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id r5793meZ003049; Fri, 7 Jun 2013 18:03:48 +0900 Received: from (unknown [133.2.206.134]) by scmse02.scbb.aoyama.ac.jp with smtp id 3a18_f509_2a164ff2_cf51_11e2_aaec_001e6722eec2; Fri, 07 Jun 2013 18:03:47 +0900 Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id 10766BF521; Fri, 7 Jun 2013 18:02:40 +0900 (JST) Message-ID: <51B1A1E2.7020202@it.aoyama.ac.jp> Date: Fri, 07 Jun 2013 18:03:30 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: "Joe Hildebrand (jhildebr)" References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Jacob Davies , "json@ietf.org" Subject: Re: [Json] The parts of JSON (a possible aid to discussion) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 07 Jun 2013 09:04:00 -0000 On 2013/06/07 6:31, Joe Hildebrand (jhildebr) wrote: > On 6/6/13 2:50 PM, "Jacob Davies" wrote: > The abstract model ought to be unconcerned with Unicode or any such > temporal specificity, and the only thing the specification need say > about the concrete models of implementation is to warn that they may > vary in what ranges and sizes and kinds of values they can represent, > including which characters they can faithfully represent. The "which values they can represent" part may work (to some extent, but see below) for numbers, but not for strings. It doesn't matter *how* they are represented (somebody in China might want to use GB 18030), but it matters very much *what* is represented. If you can show (or even just explain) an implementation of your JSON model that does not/cannot represent Unicode characters, but that is interoperable, then please do so. >> b) The description of strings as sequences of specifically Unicode >> characters is in my opinion misplaced in a section that otherwise is >> speaking in abstract terms. It is enough to say that a string is an >> indefinite-length sequence of (abstract) characters. [I see Douglas' >> last proposal for this section omits the mention of Unicode.] > > Unicode code points are suitably abstract. I agree that "character" is > probably not abstract enough. > >> This includes the description of and required interpretation of escape >> sequences, and here it says that \u escapes should be interpreted as >> representing Unicode characters (or parts of surrogate pairs). That's >> the only place in this part where anything concretely related to >> Unicode needs to be invoked and it should not dictate that all >> concrete model representations or all JSON texts or all byte >> serializations be Unicode, You don't need to use an Unicode encoding for concrete representation. You may not need an Unicode encoding for byte serialization. But you need a concrete representation, and a byte encoding, than will handle all strings of Unicode code points and no other strings. Regards, Martin. >> only that the Unicode tables be used to >> look up the character for \u escapes. > > I doubt you need to use the tables, except much later in the process when > turning the parsed code points into glyphs. > > I agree that in the abstract model, the only place you care about Unicode > is when reasoning about strings, however. In the abstract model, true is > an atom with a particular semantic, not the sequence of code points > corresponding to the characters t,r,u, and e. > > The rest of your message, while probably technically correct, effectively > says we're defining an infoset for JSON. I don't like where that got XML, > but the multiple potential wire encodings for JSON may necessitate the > extra level of abstraction, if we're going to be super-clear. > > Or we may elect to remain slightly fuzzy, and a lot easier to read. > From markus.lanthaler@gmx.net Fri Jun 7 02:04:55 2013 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 1E41A21F96FB for ; Fri, 7 Jun 2013 02:04:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.15 X-Spam-Level: X-Spam-Status: No, score=-1.15 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zzb-MlfCrmEY for ; Fri, 7 Jun 2013 02:04:49 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by ietfa.amsl.com (Postfix) with ESMTP id 0C78721F8F6E for ; Fri, 7 Jun 2013 02:04:48 -0700 (PDT) Received: from mailout-de.gmx.net ([10.1.76.29]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0LiFuH-1TybPg3esN-00nQAv for ; Fri, 07 Jun 2013 11:04:47 +0200 Received: (qmail invoked by alias); 07 Jun 2013 09:04:47 -0000 Received: from 84-115-182-43.dynamic.surfer.at (EHLO Vostro3500) [84.115.182.43] by mail.gmx.net (mp029) with SMTP; 07 Jun 2013 11:04:47 +0200 X-Authenticated: #419883 X-Provags-ID: V01U2FsdGVkX1+pFWR2GlepjawzAw0L6hcg/OH8T4O1YWEhVgtGzS Rt8aZJo194FLp0 From: "Markus Lanthaler" To: References: <51AF8479.5080002@crockford.com> <51b1168c.e686440a.5339.5fc4SMTPIN_ADDED_BROKEN@mx.google.com> In-Reply-To: Date: Fri, 7 Jun 2013 11:04:40 +0200 Message-ID: <009801ce635e$0bef7080$23ce5180$@lanthaler@gmx.net> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac5jE+PvH2bEj5xLTDODI7P1Tx6nyQASfdaw Content-Language: de X-Y-GMX-Trusted: 0 Subject: Re: [Json] The names within an object SHOULD be unique. X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 07 Jun 2013 09:04:55 -0000 On Friday, June 07, 2013 2:14 AM, Nico Williams wrote: >On Jun 6, 2013 6:09 PM, "Markus Lanthaler" = wrote: >> >> On Sent: Friday, June 07, 2013 12:22 AM, Nico Williams wrote: >> > Having thought this far, I propose this text: >> > >> > Encoders SHOULD NOT send duplicate keys. Some encoders might = not >> > be able to prevent duplicate keys. Therefore parsers MUST be = prepared >> > to handle duplicate keys. >> >> -1, it is very reasonable to reject such JSON. > >I wrote "handle", not "accept". If your "handle" implies that an error might be raised then it would be = OK but I believe most people wouldn't understand it that way. -- Markus Lanthaler @markuslanthaler From stefan@drees.name Fri Jun 7 02:09:00 2013 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 B6A1721F9485 for ; Fri, 7 Jun 2013 02:08:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aHxBp6rU7tBg for ; Fri, 7 Jun 2013 02:08:53 -0700 (PDT) Received: from mout.web.de (mout.web.de [212.227.15.3]) by ietfa.amsl.com (Postfix) with ESMTP id 2748321F92B8 for ; Fri, 7 Jun 2013 02:08:52 -0700 (PDT) Received: from newyork.local.box ([93.129.186.5]) by smtp.web.de (mrweb101) with ESMTPSA (Nemesis) id 0MCqsR-1UcJp303P9-009gwU; Fri, 07 Jun 2013 11:08:43 +0200 Message-ID: <51B1A317.4060105@drees.name> Date: Fri, 07 Jun 2013 11:08:39 +0200 From: Stefan Drees User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: =?ISO-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= References: <255B9BB34FB7D647A506DC292726F6E1151B21F79E@WSMSG3153V.srv.dir.telstra.com> <255B9BB34FB7D647A506DC292726F6E1151B21F8CA@WSMSG3153V.srv.dir.telstra.com> <51B17E54.9030107@drees.name> <51B19672.8040706@it.aoyama.ac.jp> In-Reply-To: <51B19672.8040706@it.aoyama.ac.jp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:tKTuz98j+8h3MKinT/ti4eP3kWrbz1cdG15nsa+Lwm9mq8WT6zK W95BA649YtKB7DgsoXKixuLvhDYcgRa3MAnbhQvKNsAaqP6UH4YEO9BvqAtaubpfZjel9tq bNx+Gum27qaQ/YYkn7mP43p3DWzaN35ng9gjarWZnwn/pL6GI7YcIMbCUqWXQf3GPvsgVp7 Fj/3yKtlzOCx6tHmmPWeQ== Cc: "Manger, James H" , "Joe Hildebrand \(jhildebr\)" , "json@ietf.org" Subject: Re: [Json] ABNF nits X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stefan@drees.name List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2013 09:09:00 -0000 On 2013-06-07 10:14, Martin J. Dürst wrote: > On 2013/06/07 15:31, Stefan Drees wrote: > >> If defining a grammar with real case-sensitive "word"-ish tokens in it, >> ABNF is IMO barely usable, unless you extend it with say single quotes >> as case-sensitve string delimiters. But then dealing with two kinds of >> strings also has it's catches =( > > Another way to do this is to just note that you are using ABNF *except > that literals are case-sensitive*. Piece of cake, if all words are case sensitive, but the devil is in the mix. As I stated above "with ... case-sensitive ... tokens in it" on purpose, and not "with ... case-sensitive ... tokens only" ;-) That is a situation where I prefer eg. ANTLR stating an easy to parse tokenCS: 'CaseSensitive' nicely different from the more varying tokenCIS: [Cc][Aa][Ss][Ee][Ii][Nn][Ss][Ee][Nn][Ss][Ii][Tt][Ii][Vv][Ee] But I think readability is in the eye of the reader and for JSON the grammar is set to be ABNF which is also fully sufficient. > I'm sure there's an RFC or two which have done so. ... To the enlightment of the readers, when feeding such a grammar into an ABNF tool =( I presume ... In Open Data we settled in the ABNF URL construction rules[1] for the upcoming version 4 on an explicit differentiating strategy and also provided a tool (adaption) [2] for translating into real ABNF. References: [1]: https://tools.oasis-open.org/version-control/browse/wsvn/odata/trunk/spec/ABNF/odata-abnf-construction-rules.txt?rev=356&sc=1 [2]: https://github.com/SAP/abnf-test-tool All the best, Stefan. From duerst@it.aoyama.ac.jp Fri Jun 7 02:16:42 2013 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 39E3521F8D16 for ; Fri, 7 Jun 2013 02:16:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.29 X-Spam-Level: X-Spam-Status: No, score=-103.29 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id flq4LVMh1YEo for ; Fri, 7 Jun 2013 02:16:35 -0700 (PDT) Received: from scintmta02.scbb.aoyama.ac.jp (scintmta02.scbb.aoyama.ac.jp [133.2.253.34]) by ietfa.amsl.com (Postfix) with ESMTP id B746F21F96F5 for ; Fri, 7 Jun 2013 02:16:34 -0700 (PDT) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id r579GRrR013381; Fri, 7 Jun 2013 18:16:27 +0900 Received: from (unknown [133.2.206.134]) by scmse02.scbb.aoyama.ac.jp with smtp id 3a18_fae9_eeab8840_cf52_11e2_aaec_001e6722eec2; Fri, 07 Jun 2013 18:16:26 +0900 Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id 58871BF521; Fri, 7 Jun 2013 18:15:19 +0900 (JST) Message-ID: <51B1A4D9.2030702@it.aoyama.ac.jp> Date: Fri, 07 Jun 2013 18:16:09 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: Paul Hoffman References: <38C1C408-3AF4-4CF2-96E1-9544C54B0531@vpnc.org> <5317EF10-6424-4F4C-A9FA-8709D917C848@vpnc.org> In-Reply-To: <5317EF10-6424-4F4C-A9FA-8709D917C848@vpnc.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "json@ietf.org" Subject: Re: [Json] Strings X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 07 Jun 2013 09:16:42 -0000 On 2013/06/07 1:52, Paul Hoffman wrote: > On Jun 6, 2013, at 9:43 AM, Matt Miller (mamille2) wrote: > >>>> Are you sure you want to open pandora's box of comparing strings? >>> >>> Yes. String comparison is used for object keys, which is a hot topic in another thread. >>> >>> { "a": 1, "\u0061": 2 } >>> >> >> To (probably vainly) help keep a lid on the box, do we need to note there is no expectation of normalization? > > We do *not* need to note that, because we can't define it in under a page of text. We might need more than a page to describe how we wanted to normalize strings if we wanted to normalize them. But to say that there is *no* such expectation doesn't take much more than a few lines of text, as show by Tim. Regards, Martin. From markus.lanthaler@gmx.net Fri Jun 7 02:21:32 2013 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 852E421F9702 for ; Fri, 7 Jun 2013 02:21:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.15 X-Spam-Level: X-Spam-Status: No, score=-1.15 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5fWFn8cwrcxF for ; Fri, 7 Jun 2013 02:21:09 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) by ietfa.amsl.com (Postfix) with ESMTP id 29E2E21F965B for ; Fri, 7 Jun 2013 02:21:09 -0700 (PDT) Received: from mailout-de.gmx.net ([10.1.76.24]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0M7WX3-1UQCiE1wCF-00xKda for ; Fri, 07 Jun 2013 11:21:05 +0200 Received: (qmail invoked by alias); 07 Jun 2013 09:21:05 -0000 Received: from 84-115-182-43.dynamic.surfer.at (EHLO Vostro3500) [84.115.182.43] by mail.gmx.net (mp024) with SMTP; 07 Jun 2013 11:21:05 +0200 X-Authenticated: #419883 X-Provags-ID: V01U2FsdGVkX18E3uhvlEIEbvfWHiL87V8Bc1Rh+UiRW2VuprqQNn 91D+4EedugQlzv From: "Markus Lanthaler" To: References: <255B9BB34FB7D647A506DC292726F6E1151B21F9A9@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: <255B9BB34FB7D647A506DC292726F6E1151B21F9A9@WSMSG3153V.srv.dir.telstra.com> Date: Fri, 7 Jun 2013 11:20:58 +0200 Message-ID: <00d601ce6360$52acce30$f8066a90$@lanthaler@gmx.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac5jMj7wK5i9s5prS+2npykXIGILbgALg8dA Content-Language: de X-Y-GMX-Trusted: 0 Subject: Re: [Json] Allow any JSON value at the top level X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 07 Jun 2013 09:21:39 -0000 On Friday, June 07, 2013 5:51 AM, Manger, James H wrote: > I propose allowing a JSON text to be any JSON value. > > A JSON text is a serialization of any JSON value. > > JSON-text = value > > value = false / null / true / object / array / number / string I'm strictly against this. Not only would it break many implementations but also specs build on top of JSON that rely on JSON-text = object / array. -- Markus Lanthaler @markuslanthaler From duerst@it.aoyama.ac.jp Fri Jun 7 02:28:59 2013 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 BD7AF21F96F2 for ; Fri, 7 Jun 2013 02:28:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.39 X-Spam-Level: X-Spam-Status: No, score=-103.39 tagged_above=-999 required=5 tests=[AWL=0.400, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IHnWgr3UDIfi for ; Fri, 7 Jun 2013 02:28:54 -0700 (PDT) Received: from scintmta02.scbb.aoyama.ac.jp (scintmta02.scbb.aoyama.ac.jp [133.2.253.34]) by ietfa.amsl.com (Postfix) with ESMTP id 7895E21F9702 for ; Fri, 7 Jun 2013 02:28:43 -0700 (PDT) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id r579SfSu022854; Fri, 7 Jun 2013 18:28:41 +0900 Received: from (unknown [133.2.206.134]) by scmse02.scbb.aoyama.ac.jp with smtp id 3a18_00cb_a4132ce6_cf54_11e2_aaec_001e6722eec2; Fri, 07 Jun 2013 18:28:40 +0900 Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id 2A4C3BF521; Fri, 7 Jun 2013 18:27:33 +0900 (JST) Message-ID: <51B1A7B7.8000701@it.aoyama.ac.jp> Date: Fri, 07 Jun 2013 18:28:23 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: Tim Bray References: <38C1C408-3AF4-4CF2-96E1-9544C54B0531@vpnc.org> <255B9BB34FB7D647A506DC292726F6E1151B21F57F@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Cc: "Manger, James H" , "json@ietf.org" Subject: Re: [Json] Strings X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 07 Jun 2013 09:28:59 -0000 On 2013/06/07 11:05, Tim Bray wrote: > +1 to either, I had it backward I have a very minimal preference for the second variant, but I'm happy=20 with either. > On Thu, Jun 6, 2013 at 6:03 PM, Manger, James H< > James.H.Manger@team.telstra.com> wrote: > >>> If keys are unicode strings, the proper languagee is: >>> =E2=80=9CFor purpose of establishing key equality, comparisons MUST b= e >> conducted, after all escaping is done, on a character-by-character bas= is by >> comparing numeric character codepoints. There is to be no modification= of >> any kind to the characters in keys, including case-changing or >> combining-form normalization.=E2=80=9D While we are at it, please change "codepoint" to "code point". That's=20 how Unicode spells it. I'm not exactly happy with the "there is to be no" part. I guess that=20 was an attempt at avoiding a MUST or MUST NOT. I don't think that's=20 necessary, we are already on a normative level. Also, I'd prefer to=20 avoid long nouns. So what about: "There MUST NOT be any modification of any kind to the characters in=20 keys, including change of case or change between precomposed and=20 decomposed forms.". or if we want to avoid another normative UPPER CASE, then something like "Modifications of any kind to the characters in keys, including change=20 of case or change between precomposed and decomposed forms." A more correct way to express the last part ("change between precomposed=20 and decomposed forms") would be "or change between canonically=20 equivalents or compatibility equivalents [UAX #15]", where UAX #15 is http://www.unicode.org/reports/tr15/. That's because=20 Unicode normalization includes things such as singletons, which have=20 nothing to do with a precomposed/decomposed choice. Regards, Martin. >> s/after all escaping is done/after all unescaping is done/ >> >> or should that be >> >> s/after all escaping is done/after all escaping is undone/ >> >> -- >> James Manger >> _______________________________________________ >> json mailing list >> json@ietf.org >> https://www.ietf.org/mailman/listinfo/json >> > > > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json From stefan@drees.name Fri Jun 7 03:23:09 2013 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 9DED521F93C4 for ; Fri, 7 Jun 2013 03:23:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.93 X-Spam-Level: X-Spam-Status: No, score=-1.93 tagged_above=-999 required=5 tests=[AWL=-0.281, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_22=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fGSAvTLie6LI for ; Fri, 7 Jun 2013 03:22:58 -0700 (PDT) Received: from mout.web.de (mout.web.de [212.227.17.11]) by ietfa.amsl.com (Postfix) with ESMTP id 3E38321F8E89 for ; Fri, 7 Jun 2013 03:22:57 -0700 (PDT) Received: from newyork.local.box ([93.129.186.5]) by smtp.web.de (mrweb101) with ESMTPSA (Nemesis) id 0LpwB1-1U8WOR36db-00ffl6; Fri, 07 Jun 2013 12:22:53 +0200 Message-ID: <51B1B47C.9060009@drees.name> Date: Fri, 07 Jun 2013 12:22:52 +0200 From: Stefan Drees User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Markus Lanthaler References: <51AF8479.5080002@crockford.com> <51b1168c.e686440a.5339.5fc4SMTPIN_ADDED_BROKEN@mx.google.com> <009801ce635e$0bef7080$23ce5180$@lanthaler@gmx.net> In-Reply-To: <009801ce635e$0bef7080$23ce5180$@lanthaler@gmx.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:oaeNwssZ+xzM/HCHfj7mVijbElPnVh+TFciVDS3BBka2Kqb4fw7 /G/o2XmNI0IhFgu0K9+e5bKyZBIUmmjI4LTUX/dZ0aNOOuUlPIgMAAJz/rE04a57wpatLZD K5dIrArhDfYHvaQOka0rDfxID/tAJjtARJ8bEF7P2rUdJAgPXCHND+8uxntR/2IbnrM+tHX /NmArJOIdmPcO2LH/x+6A== Cc: json@ietf.org Subject: Re: [Json] The names within an object SHOULD be unique. X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stefan@drees.name List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2013 10:23:09 -0000 On 2013-06-07 11:04, Markus Lanthaler wrote: > On Friday, June 07, 2013 2:14 AM, Nico Williams wrote: >> On Jun 6, 2013 6:09 PM, "Markus Lanthaler" wrote: >>> >>> On Sent: Friday, June 07, 2013 12:22 AM, Nico Williams wrote: >>>> Having thought this far, I propose this text: >>>> >>>> Encoders SHOULD NOT send duplicate keys. Some encoders might not >>>> be able to prevent duplicate keys. Therefore parsers MUST be prepared >>>> to handle duplicate keys. >>> >>> -1, it is very reasonable to reject such JSON. >> >> I wrote "handle", not "accept". > > If your "handle" implies that an error might be raised then it would > be OK but I believe most people wouldn't understand it that way. weighting the part following the "but" I read (and second) this as -1 In case TL;DR please goto "TL;DR" Three further remarks ignited in me by the above text (that was proposed by Nico Williams): """ Encoders SHOULD NOT send duplicate keys. Some encoders might not be able to prevent duplicate keys. Therefore parsers MUST be prepared to handle duplicate keys. """ Which b.t.w. I would certainly rewrite as: NEW """ Generators SHOULD NOT duplicate names in objects. Parsers MUST be prepared to either accept duplicate names in objects or reject the complete JSON text containing these, as a generator might not avoid nor detect such duplication. """ "TL;DR": Above is my proposal if we really want to change the current wording and if we settle on the terms generator and parser. Otherwise replace with encoder and decoder ;-) Now for something completely different (the promised remarks): A) encoders relate to parsers? There seem to be some projections of the spec we really need to check periodically, so not "hypernyms" slip in ... Let us please not cross-mix members of dimensional pairs: * ("encoder","decoder") * ("accept","reject") * ("interpret","ignore") * ("generator","parser") * ("producer","consumer") * ("sender","receiver") * ("service","client") * ... B) We can "handle" anything :-) The verb "handle" IMO is related to far too many possible actions: accept, reject, interpret, ignore all jump to my mind, when I'm requested to handle something. On a more higher level the robustness principle (a.k.a. Postel’s law) cf. [RFC1122]: "Be liberal in what you accept, and conservative in what you send" (*) might at first glance help advice the participants in the lax historically grown state we're, **but** 1. we now have all kind of JSON consumers ranging from the brittle ("picky") to the robust ("close to blind"). 2. we define a format, and not a "JSON service" or the like As I understood, we do not change practical usage of the spec, but on occasion of augmenting the RFC to STD and avoiding a cyclic normative referencing between JSON RFC and ECMAScript spec we perform "some non interupting hygienic actions". So I think there will be only microscopic changes (compared to the old RFC) on this topic left over after consensus calls. C) "names" are not "keys" Again in above text (and at the heart of the discussion IMO) we take the "name"s of the object members as "key" but do not say so in the RFC, and did not in the original. This semantic difference and the historical fact that it was not spelled out in the original RFC gently directs us to just leave the "names" condition as is, and not start expressing our whishful thinking, we could simply rename these as "key" and have all the uniqueness readily at hand. References: [RFC1122]: Braden, R., Ed., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989. http://www.ietf.org/rfc/rfc1122.txt. *): I know RFC791 is historically the first similar mention, but it is obsoleted as RFC, so ... All the best, Stefan. From duerst@it.aoyama.ac.jp Fri Jun 7 03:25:17 2013 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 3CF4421F8F2F for ; Fri, 7 Jun 2013 03:25:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.457 X-Spam-Level: X-Spam-Status: No, score=-103.457 tagged_above=-999 required=5 tests=[AWL=0.333, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HHNb8vh1S+KD for ; Fri, 7 Jun 2013 03:25:11 -0700 (PDT) Received: from scintmta02.scbb.aoyama.ac.jp (scintmta02.scbb.aoyama.ac.jp [133.2.253.34]) by ietfa.amsl.com (Postfix) with ESMTP id 1043821F8E89 for ; Fri, 7 Jun 2013 03:25:10 -0700 (PDT) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id r57AOw1X002780; Fri, 7 Jun 2013 19:24:58 +0900 Received: from (unknown [133.2.206.134]) by scmse02.scbb.aoyama.ac.jp with smtp id 3a18_1b26_81159aa0_cf5c_11e2_aaec_001e6722eec2; Fri, 07 Jun 2013 19:24:58 +0900 Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id 65FA0BF521; Fri, 7 Jun 2013 19:23:50 +0900 (JST) Message-ID: <51B1B4E7.8090101@it.aoyama.ac.jp> Date: Fri, 07 Jun 2013 19:24:39 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: Tim Bray References: <51B06F38.8050707@crockford.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Cc: "json@ietf.org" , Paul Hoffman , Douglas Crockford , "Joe Hildebrand \(jhildebr\)" Subject: Re: [Json] Unpaired surrogates in JSON strings X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 07 Jun 2013 10:25:17 -0000 On 2013/06/06 23:57, Tim Bray wrote: > F0, 90, 8D, 86 > On Thu, Jun 6, 2013 at 4:15 AM, Douglas Crockfordwrote: > >> What then is the standard name for a 16-bit element of text? When >> JavaScript was created, that word was character. What is the word now? >> > > The only somewhat-standardized term would be =E2=80=9CUTF-16 codepoint=E2= =80=9D. But > that=E2=80=99s not really a =E2=80=9Cunit of text=E2=80=9D any more tha= n the 2nd byte of a > character encoded in 3 bytes with UTF-8 is. > > I=E2=80=99m fairly shocked. I have always believed that JSON encodes w= hat its > introduction (and section 2.5 "Strings") say it encodes, Unicode > characters. > > If it is a requirement to accommodate the class of bug where languages = that > use UTF-16 (Java, JavaScript, C#) can emit unpaired UTF-16 surrogates, = the > spec needs to be clear that the INTENT is actually to support Unicode > characters, and that unpaired surrogates are always evidence of a bug, = and > there can be no expectation that any software receiving such buggy data > will be able to do anything useful with it, or even avoid crashing in a > hard-to-debug way down in the bowels of a library routine. -T I fully agree with what Tim says above: We know (and to a certain extent=20 have to accept) that there are implementations that, surely way more by=20 accident than by any kind of intent, send unpaired surrogates. But we=20 should try to do whatever we can in the spec to make it perfectly clear=20 that there are no good reasons whatsoever to actually do that. Although we may not end up with exactly parallel or equivalent language,=20 I think the situation is fairly similar to the one regarding duplicate=20 keys: The current spec isn't totally clear, and in practice it happens,=20 and for some implementations, it may be an unreasonable burden to=20 require to check everything on sending, but it's not something that one=20 would or should do on purpose. A second point: Just to get the correct definitions from the Unicode side, here are the=20 easiest references, everything on a page: http://www.unicode.org/glossary/ In a few of my mails today, I have also used "code point", but I didn't=20 intend to include surrogates. There's a better term, namely Unicode Scalar Value=20 (http://www.unicode.org/glossary/#unicode_scalar_value): Any Unicode code point except high-surrogate and low-surrogate code=20 points. In other words, the ranges of integers 0 to D7FF16 and E00016 to=20 10FFFF16 inclusive. (See definition D76 in Section 3.9, Unicode Encoding=20 Forms.) Regards, Martin. From derhoermi@gmx.net Fri Jun 7 03:42:27 2013 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 E2BEA21F8F2F for ; Fri, 7 Jun 2013 03:42:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2nbhXEQJdL2t for ; Fri, 7 Jun 2013 03:42:22 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) by ietfa.amsl.com (Postfix) with ESMTP id B568221F8E93 for ; Fri, 7 Jun 2013 03:42:21 -0700 (PDT) Received: from mailout-de.gmx.net ([10.1.76.10]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0Lh9yb-1TzhPw1lzz-00oWSz for ; Fri, 07 Jun 2013 12:42:19 +0200 Received: (qmail invoked by alias); 07 Jun 2013 10:42:18 -0000 Received: from p5B2339AC.dip0.t-ipconnect.de (EHLO netb.Speedport_W_700V) [91.35.57.172] by mail.gmx.net (mp010) with SMTP; 07 Jun 2013 12:42:18 +0200 X-Authenticated: #723575 X-Provags-ID: V01U2FsdGVkX19xk51s8VNxRxq+SakGNTB8L4sB+oiNuYfP6bewdh tBSsaYJuPAG7q0 From: Bjoern Hoehrmann To: =?ISO-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= Date: Fri, 07 Jun 2013 12:42:17 +0200 Message-ID: <9ld3r8pc0tufif18dohb2fmi0ijna1vs4n@hive.bjoern.hoehrmann.de> References: <51B06F38.8050707@crockford.com> <51B1B4E7.8090101@it.aoyama.ac.jp> In-Reply-To: <51B1B4E7.8090101@it.aoyama.ac.jp> X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 Cc: "json@ietf.org" Subject: Re: [Json] Unpaired surrogates in JSON strings X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 07 Jun 2013 10:42:27 -0000 * Martin J. Dürst wrote: >I fully agree with what Tim says above: We know (and to a certain extent >have to accept) that there are implementations that, surely way more by >accident than by any kind of intent, send unpaired surrogates. But we >should try to do whatever we can in the spec to make it perfectly clear >that there are no good reasons whatsoever to actually do that. Actually there are many good reasons for having unpaired surrogates in JSON documents. A simple example would be a test suite for string APIs. -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ From derhoermi@gmx.net Fri Jun 7 03:49:49 2013 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 710BC21F8EF2 for ; Fri, 7 Jun 2013 03:49:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.419 X-Spam-Level: X-Spam-Status: No, score=-2.419 tagged_above=-999 required=5 tests=[AWL=-0.120, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qnEWvhVu22Yo for ; Fri, 7 Jun 2013 03:49:44 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by ietfa.amsl.com (Postfix) with ESMTP id 3127721F8FE5 for ; Fri, 7 Jun 2013 03:49:44 -0700 (PDT) Received: from mailout-de.gmx.net ([10.1.76.29]) by mrigmx.server.lan (mrigmx002) with ESMTP (Nemesis) id 0MevCx-1V04eD1rAX-00OYMX for ; Fri, 07 Jun 2013 12:49:40 +0200 Received: (qmail invoked by alias); 07 Jun 2013 10:49:40 -0000 Received: from p5B2339AC.dip0.t-ipconnect.de (EHLO netb.Speedport_W_700V) [91.35.57.172] by mail.gmx.net (mp029) with SMTP; 07 Jun 2013 12:49:40 +0200 X-Authenticated: #723575 X-Provags-ID: V01U2FsdGVkX1+JjMBycySJIDpVcq92+PxsK7zkOwoFQTFKLC7tbc kK00Zivl8XLVVd From: Bjoern Hoehrmann To: =?ISO-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= Date: Fri, 07 Jun 2013 12:49:39 +0200 Message-ID: <6fe3r8h0apir4ftn05ab71tmtgeve4s274@hive.bjoern.hoehrmann.de> References: <255B9BB34FB7D647A506DC292726F6E1151B21F79E@WSMSG3153V.srv.dir.telstra.com> <255B9BB34FB7D647A506DC292726F6E1151B21F8CA@WSMSG3153V.srv.dir.telstra.com> <51B17E54.9030107@drees.name> <51B19672.8040706@it.aoyama.ac.jp> In-Reply-To: <51B19672.8040706@it.aoyama.ac.jp> X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 Cc: json@ietf.org Subject: Re: [Json] ABNF nits X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 07 Jun 2013 10:49:49 -0000 * Martin J. Dürst wrote: >Another way to do this is to just note that you are using ABNF *except >that literals are case-sensitive*. I'm sure there's an RFC or two which >have done so. Sadly. -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ From jsontest@yahoo.com Fri Jun 7 05:33:04 2013 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 6A7B021F8F0E for ; Fri, 7 Jun 2013 05:33:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.749 X-Spam-Level: X-Spam-Status: No, score=0.749 tagged_above=-999 required=5 tests=[AWL=-0.463, BAYES_40=-0.185, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TCPnwwTEj5iI for ; Fri, 7 Jun 2013 05:32:58 -0700 (PDT) Received: from nm42-vm1.bullet.mail.bf1.yahoo.com (nm42-vm1.bullet.mail.bf1.yahoo.com [216.109.114.188]) by ietfa.amsl.com (Postfix) with ESMTP id 7F3C621F8B35 for ; Fri, 7 Jun 2013 05:32:57 -0700 (PDT) Received: from [98.139.215.142] by nm42.bullet.mail.bf1.yahoo.com with NNFMP; 07 Jun 2013 12:32:56 -0000 Received: from [98.139.211.203] by tm13.bullet.mail.bf1.yahoo.com with NNFMP; 07 Jun 2013 12:32:56 -0000 Received: from [127.0.0.1] by smtp212.mail.bf1.yahoo.com with NNFMP; 07 Jun 2013 12:32:56 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1370608376; bh=lP953Am7HxPxdU42AjqZdTNBx+KaOqo69FHGl4YdBlw=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:References:In-Reply-To:Mime-Version:Content-Type:Content-Transfer-Encoding:Message-Id:Cc:X-Mailer:From:Subject:Date:To; b=n6xxfLN+wYbogC+qjXFAD74vAoPY7pmsXsB3IUtMQwLWnz8XJR9qX5c5UDFZ7Hj33GgLe2dSfhgISVNWr03Npccqym/r+IGjnG9/ypKgUWXuKq1pLL5z6bJHqNVNOn3uSR0LDJXITujhEZ/qM3SttynkKv0hMns5BHyc43iUE9s= X-Yahoo-Newman-Id: 192338.40308.bm@smtp212.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: VSvjossVM1m_gf0OArBgYgrnTnBXuOfuq7tVjmR34BaVSc4 HzfvEFjcATx4XxSedtGHvscxtrnxjG_ahhUuoyZtnRSZZrIY5id.OrlBfY_n mZEtno9wdWtJTRoBe5f2WqvymPkuVgwassQTerMRAu4cjWQ5lejJTTyFOs43 HTE6JAOFoSc9Lgqgmz2VOcLZk5o6Z6g9wkm2ZQLQkLiqfxk3E40Pkw72quT0 Qx8nebwVPJutPsaZIINjwhY1Qw9Rklck_SQ8HkAZH6VVYGG26f3TxCczgvIR jMgKkcXIp5J2jKO9dKcSFeZ_LBKrAmA6i.UL25XpUagqudVWIdL3ipPv1Ttp 85xHIOglW2vnRUa8fZAW4VW.5G8hGrSyO2hCL98MzD9gKdNYyop.B06PkIQz aw1JEwv58LnY6hADm_2vvE6Dar2impOfmRWDSX60NcDBhkU_d1Obj1ucNX8c t.cDKd3lpXV1rlIapRoiPtA-- X-Yahoo-SMTP: indQcmSswBC8IKsm6t4aCAPskK3T X-Rocket-Received: from [192.168.0.102] (jsontest@76.29.100.42 with ) by smtp212.mail.bf1.yahoo.com with SMTP; 07 Jun 2013 05:32:56 -0700 PDT References: <20130606225906.GO3090@mercury.ccil.org> In-Reply-To: Mime-Version: 1.0 (1.0) Content-Type: multipart/alternative; boundary=Apple-Mail-0AAD4060-4AFC-4BF2-8855-5ED2FF2FD813 Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: iPod Mail (9B206) From: Vinny A Date: Fri, 7 Jun 2013 07:32:52 -0500 To: Pete Cordell Cc: Nico Williams , John Cowan , Douglas Crockford , "json@ietf.org" Subject: Re: [Json] Parser and encoder options (Re: The names within an object SHOULD be unique.) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 07 Jun 2013 12:33:04 -0000 --Apple-Mail-0AAD4060-4AFC-4BF2-8855-5ED2FF2FD813 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jun 7, 2013, at 3:41 AM, "Pete Cordell" wrote: > Douglas said the text "The names within an object SHOULD be unique" should= have been "The names within an object MUST be unique". IMO by defining a f= all-back mechanism we're justifying having non-unique names and we're actual= ly weakening the requirement to something like "The names within an object M= AY be unique". Is that the direction we want to go in? Unfortunately enough, yes. I agree with you that the best course of action w= ould be to switch to a MUST; however Douglas has also indicated a need to pr= eserve backward-compatibility as well. See this previous message: > On Jun 5, 2013, at 4:56 PM, Douglas Crockford > wrote: > > There are people who interpreted the SHOULD as DON'T HAVE TO and intenti= onally duplicated the keys. My personal feeling is that we should change the= SHOULD to MUST and let those applications break. But the consensus of ECMA T= C39 is that the SHOULD must stand. So since the SHOULD is standing, we absolutely must have a plan for those pa= rsers and emitters that are=20= --Apple-Mail-0AAD4060-4AFC-4BF2-8855-5ED2FF2FD813 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On J= un 7, 2013, at 3:41 AM, "Pete Cordell" <petejson@codalogic.com> wrote:
Douglas said the text "The names within an object SHOULD be uni= que" should have been "The names within an object MUST be unique".  IMO= by defining a fall-back mechanism we're justifying having non-unique names a= nd we're actually weakening the requirement to something like "The names wit= hin an object MAY be unique".  Is that the direction we want to go in?<= /span>

Unfortunately enough, yes. I agree w= ith you that the best course of action would be to switch to a MUST; however= Douglas has also indicated a need to preserve backward-compatibility as wel= l. See this previous message:

= On Jun 5, 2013, at 4:56 P= M, Douglas Crockford <douglas@crockford.= com<mailto:douglas@crockford.com&= gt;> wrote:
> There are people who interpreted t= he SHOULD as DON'T HAVE TO and intentionally duplicated the keys. My persona= l feeling is that we should change the SHOULD to MUST and let those applicat= ions break. But the consensus of ECMA TC39 is that the SHOULD must stand.

So since the SHOULD is sta= nding, we absolutely must have a plan for those parsers and emitters that ar= e 
= --Apple-Mail-0AAD4060-4AFC-4BF2-8855-5ED2FF2FD813-- From sgbeal@googlemail.com Fri Jun 7 06:06:54 2013 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 A7D6721F85C3 for ; Fri, 7 Jun 2013 06:06:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.546 X-Spam-Level: X-Spam-Status: No, score=-1.546 tagged_above=-999 required=5 tests=[AWL=0.431, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H9jPzP9qBxSQ for ; Fri, 7 Jun 2013 06:06:52 -0700 (PDT) Received: from mail-wg0-x22a.google.com (mail-wg0-x22a.google.com [IPv6:2a00:1450:400c:c00::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 408BC21F859B for ; Fri, 7 Jun 2013 06:06:52 -0700 (PDT) Received: by mail-wg0-f42.google.com with SMTP id n12so1317060wgh.3 for ; Fri, 07 Jun 2013 06:06:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=mUbJw5FbufStv8d2dokdaqyiMjmkR2WjWRPkhLA65C8=; b=HhhoJBVaVKzGK0+I2a0msp0ebgc4+uFkckZUKK2J8XxoaQT6p4lRST8E1+MhG88oPX ITkFYPWi5ydny36sEE7XMB9GKLfUnquVL6BMKxEZ/Kvd8qHuAWCsQ3/6Yw7wcNWnfRZw B76AZX2rQSkCXKqeDN0T3/daJ2L45i365uo88kEHC66e3C2OA41JJdk94HGaMx+iL0tg RwGCm4QYjwZGbPNEvka5UWgWNPdy78f7lLAGZi/YMsXfFrBGPOFJCx5+d7UitJKmKCk6 +slaPoZF84f0Dng9wu3wJcYtEa2Yfu8e/mMfC5ns7QK+pHrDBLzK6f41zb+38uPiMU2m lzPQ== MIME-Version: 1.0 X-Received: by 10.194.179.102 with SMTP id df6mr35722545wjc.42.1370610411258; Fri, 07 Jun 2013 06:06:51 -0700 (PDT) Received: by 10.194.42.230 with HTTP; Fri, 7 Jun 2013 06:06:51 -0700 (PDT) In-Reply-To: <51b1a644.2988440a.183c.ffff9523SMTPIN_ADDED_BROKEN@mx.google.com> References: <255B9BB34FB7D647A506DC292726F6E1151B21F9A9@WSMSG3153V.srv.dir.telstra.com> <51b1a644.2988440a.183c.ffff9523SMTPIN_ADDED_BROKEN@mx.google.com> Date: Fri, 7 Jun 2013 15:06:51 +0200 Message-ID: From: Stephan Beal To: Markus Lanthaler Content-Type: multipart/alternative; boundary=089e01493c34b049ef04de901a95 Cc: "json@ietf.org" Subject: Re: [Json] Allow any JSON value at the top level X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 07 Jun 2013 13:06:54 -0000 --089e01493c34b049ef04de901a95 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Jun 7, 2013 at 11:20 AM, Markus Lanthaler wrote: > I'm strictly against this. Not only would it break many implementations but > also specs build on top of JSON that rely on JSON-text = object / array. > +Inf (even though JSON doesn't support it ;) -- ----- stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal --089e01493c34b049ef04de901a95 Content-Type: text/html; charset=ISO-8859-1
On Fri, Jun 7, 2013 at 11:20 AM, Markus Lanthaler <markus.lanthaler@gmx.net> wrote:
I'm strictly against this. Not only would it break many implementations but
also specs build on top of JSON that rely on JSON-text = object / array.

+Inf

(even though JSON doesn't support it ;)

--
----- stephan beal
http://wanderinghorse.net/home/stephan/
--089e01493c34b049ef04de901a95-- From jsontest@yahoo.com Fri Jun 7 06:38:25 2013 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 01FDF21F92E3 for ; Fri, 7 Jun 2013 06:38:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.264 X-Spam-Level: X-Spam-Status: No, score=0.264 tagged_above=-999 required=5 tests=[AWL=-1.467, BAYES_50=0.001, IP_NOT_FRIENDLY=0.334, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ab7O23RmlrnK for ; Fri, 7 Jun 2013 06:38:19 -0700 (PDT) Received: from nm43.bullet.mail.gq1.yahoo.com (nm43.bullet.mail.gq1.yahoo.com [67.195.87.83]) by ietfa.amsl.com (Postfix) with ESMTP id 6B40621F91A3 for ; Fri, 7 Jun 2013 06:38:19 -0700 (PDT) Received: from [98.137.12.189] by nm43.bullet.mail.gq1.yahoo.com with NNFMP; 07 Jun 2013 13:38:18 -0000 Received: from [208.71.42.209] by tm10.bullet.mail.gq1.yahoo.com with NNFMP; 07 Jun 2013 13:38:18 -0000 Received: from [127.0.0.1] by smtp220.mail.gq1.yahoo.com with NNFMP; 07 Jun 2013 13:38:18 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1370612298; bh=wLx3Ofr/rw2mMcKlYXLCKzjoUEU7+gH4UNJPR43rv8I=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:References:In-Reply-To:Mime-Version:Content-Type:Content-Transfer-Encoding:Message-Id:Cc:X-Mailer:From:Subject:Date:To; b=bq/Kq3P7G//190Ou0Er6bXS4x/j06NkQeMc4YlUxL2gdhYdNmluxq8srA2JTb6E+d3GdH291NW0P81rRkQiRO1/6ZQoYvY3AQmDZ/IoxJLOiujnJiP8Bt3UnWbzF2L2nhVP3aXHNN9v2TqhHXz1PAtqBvVSjlsTr5B8pjBMnHaE= X-Yahoo-Newman-Id: 130656.68929.bm@smtp220.mail.gq1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: qyvGwpgVM1l66DL3qtrevuUkPOTZYT.K5EzxhsXOcEbeHvT CEBFiLO6z_YsrbBznKs7XyGdITUrPCpJB1t22tmdEnl01pcZ73Wzpp_lL0FD 4q3c.EW13ho.2rpL8Kbseeunc_aoWNjjmHzZ4vBIN9HAARg9eTyvqus874Er aC0xfchuIwUj3zuFnupCvy9QfmzJB0DfbmxS2SvXiSX95smKLf5bnelAvGNE VIMsWEbKKba6nTTI7k5zdzU18o2nI8JePrRswcinm42QaeUeC9mKAbWKhCQd WnyZSaELRXNgvXyJo6YEUT6ak_NJn3AjiLv_irDlcYHcTRnPausHCeGzTnNN b33kQdyiTm9rgyxYXvYNISvNRDrFPTt4SxdGii55.14ossQeVgk1JzbkQ7US Mo646YsixGsWbMEDBQyne72DHwlSbb85XSB6wW0iqWC8fK800ewqW1uiltgB 2o.FmOTnfvsNWIjQT8ygTGWvdy9aePCaSFwtYT2xDen5zM97kzs38O9kksB. Zc2VkuIGW2lYlEQl17MTBdnZr3A-- X-Yahoo-SMTP: indQcmSswBC8IKsm6t4aCAPskK3T X-Rocket-Received: from [192.168.10.95] (jsontest@64.134.39.87 with ) by smtp220.mail.gq1.yahoo.com with SMTP; 07 Jun 2013 13:38:17 +0000 UTC References: <255B9BB34FB7D647A506DC292726F6E1151B21F9A9@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: Mime-Version: 1.0 (1.0) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPod Mail (9B206) From: Vinny A Date: Fri, 7 Jun 2013 08:38:15 -0500 To: Carsten Bormann Cc: "Manger, James H" , "json@ietf.org" Subject: Re: [Json] Allow any JSON value at the top level X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 07 Jun 2013 13:38:25 -0000 On Jun 7, 2013, at 3:59 AM, Carsten Bormann wrote: > Apart from auto-detection, one other result is that JSON texts no longer s= tream. RFC 4627 texts are self-delimiting, the new ones wouldn't always be.= Of course, if you want to stream sequences of JSON texts, you could always= limit those back to arrays or maps I'm +0 on this topic, partly for Carsten's reason, but also because this loo= ks to be a breaking change. Do commonly used parsers support top level JSON values? ----------------- Vinny www.jsontest.com From jsontest@yahoo.com Fri Jun 7 06:38:41 2013 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 4743721F91A3 for ; Fri, 7 Jun 2013 06:38:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.073 X-Spam-Level: * X-Spam-Status: No, score=1.073 tagged_above=-999 required=5 tests=[AWL=-0.324, BAYES_50=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZE3S9rxx2rar for ; Fri, 7 Jun 2013 06:38:34 -0700 (PDT) Received: from nm30-vm0.bullet.mail.bf1.yahoo.com (nm30-vm0.bullet.mail.bf1.yahoo.com [98.139.213.126]) by ietfa.amsl.com (Postfix) with ESMTP id 2FBD621F936E for ; Fri, 7 Jun 2013 06:38:33 -0700 (PDT) Received: from [98.139.212.153] by nm30.bullet.mail.bf1.yahoo.com with NNFMP; 07 Jun 2013 13:38:32 -0000 Received: from [98.139.211.204] by tm10.bullet.mail.bf1.yahoo.com with NNFMP; 07 Jun 2013 13:38:32 -0000 Received: from [127.0.0.1] by smtp213.mail.bf1.yahoo.com with NNFMP; 07 Jun 2013 13:38:32 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1370612312; bh=emDz8kbPm9VoYRhkad0gIpNFQISixPfP9MGtw8RLEco=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:References:In-Reply-To:Mime-Version:Content-Type:Content-Transfer-Encoding:Message-Id:Cc:X-Mailer:From:Subject:Date:To; b=c6zAkuoMCQ0vjeO6JrkFC4xC42sM3RSEJvqTHhvDOfh3bayTCuLwWeCo3isf7uW6LkcBzaZ6xBROI7LqRa61rlqvHefrZ2mBSaqIM0GUjzqyBpJgFNPWi6EUPJaBEHGOVson75vNo6KFMHeDDl8vc47DmFuajjqIQu+81mdDAmw= X-Yahoo-Newman-Id: 611968.43508.bm@smtp213.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: V.IQBCwVM1mspPwQa7Agt1D_lMpmFxxc4NsxBC.xspqR1og ot0RLQdSkaOkpfyunk5s.TctEzLRYfdgujpWq5EnA9Aw5dgUFZcsUTyq3yBb l5VeCcyQubVw92yUJW5nT7PTJi.XLPrYioAwdbEYLJWrQPQyfX_Vm.edcwGR BY2R3ixaftqiBgKI6kDWrHjz_JPr7MAhURrxqr4uSYIW0ULA69gyK_.Cc6hY YGM6DCzheltD5YD5Xjz5rYOPeJ7jxZJdkLcGijSUuC9n7NAdO6g_WeAAiFEK 1KBt5RSLQ.uLGSiyV763iqXVM3pnN_Z_ZltWKpjjMRnDFiArVNK9HitrOvRH es4hPJacfneL3UhR91FzzC2qQw9bz0amEjTWvCAaVfCkA6ogd0R5O.pbqaJj YFt2YMQ.fFTPznX.dbaUl8fnwPyq.QnRcHbs55GnzJRNaIQWsijRdJWAL4LZ l_FQt74Uazzu6ltSPcdtjAGfYrhb1wToGL4zKSMObe92lVbmyydTg.j5Kpqi 6pF84AwbaLJo073acHFd95Dmcew-- X-Yahoo-SMTP: indQcmSswBC8IKsm6t4aCAPskK3T X-Rocket-Received: from [192.168.10.95] (jsontest@64.134.39.87 with ) by smtp213.mail.bf1.yahoo.com with SMTP; 07 Jun 2013 06:38:32 -0700 PDT References: <51AF8479.5080002@crockford.com> <51b1168c.e686440a.5339.5fc4SMTPIN_ADDED_BROKEN@mx.google.com> <009801ce635e$0bef7080$23ce5180$@lanthaler@gmx.net> <51B1B47C.9060009@drees.name> In-Reply-To: <51B1B47C.9060009@drees.name> Mime-Version: 1.0 (1.0) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPod Mail (9B206) From: Vinny A Date: Fri, 7 Jun 2013 08:38:31 -0500 To: "stefan@drees.name" Cc: Markus Lanthaler , "json@ietf.org" Subject: Re: [Json] The names within an object SHOULD be unique. X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 07 Jun 2013 13:38:41 -0000 On Jun 7, 2013, at 5:22 AM, Stefan Drees wrote: > Which b.t.w. I would certainly rewrite as: >=20 > NEW > """ > Generators SHOULD NOT duplicate names in objects. Parsers MUST be prepare= d to either accept duplicate names in objects or reject the complete JSON te= xt containing these, as a generator might not avoid nor detect such duplicat= ion. > """ For the sake of readability, can you split this proposed text into separate p= rescriptions for parsers and emitters? I.e. section 4 of the RFC is for pars= ers, section 5 is for generators, put their respective advice into the appro= priate sections. ----------------- Vinny www.jsontest.com From stefan@drees.name Fri Jun 7 07:07:20 2013 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 A385421F8916 for ; Fri, 7 Jun 2013 07:07:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.199 X-Spam-Level: X-Spam-Status: No, score=-2.199 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BboZy2GMm2Ab for ; Fri, 7 Jun 2013 07:07:14 -0700 (PDT) Received: from mout.web.de (mout.web.de [212.227.17.12]) by ietfa.amsl.com (Postfix) with ESMTP id 82A4F21F8994 for ; Fri, 7 Jun 2013 07:07:12 -0700 (PDT) Received: from newyork.local.box ([93.129.186.5]) by smtp.web.de (mrweb102) with ESMTPSA (Nemesis) id 0M9GJ0-1UfyBI2aRa-00Cljl; Fri, 07 Jun 2013 16:07:06 +0200 Message-ID: <51B1E909.2010402@drees.name> Date: Fri, 07 Jun 2013 16:07:05 +0200 From: Stefan Drees User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Vinny A References: <51AF8479.5080002@crockford.com> <51b1168c.e686440a.5339.5fc4SMTPIN_ADDED_BROKEN@mx.google.com> <009801ce635e$0bef7080$23ce5180$@lanthaler@gmx.net> <51B1B47C.9060009@drees.name> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V02:K0:9mgSxfvTiSDiaMjSuFSwlshhOW4P5K57Pml4cslMR+y oEBPBLBLU8Eyci17Tp5ueCl2GNMVwvpTMQ1VjuZU8bs8I5M4mV U8okP5Q8r9Pn6IYuWozsN7pp6zPZIOA4qD92nFQVduHJoWcd3S MeWJhGGguVyo9ImrhhBRY+XG6QN0G9BIg3auceMBDBOHCDxrLO 5cKv/hFQqVLOEJjyeJejA== Cc: Markus Lanthaler , "json@ietf.org" Subject: Re: [Json] The names within an object SHOULD be unique. X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stefan@drees.name List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2013 14:07:21 -0000 On 2013-06-07 15:38, "Vinny A" wrote: > > On Jun 7, 2013, at 5:22 AM, Stefan Drees ... wrote: >> Which b.t.w. I would certainly rewrite as: >> >> NEW >> """ >> Generators SHOULD NOT duplicate names in objects. Parsers MUST be >> prepared to either accept duplicate names in objects or reject the >> complete JSON text containing these, as a generator might not avoid nor >> detect such duplication. >> """ > > For the sake of readability, can you split this proposed text into > separate prescriptions for parsers and emitters? I.e. section 4 of the > RFC is for parsers, section 5 is for generators, put their respective > advice into the appropriate sections. > sure thing. Here comes my proposed rewrite of sections 4 and 5 based on the above, but possibly ignoring ideas in other messages already sent to this list (the subject of a mail thread MAY relate to the message body content ;-) OLD: """ 4. Parsers A JSON parser transforms a JSON text into another representation. A JSON parser MUST accept all texts that conform to the JSON grammar. A JSON parser MAY accept non-JSON forms or extensions. An implementation may set limits on the size of texts that it accepts. An implementation may set limits on the maximum depth of nesting. An implementation may set limits on the range of numbers. An implementation may set limits on the length and character contents of strings. 5. Generators A JSON generator produces JSON text. The resulting text MUST strictly conform to the JSON grammar. """ NEW: """ 4. Parsers A JSON parser transforms JSON text into another representation, MUST accept all texts that conform to the JSON grammar and MUST be prepared to either accept duplicate names in objects or reject the complete JSON text containing these. A JSON parser MAY accept non-JSON forms or extensions. An implementation may set limits on any of the following: the size of texts that it accepts, the maximum depth of nesting, the range of numbers, and the length and character contents of strings. 5. Generators A JSON generator produces JSON text. The resulting text MUST strictly conform to the JSON grammar. Generators SHOULD NOT duplicate names in objects if they can avoid or detect such duplication. """ What do you think? All the best, Stefan. From mamille2@cisco.com Fri Jun 7 07:10:40 2013 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 E14C921F888F for ; Fri, 7 Jun 2013 07:10:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uaKyYARo7kuF for ; Fri, 7 Jun 2013 07:10:36 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id DA14521F969F for ; Fri, 7 Jun 2013 07:10:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8314; q=dns/txt; s=iport; t=1370614236; x=1371823836; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=IPUBXiuQBPNBZ94tRcCY3Av5QDhWIYoCyx1kaBkhSz4=; b=jGCAlUYPVOAlGJ3kKitTwjacj/gPNxR1OWjTh9KJMV7aTWnFSZp25AuF xcmxDXivIhQUaISLX2/sPnkhKWeKmiKavLsSdOzkjeNg+oSmi10/Y8n1f KwZ76G7KhYPLHLmH2yYPbPe8YRSo9Aq7WdUsh0tUOZSMTt9LrAZggnrpt w=; X-Files: smime.p7s : 4136 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhgFAJfpsVGtJXHB/2dsb2JhbABZgwkwuweDaX0WdIIjAQEBAwEBAQFrCwULAgEIGAokAiULJQIEAQ0FCAaHeQYMvFAEjwcWGweCe2EDkAGBLJdVgw+CJw X-IronPort-AV: E=Sophos;i="4.87,822,1363132800"; d="p7s'?scan'208";a="219848746" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-1.cisco.com with ESMTP; 07 Jun 2013 14:10:29 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r57EAScn014624 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 7 Jun 2013 14:10:28 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.24]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.02.0318.004; Fri, 7 Jun 2013 09:10:28 -0500 From: "Matt Miller (mamille2)" To: "stefan@drees.name" , "Manger, James H" , Carsten Bormann , "Joe Hildebrand (jhildebr)" Thread-Topic: [Json] ABNF nits Thread-Index: AQHOYxhuLNPlu69CpUeh/eSpf1GKTZkpg97A///1nACAABksoIAAjFoAgACAJYA= Date: Fri, 7 Jun 2013 14:10:27 +0000 Message-ID: References: <255B9BB34FB7D647A506DC292726F6E1151B21F79E@WSMSG3153V.srv.dir.telstra.com> <255B9BB34FB7D647A506DC292726F6E1151B21F8CA@WSMSG3153V.srv.dir.telstra.com> <51B17E54.9030107@drees.name> In-Reply-To: <51B17E54.9030107@drees.name> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.129.24.59] Content-Type: multipart/signed; boundary="Apple-Mail=_0A8A7FE2-6045-4D4D-BDCF-731ADA2F9457"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Cc: "json@ietf.org" Subject: Re: [Json] ABNF nits X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 07 Jun 2013 14:10:41 -0000 --Apple-Mail=_0A8A7FE2-6045-4D4D-BDCF-731ADA2F9457 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Would one of you be so kind as to put all of this into a proposal we can = all get our heads wrapped around? kthxbye, - m&m Matt Miller < mamille2@cisco.com > Cisco Systems, Inc. On Jun 7, 2013, at 12:31 AM, Stefan Drees wrote: > On 2013-06-07 05:15, James H. Manger wrote: >>>>> Some things I found futzing with the ABNF: >>>>>=20 >>>>> - normalize the indentation (makes it easier to pull out) >>>>> - Hex literals need to be uppercase. The false and null rules are >>>>> wrong. >>>>=20 >>>> Lowercase is allowed in hex literals. >>>> It links back to HEXDIG in RFC5234 (or RFC 4234). >>>> You have to remember the sneaky ABNF rule that quoted strings (eg = "A") >>>> are case insensitive. "A" is equivalent to %x41 / %x61. >>>=20 >>> Crap. I didn't see that because it's in a "Note:" in section 2.3. >>=20 >> I didn't call it "sneaky" for nothing ;) ... >=20 > lucky JSON, it only needs short tokens (cowardly avoiding the word = single character here ;-) >=20 > If defining a grammar with real case-sensitive "word"-ish tokens in = it, ABNF is IMO barely usable, unless you extend it with say single = quotes as case-sensitve string delimiters. But then dealing with two = kinds of strings also has it's catches =3D( >=20 >=20 >>> Regardless, we should change both of those rules for consistency = with >>> the rest of the doc. >>>=20 >>>>> - DIGIT and HEXDIG are neither defined nor imported, as far as I = can >>>>> tell. >>>>> I suggest: >>>>>=20 >>>>> DIGIT =3D %x30-39 ; 0-9 >>>>> HEXDIG =3D %x30-39 / %x41-46 / %x61-66 ; 0-9, A-F, or a-f >>>=20 >>> I still recommend being explicit about this, like the rule for e. >>=20 >> I agree. >> Add DIGIT and HEXDIG to the doc so all the ABNF is present. >> Use your definition of HEXDIG above, not the RFC5234 one, to avoid = the sneaky ABNF rule. >> Optionally add a note "; DIGIT and HEXDIG are equivalent to rules = with the same names in [RFC5234]". >=20 > +1 on your proposal James (including the ABNF comment). >=20 > Stefan. >=20 > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json --Apple-Mail=_0A8A7FE2-6045-4D4D-BDCF-731ADA2F9457 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMezCCBjQw ggQcoAMCAQICAR4wDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDE1NVoX DTE3MTAyNDIxMDE1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMcJg8zOLdgasSmkLhOrlr6KMoOMpohBllVHrdRvEg/q6r8jR+EK 75xCGhR8ToREoqe7zM9/UnC6TS2y9UKTpT1v7RSMzR0t6ndl0TWBuUr/UXBhPk+Kmy7bI4yW4urC +y7P3/1/X7U8ocb8VpH/Clt+4iq7nirMcNh6qJR+xjOhV+VHzQMALuGYn5KZmc1NbJQYclsGkDxD z2UbFqE2+6vIZoL+jb9x4Pa5gNf1TwSDkOkikZB1xtB4ZqtXThaABSONdfmv/Z1pua3FYxnCFmdr /+N2JLKutIxMYqQOJebr/f/h5t95m4JgrM3Y/w7YX9d7YAL9jvN4SydHsU6n65cCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRTcu2SnODaywFc fH6WNU7y1LhRgjAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBAAqDCH14qywG XLhjjF6uHLkjd02hcdh9hrw+VUsv+q1eeQWB21jWj3kJ96AUlPCoEGZ/ynJNScWy6QMVQjbbMXlt UfO4n4bGGdKo3awPWp61tjAFgraLJgDk+DsSvUD6EowjMTNx25GQgyYJ5RPIzKKR9tQW8gGK+2+R HxkUCTbYFnL6kl8Ch507rUdPPipJ9CgJFws3kDS3gOS5WFMxcjO5DwKfKSETEPrHh7p5shuuNktv sv6hxHTLhiMKX893gxdT3XLS9OKmCv87vkINQcNEcIIoFWbP9HORz9v3vQwR4e3ksLc2JZOAFK+s sS5XMEoznzpihEP0PLc4dCBYjbvSD7kxgDwZ+Aj8Q9PkbvE9sIPP7ON0fz095HdThKjiVJe6vofq +n6b1NBc8XdrQvBmunwxD5nvtTW4vtN6VY7mUCmxsCieuoBJ9OlqmsVWQvifIYf40dJPZkk9YgGT zWLpXDSfLSplbY2LL9C9U0ptvjcDjefLTvqSFc7tw1sEhF0n/qpA2r0GpvkLRDmcSwVyPvmjFBGq Up/pNy8ZuPGQmHwFi2/14+xeSUDG2bwnsYJQG2EdJCB6luQ57GEnTA/yKZSTKI8dDQa8Sd3zfXb1 9mOgSF0bBdXbuKhEpuP9wirslFe6fQ1t5j5R0xi72MZ8ikMu1RQZKCyDbMwazlHiMIIGPzCCBSeg AwIBAgIDBoRIMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcN MTMwNDMwMjE1NDQyWhcNMTQwNTAyMDUzOTA0WjBbMRkwFwYDVQQNExBiN2F6NndOY0t0R3JtMEpF MRswGQYDVQQDDBJtYW1pbGxlMkBjaXNjby5jb20xITAfBgkqhkiG9w0BCQEWEm1hbWlsbGUyQGNp c2NvLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJbKBMsG+9UFTx9uq/bhhXgu vJvO8z7cwKaqqwZhVf5z/kHFyCNijtmTOE+YXjA8mWR4aoBwB5SvGypI/cJUofJ+AlBTC4g+RMx/ K0Ab4/jQqTQz9CDzMOB+Wm+rt8ZJ7A8ZzOJmNDAsf/VvB8l2A1SQz1UsAixgH16NTr8SlblAXEKk 4hwpCudUiNjjQokqJ0H686UBKVorcZSgXaza8XMqGtJF/8mNhR9GQYi7Xht1ky+9LFOrto2daZto KJRwMeVusVdHUeKEQSu7jztw8HchH3KEb7Q+r5X+hhDZoddfKE8d5eyPuhiZdrzv7OlNZ0fSLdx7 3AE3nx9/R5YlXucCAwEAAaOCAtgwggLUMAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQW MBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQUxGd+/qrdVudHrIKkw5xOMY7eaLUwHwYD VR0jBBgwFoAUU3Ltkpzg2ssBXHx+ljVO8tS4UYIwHQYDVR0RBBYwFIESbWFtaWxsZTJAY2lzY28u Y29tMIIBTAYDVR0gBIIBQzCCAT8wggE7BgsrBgEEAYG1NwECAzCCASowLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0 Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBp c3N1ZWQgYWNjb3JkaW5nIHRvIHRoZSBDbGFzcyAxIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9m IHRoZSBTdGFydENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBw dXJwb3NlIGluIGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMDYG A1UdHwQvMC0wK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUxLWNybC5jcmwwgY4G CCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIv Y2xhc3MxL2NsaWVudC9jYTBCBggrBgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2Vy dHMvc3ViLmNsYXNzMS5jbGllbnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRz c2wuY29tLzANBgkqhkiG9w0BAQUFAAOCAQEAlDhXbGEI7lbqUcu5r2JHZaMsbRZda/99ZqODzWGX 0llou9jGccsAWDPPwRRe2+ROpXfH4cuJZElTcLDeZSp/qpXKhjYieFSX8+Ml9sKEj5UOSqQLyoLk PtrIJV12Jk3nuG2Jc0UeEnGwK/aqtzy7+bfEVI0ziyVM2gChHh0RH74KyiwYWknbOTRIkZcz/ulE DVFQp63uj6wfmDNvAUHBAdhKVqA1S/rfP1KcDZpf1NfvwXJibiqTRA6K1EOxTJOP41n/XdvHqHXL RWL2xrOUI9/URANr/ok3OrsuZEMFnAAGefS1bWS/hFtUGVkHGiKEBbyDW7da2ULXbuC7umrQnzGC A28wggNrAgEBMIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkG A1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwaESDAJBgUrDgMCGgUA oIIBrzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMzA2MDcxNDEw MjhaMCMGCSqGSIb3DQEJBDEWBBRm35T4g3uDod6fHC+ahJmthiTyeDCBpQYJKwYBBAGCNxAEMYGX MIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3Mg MSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwaESDCBpwYLKoZIhvcNAQkQAgsxgZeg gZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1 cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAx IFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDBoRIMA0GCSqGSIb3DQEBAQUABIIBAD8l 1LElHpniMUzK2shxrNaP+sTJXJdP+RMUYGOkDwhiqRK4jeYm5cQze/8OOOWDVc06Lj1NJueiZTzf wSKmrM2utekdoqMUnuQPSgyXHNNaLyJjHcth/iTFomXKbStm+cdWj/d05t7JGSThzhrh4JZdukiF Ui0IVsYxmDRiRntXgVag7AOUpB0WxQEAPT/wwa8DIL+X8sFePKePYBgUYVZFGxy8AkftAcFjxWMJ dI5N6A/CrF2gUv08UagHM2UWEuVs9wJhfJ6A6johq7yYwvBFmwI8gdVAdFRQfWne6zco6K79F/nr yoWkIye1y1WlfC0ehy9JZEUeflxvgQlb9XwAAAAAAAA= --Apple-Mail=_0A8A7FE2-6045-4D4D-BDCF-731ADA2F9457-- From stefan@drees.name Fri Jun 7 07:28:46 2013 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 0B85821F9473 for ; Fri, 7 Jun 2013 07:28:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.904 X-Spam-Level: X-Spam-Status: No, score=-1.904 tagged_above=-999 required=5 tests=[AWL=-0.255, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_14=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EzuCmYEGNLam for ; Fri, 7 Jun 2013 07:28:38 -0700 (PDT) Received: from mout.web.de (mout.web.de [212.227.17.12]) by ietfa.amsl.com (Postfix) with ESMTP id 5D8DA21F9619 for ; Fri, 7 Jun 2013 07:28:33 -0700 (PDT) Received: from newyork.local.box ([93.129.186.5]) by smtp.web.de (mrweb003) with ESMTPSA (Nemesis) id 0MJkvs-1Um3a30gM8-001dDK; Fri, 07 Jun 2013 16:28:20 +0200 Message-ID: <51B1EE02.4090804@drees.name> Date: Fri, 07 Jun 2013 16:28:18 +0200 From: Stefan Drees User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "Matt Miller (mamille2)" References: <255B9BB34FB7D647A506DC292726F6E1151B21F79E@WSMSG3153V.srv.dir.telstra.com> <255B9BB34FB7D647A506DC292726F6E1151B21F8CA@WSMSG3153V.srv.dir.telstra.com> <51B17E54.9030107@drees.name> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V02:K0:ClAmMER5UjD0v+nnARIaRbFSKdWnn1n47wi47H4nVy8 YBg+gRKjSxtvqT6PVePQPQ6fuO0ovAu7zMmaf2aHlA0dmcYl0G hFDpbSpNBn6r6t72DLR+M5LzVHPH/803sFtUlk4peWF/T0a+Ba awokLavRY9wHdv2Yi1ce3fd80qTXlTIg8BHkYbvzhm0HS4KSzW yMoOMtALhI9RYPV5vp83A== Cc: Carsten Bormann , "Manger, James H" , "Joe Hildebrand \(jhildebr\)" , "json@ietf.org" Subject: Re: [Json] ABNF nits X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stefan@drees.name List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2013 14:28:46 -0000 On 07.06.13 16:10, Matt Miller (mamille2) wrote: > Would one of you be so kind as to put all of this into a proposal we can > all get our heads wrapped around? I will try for an estimated consensual definition of all and this ;-) Proposal: Replace the closing ABNF rules inside section 2.4. Numbers OLD: """ number = [ minus ] int [ frac ] [ exp ] decimal-point = %x2E ; . digit1-9 = %x31-39 ; 1-9 e = %x65 / %x45 ; e E exp = e [ minus / plus ] 1*DIGIT frac = decimal-point 1*DIGIT int = zero / ( digit1-9 *DIGIT ) minus = %x2D ; - plus = %x2B ; + zero = %x30 ; 0 """ with NEW: """ number = [ minus ] int [ frac ] [ exp ] decimal-point = %x2E ; . digit1-9 = %x31-39 ; 1-9 e = %x65 / %x45 ; e E exp = e [ minus / plus ] 1*DIGIT frac = decimal-point 1*DIGIT int = zero / ( digit1-9 *DIGIT ) DIGIT = %x30-39 ; 0-9 ; DIGIT equivalent to DIGIT rule in [RFC5234] minus = %x2D ; - plus = %x2B ; + zero = %x30 ; 0 """ and in section 2.5 Strings (as there is a 4HEXDIG, and no HEXDIG declared) also the ABNF rules section replace: OLD: """ string = quotation-mark *char quotation-mark char = unescaped / escape ( %x22 / ; " quotation mark U+0022 %x5C / ; \ reverse solidus U+005C %x2F / ; / solidus U+002F %x62 / ; b backspace U+0008 %x66 / ; f form feed U+000C %x6E / ; n line feed U+000A %x72 / ; r carriage return U+000D %x74 / ; t tab U+0009 %x75 4HEXDIG ) ; uXXXX U+XXXX escape = %x5C ; \ quotation-mark = %x22 ; " unescaped = %x20-21 / %x23-5B / %x5D-10FFFF """ with: NEW: """ string = quotation-mark *char quotation-mark char = unescaped / escape ( %x22 / ; " quotation mark U+0022 %x5C / ; \ reverse solidus U+005C %x2F / ; / solidus U+002F %x62 / ; b backspace U+0008 %x66 / ; f form feed U+000C %x6E / ; n line feed U+000A %x72 / ; r carriage return U+000D %x74 / ; t tab U+0009 %x75 4HEXDIG ) ; uXXXX U+XXXX escape = %x5C ; \ quotation-mark = %x22 ; " unescaped = %x20-21 / %x23-5B / %x5D-10FFFF HEXDIG = DIGIT / %x41-46 / %x61-66 ; 0-9, A-F, or a-f ; HEXDIG equivalent to HEXDIG rule in [RFC5234] """ Did it catch everything? Or do we want to explain, that 4HEXDIG means exactly 4 hex digits? I guess no, as the comment is depicting this nice and it is common ABNF practice to deal with multiplicity. All the best and second to top posting as this is a summarizing job ;-) Stefan > > > kthxbye, > > - m&m > > Matt Miller < mamille2@cisco.com > > Cisco Systems, Inc. > > On Jun 7, 2013, at 12:31 AM, Stefan Drees wrote: > >> On 2013-06-07 05:15, James H. Manger wrote: >>>>>> Some things I found futzing with the ABNF: >>>>>> >>>>>> - normalize the indentation (makes it easier to pull out) >>>>>> - Hex literals need to be uppercase. The false and null rules are >>>>>> wrong. >>>>> >>>>> Lowercase is allowed in hex literals. >>>>> It links back to HEXDIG in RFC5234 (or RFC 4234). >>>>> You have to remember the sneaky ABNF rule that quoted strings (eg "A") >>>>> are case insensitive. "A" is equivalent to %x41 / %x61. >>>> >>>> Crap. I didn't see that because it's in a "Note:" in section 2.3. >>> >>> I didn't call it "sneaky" for nothing ;) ... >> >> lucky JSON, it only needs short tokens (cowardly avoiding the word single character here ;-) >> >> If defining a grammar with real case-sensitive "word"-ish tokens in it, ABNF is IMO barely usable, unless you extend it with say single quotes as case-sensitve string delimiters. But then dealing with two kinds of strings also has it's catches =( >> >> >>>> Regardless, we should change both of those rules for consistency with >>>> the rest of the doc. >>>> >>>>>> - DIGIT and HEXDIG are neither defined nor imported, as far as I can >>>>>> tell. >>>>>> I suggest: >>>>>> >>>>>> DIGIT = %x30-39 ; 0-9 >>>>>> HEXDIG = %x30-39 / %x41-46 / %x61-66 ; 0-9, A-F, or a-f >>>> >>>> I still recommend being explicit about this, like the rule for e. >>> >>> I agree. >>> Add DIGIT and HEXDIG to the doc so all the ABNF is present. >>> Use your definition of HEXDIG above, not the RFC5234 one, to avoid the sneaky ABNF rule. >>> Optionally add a note "; DIGIT and HEXDIG are equivalent to rules with the same names in [RFC5234]". >> >> +1 on your proposal James (including the ABNF comment). >> >> Stefan. >> >> _______________________________________________ >> json mailing list >> json@ietf.org >> https://www.ietf.org/mailman/listinfo/json > From jsontest@yahoo.com Fri Jun 7 08:19:22 2013 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 A2E7E21F92B8 for ; Fri, 7 Jun 2013 08:19:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.461 X-Spam-Level: X-Spam-Status: No, score=-0.461 tagged_above=-999 required=5 tests=[AWL=0.743, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qIwbEevQRKXf for ; Fri, 7 Jun 2013 08:19:17 -0700 (PDT) Received: from nm37.bullet.mail.gq1.yahoo.com (nm37.bullet.mail.gq1.yahoo.com [98.136.217.20]) by ietfa.amsl.com (Postfix) with ESMTP id EDCF721F9050 for ; Fri, 7 Jun 2013 08:19:16 -0700 (PDT) Received: from [98.137.12.62] by nm37.bullet.mail.gq1.yahoo.com with NNFMP; 07 Jun 2013 15:19:16 -0000 Received: from [98.136.185.40] by tm7.bullet.mail.gq1.yahoo.com with NNFMP; 07 Jun 2013 15:19:16 -0000 Received: from [127.0.0.1] by smtp101.mail.gq1.yahoo.com with NNFMP; 07 Jun 2013 15:19:16 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1370618356; bh=aoYT/iMt/aQdY/n//4Kz7Fb/HT0iQU7fLvDxsVrV2Lk=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:References:In-Reply-To:Mime-Version:Content-Type:Content-Transfer-Encoding:Message-Id:Cc:X-Mailer:From:Subject:Date:To; b=uAeEmvl76KuQbyMzseXgzg/vyBs6tA8n8L/ZGyb2cm8X3+Ls0lNgXM+EgEC/j9EHMfX4NOPOafxQ8v4gJ0Exhm6y/2byQLzV3eLRL/4wQTKMugyKhXnXvETmiv44LosAUiaJmM8lHwkVK2ci7nym0Na97ZG0dqlb0ouiE7nQcAw= X-Yahoo-Newman-Id: 355916.31492.bm@smtp101.mail.gq1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: JNAhERoVM1kl54RrGEmwgK4Nr9wber2KHQVaa9pe1PKh2Ta JLTKeZbw4GjMThFzo2.D5ZA1f6Jz7zcZhd52fjarVnb6tn4DoynClmUcazrA t2vOPkntwrNYj_8vOD0uBzD8x4L5r7Rp7z214WEa7alvS5eVF5ssI9EG3aBk oLy6xZVNg_HA_pm30zaYGsLH602dNNLvUEF3drR4qpcDB2GlXlh6SVI4NDey gW9aQlPApeGjRaeMu.McrTBl9JiXhCwpbmKjGHILY5IDL1YuphlLKskHuuMJ Sr2rRqTnV6UQTbD5B3vd5fkD6ekiDMpU_KuyXwjssyRBavHF2AZrmxWKq1os ap6_4HHJm6ae7PykwJD4.URtHJcMyxNuLlegHFlXhWzYOmpa_8WHh_ys8_vu ZX4TAUQ0Fyy2dph6zfTpxsBfbgO8BYkF3_x9PI9lDL5AxPbowWYwUvzUrdSc ntN_LwICT.aztP_WrAUapsGSDvMQQUVJtNxMlrZeJJyqxWl2M.Ag.6WovQ_I ySfYxDginY.km2SU6ZJOh4V4sSQ-- X-Yahoo-SMTP: indQcmSswBC8IKsm6t4aCAPskK3T X-Rocket-Received: from [192.168.10.95] (jsontest@64.134.39.87 with ) by smtp101.mail.gq1.yahoo.com with SMTP; 07 Jun 2013 08:19:16 -0700 PDT References: <51AF8479.5080002@crockford.com> <51b1168c.e686440a.5339.5fc4SMTPIN_ADDED_BROKEN@mx.google.com> <009801ce635e$0bef7080$23ce5180$@lanthaler@gmx.net> <51B1B47C.9060009@drees.name> <51B1E909.2010402@drees.name> In-Reply-To: <51B1E909.2010402@drees.name> Mime-Version: 1.0 (1.0) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPod Mail (9B206) From: Vinny A Date: Fri, 7 Jun 2013 10:19:13 -0500 To: "stefan@drees.name" Cc: Markus Lanthaler , "json@ietf.org" Subject: Re: [Json] The names within an object SHOULD be unique. X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 07 Jun 2013 15:19:22 -0000 On Jun 7, 2013, at 9:07 AM, Stefan Drees wrote: >=20 > NEW: > """ > 4. Parsers >=20 > A JSON parser transforms JSON text into another representation, > MUST accept all texts that conform to the JSON grammar and MUST be > prepared to either accept duplicate names in objects or reject the > complete JSON text containing these. > A JSON parser MAY accept non-JSON forms or extensions. >=20 > An implementation may set limits on any of the following: the size > of texts that it accepts, the maximum depth of nesting, the range of > numbers, and the length and character contents of strings. >=20 > 5. Generators >=20 > A JSON generator produces JSON text. The resulting text MUST > strictly conform to the JSON grammar. >=20 > Generators SHOULD NOT duplicate names in objects if they can avoid > or detect such duplication. >=20 > """ +1, with the understanding that some parsers (in particular streaming parser= s) will not be able to reject the "complete JSON text" because they've alrea= dy sent earlier parts of the JSON text for processing by other app component= s. But that's a bit nitpicky, so feel free to keep the current text as-is. ----------------- Vinny www.jsontest.com From stedolan@stedolan.net Fri Jun 7 08:19:32 2013 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 77FA521F91BC for ; Fri, 7 Jun 2013 08:19:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.426 X-Spam-Level: X-Spam-Status: No, score=-0.426 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R+zlv+NVNNCR for ; Fri, 7 Jun 2013 08:19:27 -0700 (PDT) Received: from mail-la0-x229.google.com (mail-la0-x229.google.com [IPv6:2a00:1450:4010:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id 20EB321F955A for ; Fri, 7 Jun 2013 08:19:26 -0700 (PDT) Received: by mail-la0-f41.google.com with SMTP id fn20so3858892lab.28 for ; Fri, 07 Jun 2013 08:19:25 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:x-originating-ip:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :x-gm-message-state; bh=9SIDazaLbKKREf//eF6MzCRyahzNrzaYo16rw6mOpOo=; b=gYHooREdD8XVkUi7YMcN+e5cCqpZjnRPKoKrQmmqF5pC5uv9vg39LNGmInoqmJu7xm Dj4p+nJGoeL/t37mebdDCQMlpjn/f1fQ8OyhmWRn33twQ1F2bNrXZ7b7w4De4UzCtglh /qpIJ0jpc117tYbUtJvsuH5coHAb32KmCroQto/3fH8UemAM9pPlwgfTkOHWWJ47LnaR Xz7cULfQCAEn2YIJkoNofFD21HHOugqT6RWGD/jf1y1nCMoWcmdT7sG8ItttkjD1ud/p +ywPkwBo3ONDOvYIG50kM5DOwgFyaSQusn41XbV5GJa4LyKkFYtt1AUxvXa3ym6NUVk3 AQfQ== MIME-Version: 1.0 X-Received: by 10.152.42.171 with SMTP id p11mr2751015lal.79.1370618365443; Fri, 07 Jun 2013 08:19:25 -0700 (PDT) Sender: stedolan@stedolan.net Received: by 10.114.186.41 with HTTP; Fri, 7 Jun 2013 08:19:25 -0700 (PDT) X-Originating-IP: [128.232.9.157] In-Reply-To: <51B1E909.2010402@drees.name> References: <51AF8479.5080002@crockford.com> <51b1168c.e686440a.5339.5fc4SMTPIN_ADDED_BROKEN@mx.google.com> <51B1B47C.9060009@drees.name> <51B1E909.2010402@drees.name> Date: Fri, 7 Jun 2013 16:19:25 +0100 X-Google-Sender-Auth: cDk_an-QriKte0K8sxdERiGTev0 Message-ID: From: Stephen Dolan To: stefan@drees.name Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQlmyo8bC2+cgLjdLdebGfO5gSDeLi62EGBsG1u0D6UybyEutcUvk1uANOIgtGfC2gvfNiyt Cc: Vinny A , Markus Lanthaler , "json@ietf.org" Subject: Re: [Json] The names within an object SHOULD be unique. X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 07 Jun 2013 15:21:07 -0000 On Jun 7, 2013, at 5:22 AM, Stefan Drees ... wrote: > > Which b.t.w. I would certainly rewrite as: > > NEW > """ > Generators SHOULD NOT duplicate names in objects. Parsers MUST be > prepared to either accept duplicate names in objects or reject the > complete JSON text containing these, as a generator might not avoid nor > detect such duplication. > """ Regarding duplicate keys, the issue was raised before that having multiple valid interpretations of an input leads to security problems. Consider this document: {"command": "no-op", "user": "untrustworthy-person", "command": "launch-missiles"} if submitted to a system which separates authorization from execution, where both use JSON implementations which differ in their interpretation of duplicate keys, this could end badly. There are some JSON implementations which preserve duplicate keys, and many which don't. However, I know of no implementation which interprets {"a":2, "a":1} as {"a":2} - the implementations I've seen keep either all or just the last entry. Codifying this behaviour in the RFC would help to prevent the security issue described above, so how about some text along the lines of: If an object contains several key-value entries with the same key, a JSON parser MAY ignore all but the last of these entries. A JSON parser MUST NOT ignore the last such entry. Stephen Dolan From stefan@drees.name Fri Jun 7 08:38:41 2013 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 3834821F9703 for ; Fri, 7 Jun 2013 08:38:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.181 X-Spam-Level: X-Spam-Status: No, score=-2.181 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0kAIMzw+0lUo for ; Fri, 7 Jun 2013 08:38:24 -0700 (PDT) Received: from mout.web.de (mout.web.de [212.227.17.12]) by ietfa.amsl.com (Postfix) with ESMTP id DBE0321F9642 for ; Fri, 7 Jun 2013 08:38:23 -0700 (PDT) Received: from newyork.local.box ([93.129.186.5]) by smtp.web.de (mrweb102) with ESMTPSA (Nemesis) id 0Ljrq1-1UDYrj2zAv-00bvLV; Fri, 07 Jun 2013 17:38:19 +0200 Message-ID: <51B1FE6A.80409@drees.name> Date: Fri, 07 Jun 2013 17:38:18 +0200 From: Stefan Drees User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Stephen Dolan References: <51AF8479.5080002@crockford.com> <51b1168c.e686440a.5339.5fc4SMTPIN_ADDED_BROKEN@mx.google.com> <51B1B47C.9060009@drees.name> <51B1E909.2010402@drees.name> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V02:K0:Dyxx+MMQXxtpk5M+m4g/jnFF7ribP0cFrgqMD8IqjkB gxInJBGDAEa3IvAWDvpTXCR0bEvBPLGd/weTuWWB+7BkAPO3zy 3N5+qBOmdTJFsZHYmW22ZvKBd4yc6SoOWnvogjdUq8armXwAp1 gYWI6y/X1bsFe5TlJnixyO9vfZInP6rjKdg99WL+ZtnJ7exPn1 wzxYtWGKOF0eX5aI/6ITw== Cc: Vinny A , Markus Lanthaler , "json@ietf.org" Subject: Re: [Json] The names within an object SHOULD be unique. X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stefan@drees.name List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2013 15:38:41 -0000 On 2013-06-07 17:19, Stephen Dolan wrote: > On Jun 7, 2013, at 5:22 AM, Stefan Drees ... wrote: >> >> Which b.t.w. I would certainly rewrite as: >> >> NEW >> """ >> Generators SHOULD NOT duplicate names in objects. Parsers MUST be >> prepared to either accept duplicate names in objects or reject the >> complete JSON text containing these, as a generator might not avoid nor >> detect such duplication. >> """ Please note: The above proposal has already been split and updated upon request of "Vinny A" as the spec separates Parser and Generator sections. > Regarding duplicate keys, the issue was raised before that having > multiple valid interpretations of an input leads to security problems. > Consider this document: > > {"command": "no-op", "user": "untrustworthy-person", "command": > "launch-missiles"} > > if submitted to a system which separates authorization from execution, > where both use JSON implementations which differ in their > interpretation of duplicate keys, this could end badly. > > There are some JSON implementations which preserve duplicate keys, and > many which don't. However, I know of no implementation which > interprets {"a":2, "a":1} as {"a":2} - the implementations I've seen > keep either all or just the last entry. Codifying this behaviour in > the RFC would help to prevent the security issue described above, so > how about some text along the lines of: > > If an object contains several key-value entries with the same key, > a JSON parser MAY ignore all but the last of these entries. A JSON > parser MUST NOT ignore the last such entry. ... I do think, that forcing the consumer to "keep" the last parsed (whatever this means from the perspective of the source of the message) name as "the one" is **not** "good", nor "more secure" nor "doesn't break anything in the wild". A "source of the message" shall indicate, that this is not a format concern, but one of the sender and receivers rules. Say e.g. a program running on node A has a list of names and these have values attached. The names are not unique (thus a list ;-) if this program decides to send this information through a JSON data interchange, when selecting the JSON type object, it does so knowingly, that the order of members in a JSON object is undefined, so there is IMO no principal security dilemma in ordering, but in ambiguity of a message that would have better been build with a unique set of names from the start. As has been noted in many differnt mails already here on this list, we have no time-machine and somehow have to deal with that :-) All the best, Stefan. From paul.hoffman@vpnc.org Fri Jun 7 08:40:15 2013 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 A5D8B21F9711 for ; Fri, 7 Jun 2013 08:40:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.334 X-Spam-Level: X-Spam-Status: No, score=-102.334 tagged_above=-999 required=5 tests=[AWL=0.265, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ndtz11t+8zMZ for ; Fri, 7 Jun 2013 08:40:15 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 231BF21F9704 for ; Fri, 7 Jun 2013 08:40:10 -0700 (PDT) Received: from [10.20.30.90] (50-0-66-165.dsl.dynamic.sonic.net [50.0.66.165]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r57Fe9av081461 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 7 Jun 2013 08:40:09 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Paul Hoffman In-Reply-To: <255B9BB34FB7D647A506DC292726F6E1151B21F9A9@WSMSG3153V.srv.dir.telstra.com> Date: Fri, 7 Jun 2013 08:40:08 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <3B4E7F65-B9B9-4C95-B077-D178B8DD8216@vpnc.org> References: <255B9BB34FB7D647A506DC292726F6E1151B21F9A9@WSMSG3153V.srv.dir.telstra.com> To: "json@ietf.org" X-Mailer: Apple Mail (2.1508) Subject: Re: [Json] Allow any JSON value at the top level X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 07 Jun 2013 15:40:15 -0000 On Jun 6, 2013, at 8:51 PM, "Manger, James H" = wrote: > The current spec only allows a JSON text to be an object or array. = Section 2. "JSON Grammar" says: >=20 > A JSON text is a serialized object or array. >=20 > JSON-text =3D object / array >=20 >=20 > I propose allowing a JSON text to be any JSON value. >=20 > A JSON text is a serialization of any JSON value. >=20 > JSON-text =3D value >=20 > value =3D false / null / true / object / array / number / string +1 to this, and to removing the "how to tell if you are looking at a = JSON text" from the parser section. That rule is fragile and not useful. I am interested to hear examples of where this change would cause = breakage, particularly given that ECMAScript already has this rule. --Paul Hoffman= From paul.hoffman@vpnc.org Fri Jun 7 08:46:06 2013 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 EAB8021F9346 for ; Fri, 7 Jun 2013 08:46:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.345 X-Spam-Level: X-Spam-Status: No, score=-102.345 tagged_above=-999 required=5 tests=[AWL=0.254, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lFnrO4es6-ut for ; Fri, 7 Jun 2013 08:46:06 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 6CCDF21F9302 for ; Fri, 7 Jun 2013 08:46:06 -0700 (PDT) Received: from [10.20.30.90] (50-0-66-165.dsl.dynamic.sonic.net [50.0.66.165]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r57Fk3Bn081705 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 7 Jun 2013 08:46:03 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Paul Hoffman In-Reply-To: Date: Fri, 7 Jun 2013 08:46:02 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <296843F3-7933-4DF3-9FAF-841CDFD697BB@vpnc.org> References: <51AF8479.5080002@crockford.com> <51b1168c.e686440a.5339.5fc4SMTPIN_ADDED_BROKEN@mx.google.com> To: R S X-Mailer: Apple Mail (2.1508) Cc: json@ietf.org Subject: Re: [Json] The names within an object SHOULD be unique. X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 07 Jun 2013 15:46:07 -0000 On Jun 6, 2013, at 7:59 PM, R S wrote: > JSON is sometimes produced by naive string concatenation, which will = probably never change. It is consumed by browsers, which will probably = never change their duplicate key handling. >=20 > The text from RFC 4627 should stay unchanged. The suggestions for = requirements on encoders are prescriptive and therefore inaccurate at = this stage in JSON's adoption. Your first paragraph does not match your second. Many of the proposals = here keep the gist of RFC 4267 for encoders, "The names within an object = SHOULD be unique.". For parsers in browsers, so far all the examples we = have seen have followed the proposed wording of "MUST choose the last = one". --Paul Hoffman= From mamille2@cisco.com Fri Jun 7 08:46:48 2013 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 DA83E21F9346 for ; Fri, 7 Jun 2013 08:46:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4v59CM04w20e for ; Fri, 7 Jun 2013 08:46:44 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 3833C21F9485 for ; Fri, 7 Jun 2013 08:46:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8921; q=dns/txt; s=iport; t=1370620001; x=1371829601; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=A65Zox7mof/og9WOv61zzSDAx3lIGwZPpRnj49MwFHs=; b=QjwPvPHYWk7AzerEtFDQWhwDZn2QJL1TY0hAdGxFZz8Cc/zCGrHuQKHz 5mqsq9DDXbcbTtqfSDcRt4A+MMP1fzlCwHirVp/lJ7Vf5kxDOFGHTZK/x EgD29rWQbDrZJck8FcXb9FKOaf3KUSA1JUklLrTF/k0bTtEhesJ9+rxha 8=; X-Files: smime.p7s : 4136 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhIFANj/sVGtJXG+/2dsb2JhbABZgwkwvnB/FnSCIwEBAQMBAQEBawsFCwIBCBgKJAIlCyUCBA4FCAaHeQYMvHYEjwcxB4J7YQOQAYEsl1WDD4FqJBk X-IronPort-AV: E=Sophos;i="4.87,822,1363132800"; d="p7s'?scan'208";a="220095142" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-5.cisco.com with ESMTP; 07 Jun 2013 15:46:40 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r57FkdtN005694 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 7 Jun 2013 15:46:39 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.24]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.02.0318.004; Fri, 7 Jun 2013 10:46:39 -0500 From: "Matt Miller (mamille2)" To: Nico Williams Thread-Topic: [Json] The names within an object SHOULD be unique. Thread-Index: AQHOYhtyBSnxVkBEbkeV6bO5MJr11ZkpmAIAgAADZgCAAAG6gIABHt0A Date: Fri, 7 Jun 2013 15:46:38 +0000 Message-ID: References: <51AF8479.5080002@crockford.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.129.24.59] Content-Type: multipart/signed; boundary="Apple-Mail=_8A82AC51-F74F-4F32-A4DE-AC4A50EAA997"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Cc: Douglas Crockford , "json@ietf.org" Subject: Re: [Json] The names within an object SHOULD be unique. X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 07 Jun 2013 15:46:49 -0000 --Apple-Mail=_8A82AC51-F74F-4F32-A4DE-AC4A50EAA997 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Nico, would you clarify your proposal to indicate place or places in = 4627bis-02 your text replace or append to? With regards to parsers types elsewhere in this, while I also think = there might only be two, Paul does raise an interesting point about = keeping the extra terms to a minimum. I think we can further refine the = language as long as we're clear where and how this proposal fits. - m&m Matt Miller < mamille2@cisco.com > Cisco Systems, Inc. On Jun 6, 2013, at 4:39 PM, Nico Williams wrote: > On Thu, Jun 6, 2013 at 5:33 PM, Matt Miller (mamille2) > wrote: >> On Jun 6, 2013, at 4:21 PM, Nico Williams >> wrote: >>> [...] >>=20 >> Note that so far, the document uses the term "name", not "key". I = think the following needs to substitute "key" with "name" to be = consistent. >=20 > Ah, sure. >=20 >>> Encoders SHOULD NOT send duplicate keys. Some encoders might not >>> be able to prevent duplicate keys. Therefore parsers MUST be = prepared >>> to handle duplicate keys. >>>=20 >>> Stateful parsers MUST accept [use?] only the last of any set of >>> duplicate keys. >>>=20 >>=20 >> I think this still needs to allow for stateful parsers that reject = duplicate keys (for which there are some). >=20 > That's fair. >=20 >> Maybe: >>=20 >> #### >>=20 >> Stateful parsers MAY reject duplicate names. However, if duplicate = names are accepted, it MUST accept only the last value of any set of = duplicate names. >=20 > Sure. I think we should define terms like "stateful parser" and > "streaming parser". >=20 >> #### >>=20 >>> Some parsers might not be able to detect duplicate keys, much less >>> pick only the last of them. Here a "stateful parser" is one that >>> keeps on hand all of the values it decodes, as it decodes them. = Note >>> that accepting duplicate keys presents potential security risks. = Note >>> that sending duplicate keys risks data loss (that is, the loss of = all >>> but the last of a duplicated key's values). >>>=20 >>=20 >> Can we describe a couple of specific security risks that are = incurred? I think one would be something like overwriting of the = original value by an attacker intercepting the exchange. >=20 > I'm not concerned about MITMs and such. I'm concerned about attacks > where we have a validator of some sorts as a filter and then a final > consumer. The sender might send JSON that the validator accepts as > valid, that will be passed on to the final consumer, and where the > consumer will receive a different document (from it's p.o.v.) than the > validator saw. >=20 > Nico > -- > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json --Apple-Mail=_8A82AC51-F74F-4F32-A4DE-AC4A50EAA997 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMezCCBjQw ggQcoAMCAQICAR4wDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDE1NVoX DTE3MTAyNDIxMDE1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMcJg8zOLdgasSmkLhOrlr6KMoOMpohBllVHrdRvEg/q6r8jR+EK 75xCGhR8ToREoqe7zM9/UnC6TS2y9UKTpT1v7RSMzR0t6ndl0TWBuUr/UXBhPk+Kmy7bI4yW4urC +y7P3/1/X7U8ocb8VpH/Clt+4iq7nirMcNh6qJR+xjOhV+VHzQMALuGYn5KZmc1NbJQYclsGkDxD z2UbFqE2+6vIZoL+jb9x4Pa5gNf1TwSDkOkikZB1xtB4ZqtXThaABSONdfmv/Z1pua3FYxnCFmdr /+N2JLKutIxMYqQOJebr/f/h5t95m4JgrM3Y/w7YX9d7YAL9jvN4SydHsU6n65cCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRTcu2SnODaywFc fH6WNU7y1LhRgjAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBAAqDCH14qywG XLhjjF6uHLkjd02hcdh9hrw+VUsv+q1eeQWB21jWj3kJ96AUlPCoEGZ/ynJNScWy6QMVQjbbMXlt UfO4n4bGGdKo3awPWp61tjAFgraLJgDk+DsSvUD6EowjMTNx25GQgyYJ5RPIzKKR9tQW8gGK+2+R HxkUCTbYFnL6kl8Ch507rUdPPipJ9CgJFws3kDS3gOS5WFMxcjO5DwKfKSETEPrHh7p5shuuNktv sv6hxHTLhiMKX893gxdT3XLS9OKmCv87vkINQcNEcIIoFWbP9HORz9v3vQwR4e3ksLc2JZOAFK+s sS5XMEoznzpihEP0PLc4dCBYjbvSD7kxgDwZ+Aj8Q9PkbvE9sIPP7ON0fz095HdThKjiVJe6vofq +n6b1NBc8XdrQvBmunwxD5nvtTW4vtN6VY7mUCmxsCieuoBJ9OlqmsVWQvifIYf40dJPZkk9YgGT zWLpXDSfLSplbY2LL9C9U0ptvjcDjefLTvqSFc7tw1sEhF0n/qpA2r0GpvkLRDmcSwVyPvmjFBGq Up/pNy8ZuPGQmHwFi2/14+xeSUDG2bwnsYJQG2EdJCB6luQ57GEnTA/yKZSTKI8dDQa8Sd3zfXb1 9mOgSF0bBdXbuKhEpuP9wirslFe6fQ1t5j5R0xi72MZ8ikMu1RQZKCyDbMwazlHiMIIGPzCCBSeg AwIBAgIDBoRIMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcN MTMwNDMwMjE1NDQyWhcNMTQwNTAyMDUzOTA0WjBbMRkwFwYDVQQNExBiN2F6NndOY0t0R3JtMEpF MRswGQYDVQQDDBJtYW1pbGxlMkBjaXNjby5jb20xITAfBgkqhkiG9w0BCQEWEm1hbWlsbGUyQGNp c2NvLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJbKBMsG+9UFTx9uq/bhhXgu vJvO8z7cwKaqqwZhVf5z/kHFyCNijtmTOE+YXjA8mWR4aoBwB5SvGypI/cJUofJ+AlBTC4g+RMx/ K0Ab4/jQqTQz9CDzMOB+Wm+rt8ZJ7A8ZzOJmNDAsf/VvB8l2A1SQz1UsAixgH16NTr8SlblAXEKk 4hwpCudUiNjjQokqJ0H686UBKVorcZSgXaza8XMqGtJF/8mNhR9GQYi7Xht1ky+9LFOrto2daZto KJRwMeVusVdHUeKEQSu7jztw8HchH3KEb7Q+r5X+hhDZoddfKE8d5eyPuhiZdrzv7OlNZ0fSLdx7 3AE3nx9/R5YlXucCAwEAAaOCAtgwggLUMAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQW MBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQUxGd+/qrdVudHrIKkw5xOMY7eaLUwHwYD VR0jBBgwFoAUU3Ltkpzg2ssBXHx+ljVO8tS4UYIwHQYDVR0RBBYwFIESbWFtaWxsZTJAY2lzY28u Y29tMIIBTAYDVR0gBIIBQzCCAT8wggE7BgsrBgEEAYG1NwECAzCCASowLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0 Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBp c3N1ZWQgYWNjb3JkaW5nIHRvIHRoZSBDbGFzcyAxIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9m IHRoZSBTdGFydENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBw dXJwb3NlIGluIGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMDYG A1UdHwQvMC0wK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUxLWNybC5jcmwwgY4G CCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIv Y2xhc3MxL2NsaWVudC9jYTBCBggrBgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2Vy dHMvc3ViLmNsYXNzMS5jbGllbnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRz c2wuY29tLzANBgkqhkiG9w0BAQUFAAOCAQEAlDhXbGEI7lbqUcu5r2JHZaMsbRZda/99ZqODzWGX 0llou9jGccsAWDPPwRRe2+ROpXfH4cuJZElTcLDeZSp/qpXKhjYieFSX8+Ml9sKEj5UOSqQLyoLk PtrIJV12Jk3nuG2Jc0UeEnGwK/aqtzy7+bfEVI0ziyVM2gChHh0RH74KyiwYWknbOTRIkZcz/ulE DVFQp63uj6wfmDNvAUHBAdhKVqA1S/rfP1KcDZpf1NfvwXJibiqTRA6K1EOxTJOP41n/XdvHqHXL RWL2xrOUI9/URANr/ok3OrsuZEMFnAAGefS1bWS/hFtUGVkHGiKEBbyDW7da2ULXbuC7umrQnzGC A28wggNrAgEBMIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkG A1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwaESDAJBgUrDgMCGgUA oIIBrzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMzA2MDcxNTQ2 MzlaMCMGCSqGSIb3DQEJBDEWBBSb98iNfUbYPZTbIDyN9FIB5UXl8DCBpQYJKwYBBAGCNxAEMYGX MIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3Mg MSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwaESDCBpwYLKoZIhvcNAQkQAgsxgZeg gZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1 cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAx IFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDBoRIMA0GCSqGSIb3DQEBAQUABIIBABSn HsY/iUXvC+3qrwjA/eIYdVJwfRIeh0te9gkin1WJKr1xhpEuVne7cqSpz9u6yOKoEct0JtgLiu7H pKlAetwf0UZxCB9OhV156XP7TGVSPZ6PSapU1tYW2mWLiI9rgciKo11c9n05mqytn0AuZIVQd2Rg leu9PdRltki4Tcc5o7TSrhYluXZcwcmJIU3gfGRtIY7C1Ic5JIrn+cRtSzwr+EClZ/XYRcr2DDUU TyTL1NzxMDBJuSZ9DiMnoRHyhwt/hy03KG+e/GA2Haaj4p5LHv03UaZ6VclhaA204Gnztsk6+t1K IqzWPBLi3a8S9PtsAYkRyecnOy0zSN3V7IMAAAAAAAA= --Apple-Mail=_8A82AC51-F74F-4F32-A4DE-AC4A50EAA997-- From paul.hoffman@vpnc.org Fri Jun 7 08:56:45 2013 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 057F521F96FB for ; Fri, 7 Jun 2013 08:56:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.355 X-Spam-Level: X-Spam-Status: No, score=-102.355 tagged_above=-999 required=5 tests=[AWL=0.244, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 42GNVr8f1rvG for ; Fri, 7 Jun 2013 08:56:44 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 432E621F96F4 for ; Fri, 7 Jun 2013 08:56:44 -0700 (PDT) Received: from [10.20.30.90] (50-0-66-165.dsl.dynamic.sonic.net [50.0.66.165]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r57Fuh55082174 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 7 Jun 2013 08:56:43 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Paul Hoffman In-Reply-To: <9ld3r8pc0tufif18dohb2fmi0ijna1vs4n@hive.bjoern.hoehrmann.de> Date: Fri, 7 Jun 2013 08:56:42 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <56A163E9-E7CD-46B3-9984-8F009EBFF500@vpnc.org> References: <51B06F38.8050707@crockford.com> <51B1B4E7.8090101@it.aoyama.ac.jp> <9ld3r8pc0tufif18dohb2fmi0ijna1vs4n@hive.bjoern.hoehrmann.de> To: "json@ietf.org" X-Mailer: Apple Mail (2.1508) Subject: [Json] On characters and code points X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 07 Jun 2013 15:56:45 -0000 This may be a part of the spec where some people have to hold their = noses. The Unicode definition of "character" does not include = non-characters, and the code points for some of those non-characters = make sense in JSON strings when those strings. Bjoern has pointed out a = good one: strings used for test cases of other code. The issue not just = unpaired surrogates. Do we *really* want to prohibit: { "End of data marker": "\uFFFF" } Proposal: Remove the word "character" from the spec except in an explanatory = paragraph in Section 2.5 that says: All code points, even those that represent non-characters in the = Unicode specification [UNICODE], are allowed in JSON strings. --Paul Hoffman= From tbray@textuality.com Fri Jun 7 08:57:27 2013 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 0425721F90FD for ; Fri, 7 Jun 2013 08:57:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.951 X-Spam-Level: X-Spam-Status: No, score=-0.951 tagged_above=-999 required=5 tests=[AWL=2.025, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XOMAPS-jLiu3 for ; Fri, 7 Jun 2013 08:57:22 -0700 (PDT) Received: from mail-vc0-f175.google.com (mail-vc0-f175.google.com [209.85.220.175]) by ietfa.amsl.com (Postfix) with ESMTP id 0B42421F8AE6 for ; Fri, 7 Jun 2013 08:57:17 -0700 (PDT) Received: by mail-vc0-f175.google.com with SMTP id hr11so2845714vcb.6 for ; Fri, 07 Jun 2013 08:57:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=SMczQ99mC2ugQeX8OTuwvnm6v3B955JOefrht4uodgw=; b=N3OeYxaWs3lmxOGwI3QvRlkSmMEMm77zsg+2nER8IFsZEObKuzS5Oy/hsmnyjkLFst WIpWOmmOQ+VsjJS1LxTkFzT38xKfjmbMziOq0cXNsXAgXv/bvje3qONZLLzbvHswzJMr iDT4SVs7NDAulJaX9kNewqgmvpMpc60z7nYYZQvEMz5efYy2hMXu+AukUAhPW2F0f24v hSWPabAultuFRzwzEtccp5n/rdtXG0TX2PQi1lLZpPuuboAjKVPpEVrvF/knMoOnRfKx 2eLg+uDykBusFCIpZlbo5Ho6+29PJ/7cHj3t8sp52lk9Ab8POsApYZKJVd/Bx4dBj40B zvqw== MIME-Version: 1.0 X-Received: by 10.52.30.14 with SMTP id o14mr19448324vdh.106.1370620637050; Fri, 07 Jun 2013 08:57:17 -0700 (PDT) Received: by 10.220.48.14 with HTTP; Fri, 7 Jun 2013 08:57:16 -0700 (PDT) X-Originating-IP: [24.84.235.32] In-Reply-To: <255B9BB34FB7D647A506DC292726F6E1151B21F9A9@WSMSG3153V.srv.dir.telstra.com> References: <255B9BB34FB7D647A506DC292726F6E1151B21F9A9@WSMSG3153V.srv.dir.telstra.com> Date: Fri, 7 Jun 2013 08:57:16 -0700 Message-ID: From: Tim Bray To: "Manger, James H" Content-Type: multipart/alternative; boundary=20cf307ca1e631952604de927cc8 X-Gm-Message-State: ALoCoQkyCvElwxeI+vD2SbfD/EP0jkXqaLNFRP0pQpS/D3vX0FXaJfYuuthiXGi+cNkm2qSWeW4O Cc: "json@ietf.org" Subject: Re: [Json] Allow any JSON value at the top level X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 07 Jun 2013 15:57:27 -0000 --20cf307ca1e631952604de927cc8 Content-Type: text/plain; charset=UTF-8 On Thu, Jun 6, 2013 at 8:51 PM, Manger, James H < James.H.Manger@team.telstra.com> wrote: > The current spec only allows a JSON text to be an object or array. Section > 2. "JSON Grammar" says: > ... > I propose allowing a JSON text to be any JSON value. > -1. 1. Our mandate is not to enhance or improve JSON. 2. This is a bad idea in general and a terrible idea for network protocols, which is where JSON is most valuable. -T > > A JSON text is a serialization of any JSON value. > > JSON-text = value > > value = false / null / true / object / array / number / string > > > ECMAScript already allows this. > http://www.ecma-international.org/ecma-262/5.1/#sec-15.12 > > * The top level JSONText production of the ECMAScript JSON grammar > may consist of any JSONValue rather than being restricted to being > a JSONObject or a JSONArray as specified by RFC 4627. > > -- > James Manger > > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > --20cf307ca1e631952604de927cc8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, Jun 6, 2013 at 8:51 PM, Manger, James H <James.H.Manger@team.telstra.com> wrote:
The current spec = only allows a JSON text to be an object or array. Section 2. "JSON Gra= mmar" says:
...
I propose allowing a JSON text to be any JSON value.
<= br>-1.

1. Our mandate is not to enhance or improve JSON.<= br>
2. This is a bad idea in general and a terrible idea for netw= ork protocols, which is where JSON is most valuable.=C2=A0

-T
=C2=A0

=C2=A0 =C2=A0A JSON text is a serialization of any JSON value.

=C2=A0 =C2=A0JSON-text =3D value

=C2=A0 =C2=A0value =3D false / null / true / object / array / number / stri= ng


ECMAScript already allows this. http://www.ecma-international.= org/ecma-262/5.1/#sec-15.12

=C2=A0 =C2=A0* The top level JSONText production of the ECMAScript JSON gra= mmar
=C2=A0 =C2=A0 =C2=A0may consist of any JSONValue rather than being restrict= ed to being
=C2=A0 =C2=A0 =C2=A0a JSONObject or a JSONArray as specified by RFC 4627.
--
James Manger


_______________________________________________
json mailing list
json@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/json

--20cf307ca1e631952604de927cc8-- From paul.hoffman@vpnc.org Fri Jun 7 08:58:54 2013 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 3FC1D21F9711 for ; Fri, 7 Jun 2013 08:58:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.364 X-Spam-Level: X-Spam-Status: No, score=-102.364 tagged_above=-999 required=5 tests=[AWL=0.235, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kDmV0PwBfqoC for ; Fri, 7 Jun 2013 08:58:53 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 7A0FE21F91BC for ; Fri, 7 Jun 2013 08:58:53 -0700 (PDT) Received: from [10.20.30.90] (50-0-66-165.dsl.dynamic.sonic.net [50.0.66.165]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r57FwmjU082261 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 7 Jun 2013 08:58:49 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Paul Hoffman In-Reply-To: <51B1885F.3080908@drees.name> Date: Fri, 7 Jun 2013 08:58:48 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <9D5D948B-BD1E-4195-9B05-3376D6EFFAEA@vpnc.org> References: <51B0E02E.4070209@crockford.com> <1BD0044B-D7A6-4C7F-899E-5D3E72C62956@vpnc.org> <51B116FE.9050406@crockford.com> <51B1885F.3080908@drees.name> To: stefan@drees.name X-Mailer: Apple Mail (2.1508) Cc: Douglas Crockford , "json@ietf.org" Subject: Re: [Json] Security Considerations X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 07 Jun 2013 15:58:54 -0000 On Jun 7, 2013, at 12:14 AM, Stefan Drees wrote: > On 07.06.13 01:10, Douglas Crockford wrote: >> On 6/6/2013 4:04 PM, Paul Hoffman wrote: >>>=20 >>> On Jun 6, 2013, at 12:17 PM, Douglas Crockford = >>> wrote: >>>=20 >>>> Proposal: >>>>=20 >>>> With any data format, it is important to encode correctly. Care = must >>>> be taken when constructing JSON texts by concatenation. For = example: >>>>=20 >>>> account =3D 4627; >>>> comment =3D "\",\"account\":262"; // provided by attacker >>>> json_text =3D "(\"account\":" + account + ",\"comment\":\"" + >>>> comment + "\"}"; >>> The example is language-specific and, due to the escaping, hard to = read. >> Which specific language would you say it is? Confusion attacks are = often >> hard to read. That is why they work. ... >=20 > I propose to keep the example, but remove the need for quoting by = switching to single quotes where needed: >=20 > """ > account =3D 4627; > comment =3D '","account":262'; // provided by attacker > json_text =3D '("account":' + account + ',"comment":"' + comment + = '"}'; > """ >=20 > this is valid (Java|ECMA)Script, right and also much more readable, = isn't it? I can live with this, but I think doing it in English wording is better. --Paul Hoffman= From paul.hoffman@vpnc.org Fri Jun 7 08:59:48 2013 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 F2AA221F9815 for ; Fri, 7 Jun 2013 08:59:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.373 X-Spam-Level: X-Spam-Status: No, score=-102.373 tagged_above=-999 required=5 tests=[AWL=0.226, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D1ZuXoiELWkV for ; Fri, 7 Jun 2013 08:59:47 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id D01A221F91BC for ; Fri, 7 Jun 2013 08:59:46 -0700 (PDT) Received: from [10.20.30.90] (50-0-66-165.dsl.dynamic.sonic.net [50.0.66.165]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r57FwmjV082261 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 7 Jun 2013 08:59:46 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Paul Hoffman In-Reply-To: <51B18B1E.30805@drees.name> Date: Fri, 7 Jun 2013 08:59:46 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <21287B59-F6E3-43E4-891D-4A3744912CBE@vpnc.org> References: <51B0E02E.4070209@crockford.com> <51B18B1E.30805@drees.name> To: "json@ietf.org" X-Mailer: Apple Mail (2.1508) Subject: Re: [Json] Security Considerations X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 07 Jun 2013 15:59:48 -0000 On Jun 7, 2013, at 12:26 AM, Stefan Drees wrote: > For me the main points of data interchange and in sequence are: >=20 > 1. Do not parse any untrusted data without preconditioning >=20 > 2. Do not excecute/eval untrusted data >=20 > and trust is sometimes hard to establish ... >=20 > As long as these two points stand out and are not burried inside = sample language terms, I am happy with any re-phrasing. That sounds like a good goal for the section. --Paul Hoffman= From tbray@textuality.com Fri Jun 7 09:02:20 2013 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 6D0DC21F8887 for ; Fri, 7 Jun 2013 09:02:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.81 X-Spam-Level: X-Spam-Status: No, score=0.81 tagged_above=-999 required=5 tests=[AWL=-0.547, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j0BciLncIiwP for ; Fri, 7 Jun 2013 09:02:13 -0700 (PDT) Received: from mail-vb0-x22f.google.com (mail-vb0-x22f.google.com [IPv6:2607:f8b0:400c:c02::22f]) by ietfa.amsl.com (Postfix) with ESMTP id BB6BF21F9744 for ; Fri, 7 Jun 2013 09:01:41 -0700 (PDT) Received: by mail-vb0-f47.google.com with SMTP id x14so2800187vbb.20 for ; Fri, 07 Jun 2013 09:01:39 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=H7h+62GBPc3jhqSvzH3hkK4PEKJdwG3w/QmblNK+zYU=; b=cMW/7l1+FALyYtuu1Cn4PGvS5qb/8+W9bbBoa2NrhNPWqKuHXUe6uhZRoSrxFctatg +HIE63YGX61iHiCfAaD2/ZAAjiUuEuGeUXrv7sialS9BlXR82peCk3HxV2xqjwfFptbC F5ddnAxpaZz8f6BL9cpds772WG1qfYtx9DtPb6E9UVKh31q4XT1jUNijSwwfpZzRXXLM h69smB2A5keM+GlFy31LLw7wxUjk4s+LjX+wllRvW0K6ty/vEJE//P9xiGCF0q+clLFx n62qXZOndvE8tygr1TMbL/WHz0mzEa/Eug08884W7GCNUd1v2unN7+ul9vWsk69YPLzW YV3g== MIME-Version: 1.0 X-Received: by 10.52.237.228 with SMTP id vf4mr3232968vdc.79.1370620899451; Fri, 07 Jun 2013 09:01:39 -0700 (PDT) Received: by 10.220.48.14 with HTTP; Fri, 7 Jun 2013 09:01:39 -0700 (PDT) X-Originating-IP: [24.84.235.32] In-Reply-To: <56A163E9-E7CD-46B3-9984-8F009EBFF500@vpnc.org> References: <51B06F38.8050707@crockford.com> <51B1B4E7.8090101@it.aoyama.ac.jp> <9ld3r8pc0tufif18dohb2fmi0ijna1vs4n@hive.bjoern.hoehrmann.de> <56A163E9-E7CD-46B3-9984-8F009EBFF500@vpnc.org> Date: Fri, 7 Jun 2013 09:01:39 -0700 Message-ID: From: Tim Bray To: Paul Hoffman Content-Type: multipart/alternative; boundary=089e0122f6aad575d404de928b10 X-Gm-Message-State: ALoCoQmdT++1dsF4sWmrVln/Lwrzd0A+NbqHEWqfdk6YS0a1P7v5zxvDCp97iTIVzNhGvIA/yRbi Cc: "json@ietf.org" Subject: Re: [Json] On characters and code points X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 07 Jun 2013 16:02:22 -0000 --089e0122f6aad575d404de928b10 Content-Type: text/plain; charset=UTF-8 On Fri, Jun 7, 2013 at 8:56 AM, Paul Hoffman wrote: > This may be a part of the spec where some people have to hold their noses. > The Unicode definition of "character" does not include non-characters, and > the code points for some of those non-characters make sense in JSON strings > when those strings. Bjoern has pointed out a good one: strings used for > test cases of other code. The issue not just unpaired surrogates. Do we > *really* want to prohibit: > { "End of data marker": "\uFFFF" } > Yes, I *really* want to prohibit that. The one corner case it buys you is outweighed by a factor of a thousand or so in not being able to use general-purpose string processing software to deal with JSON payloads. BTW, a huge amount of deployed software out there ALREADY processes JSON text fields using general-purpose string processing libraries, and will explode unpredictably and in hard-to-debug ways if this starts happening. Also, consider the lovely consequences when unpaired surrogates start showing up in key fields and are fed to hash functions in every programming language in the world, which expect to receive Unicode characters. -T > > Proposal: > > Remove the word "character" from the spec except in an explanatory > paragraph in Section 2.5 that says: > All code points, even those that represent non-characters in the > Unicode specification [UNICODE], are allowed in JSON strings. > > --Paul Hoffman > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > --089e0122f6aad575d404de928b10 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Fri, Jun 7, 2013 at 8:56 AM, Paul Hoffman <paul.ho= ffman@vpnc.org> wrote:
This may be a part of the spec where some pe= ople have to hold their noses. The Unicode definition of "character&qu= ot; does not include non-characters, and the code points for some of those = non-characters make sense in JSON strings when those strings. Bjoern has po= inted out a good one: strings used for test cases of other code. The issue = not just unpaired surrogates. Do we *really* want to prohibit:
=C2=A0 =C2=A0{ "End of data marker": "\uFFFF" }

Yes, I *really* want to prohibit that. The one= corner case it buys you is outweighed by a factor of a thousand or so in n= ot being able to use general-purpose string processing software to deal wit= h JSON payloads.=C2=A0=C2=A0 BTW, a huge amount of deployed software out th= ere ALREADY processes JSON text fields using general-purpose string process= ing libraries, and will explode unpredictably and in hard-to-debug ways if = this starts happening.

Also, consider the lovely consequences when unpaired surrogates start s= howing=C2=A0 up in key fields and are fed to hash functions in every progra= mming language in the world, which expect to receive Unicode characters.
=C2=A0-T

=C2=A0

Proposal:

Remove the word "character" from the spec except in an explanator= y paragraph in Section 2.5 that says:
=C2=A0 =C2=A0All code points, even those that represent non-characters in t= he Unicode specification [UNICODE], are allowed in JSON strings.

--Paul Hoffman
_______________________________________________
json mailing list
json@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/json

--089e0122f6aad575d404de928b10-- From stefan@drees.name Fri Jun 7 09:07:18 2013 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 621DD21F8956 for ; Fri, 7 Jun 2013 09:07:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.187 X-Spam-Level: X-Spam-Status: No, score=-2.187 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Y9Uq2HKFRHq for ; Fri, 7 Jun 2013 09:07:12 -0700 (PDT) Received: from mout.web.de (mout.web.de [212.227.17.11]) by ietfa.amsl.com (Postfix) with ESMTP id 3FD8521F8756 for ; Fri, 7 Jun 2013 09:07:12 -0700 (PDT) Received: from newyork.local.box ([93.129.186.5]) by smtp.web.de (mrweb004) with ESMTPSA (Nemesis) id 0MMZck-1UjMMm409G-008Fgl; Fri, 07 Jun 2013 18:07:07 +0200 Message-ID: <51B20529.2040906@drees.name> Date: Fri, 07 Jun 2013 18:07:05 +0200 From: Stefan Drees User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Paul Hoffman References: <255B9BB34FB7D647A506DC292726F6E1151B21F9A9@WSMSG3153V.srv.dir.telstra.com> <3B4E7F65-B9B9-4C95-B077-D178B8DD8216@vpnc.org> In-Reply-To: <3B4E7F65-B9B9-4C95-B077-D178B8DD8216@vpnc.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:PV5q+80YkKN+E5/V5cWGufl53WIbZkEPQwA3L/sm4bUjWofq0Hk S3RMFy0Cvppdi8LdfiHosNRBMfFmvWxeSL5viYtfKmlOg8WSCqdFtBj90DTdEIhp13pqADC 4G/U3ZgwYrrO6mV+tfrap+NgH/PamE7JtN8uge5pzg7wnsuDaLWQUI+qX3oCv4yUCRQ7CrB MpmU9reVbcen2q1Wp3B+w== Cc: "json@ietf.org" Subject: Re: [Json] Allow any JSON value at the top level X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stefan@drees.name List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2013 16:07:18 -0000 On 07.06.13 17:40, Paul Hoffman wrote: > > > On Jun 6, 2013, at 8:51 PM, "Manger, James H" wrote: > >> The current spec only allows a JSON text to be an object or array. Section 2. "JSON Grammar" says: >> >> A JSON text is a serialized object or array. >> >> JSON-text = object / array >> >> >> I propose allowing a JSON text to be any JSON value. >> >> A JSON text is a serialization of any JSON value. >> >> JSON-text = value >> >> value = false / null / true / object / array / number / string > > +1 to this, and to removing the "how to tell if you are looking at a > JSON text" from the parser section. That rule is fragile and not useful. > +0 as long as the future encoding detection tricks in section 3 are coherent with it. > I am interested to hear examples of where this change would cause > breakage, particularly given that ECMAScript already has this rule. I expect that all the php, python whatever (de-)serializers will deliver no surprises. Sample PHP: $> cat ./json_test_null.php php ./json_test_null.php false transforms to: """ of type: boolean null transforms to: """ of type: NULL true transforms to: "1"" of type: boolean {} transforms to: "stdClass Object ( ) "" of type: object [] transforms to: "Array ( ) "" of type: array 42 transforms to: "42"" of type: integer "Äther" transforms to: "Äther"" of type: string So all well with php (5.3.25). All the ebst, Stefan. From stedolan@stedolan.net Fri Jun 7 09:09:52 2013 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 C542D21F9642 for ; Fri, 7 Jun 2013 09:09:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.402 X-Spam-Level: X-Spam-Status: No, score=-1.402 tagged_above=-999 required=5 tests=[AWL=0.975, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 84fyfREVDtaZ for ; Fri, 7 Jun 2013 09:09:48 -0700 (PDT) Received: from mail-lb0-f173.google.com (mail-lb0-f173.google.com [209.85.217.173]) by ietfa.amsl.com (Postfix) with ESMTP id 2E35521F9600 for ; Fri, 7 Jun 2013 09:09:47 -0700 (PDT) Received: by mail-lb0-f173.google.com with SMTP id t10so4440789lbi.18 for ; Fri, 07 Jun 2013 09:09:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:x-originating-ip:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding:x-gm-message-state; bh=BSiOP+hTDDS842gtMHaGYEP1sSpAVWYXMPPepSaTmZk=; b=K7x8TurYIkxzOHGzQLeR+IPx2n9zDKNgeWKEVL792rYzp+hkogy/h4KvAJIDKKKN5T tVX6nQPFJ5slFmlsx1RCRAAYFPo0MpKNMBg7FRUYR4kHXSFU9lpqjJ26qDgsWa3f5Apv Hei7iFWVhSRYqzSsPi1jBQGo9nV+fonRWygV4fDh/XGc097cL/f9Gs22AoJsmIpieYrp A5JX1HDdUGjtgE9v5Eo6I4jTvWRT8SIKrtzgBVe61FYcKmEZifkStcEKRGunM6GPyp78 AvdSXzzJsSvCW92tYDxLnYVCLgeKhisFlvJtwZnQ5FNPliwzgyacMSCveMu79yj7AQl7 kdCw== MIME-Version: 1.0 X-Received: by 10.112.144.69 with SMTP id sk5mr1530094lbb.64.1370621386619; Fri, 07 Jun 2013 09:09:46 -0700 (PDT) Sender: stedolan@stedolan.net Received: by 10.114.186.41 with HTTP; Fri, 7 Jun 2013 09:09:46 -0700 (PDT) X-Originating-IP: [128.232.9.157] In-Reply-To: <56A163E9-E7CD-46B3-9984-8F009EBFF500@vpnc.org> References: <51B06F38.8050707@crockford.com> <51B1B4E7.8090101@it.aoyama.ac.jp> <9ld3r8pc0tufif18dohb2fmi0ijna1vs4n@hive.bjoern.hoehrmann.de> <56A163E9-E7CD-46B3-9984-8F009EBFF500@vpnc.org> Date: Fri, 7 Jun 2013 17:09:46 +0100 X-Google-Sender-Auth: TE3FAOTdp5YpvZKzfhg_UY9cBPw Message-ID: From: Stephen Dolan To: Paul Hoffman Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQluaeVTbcWcZZZgR1f/GEpVhJsMAyy+YOrsGdhKIremcXFBaotMuv1mYbSAEvWjvM7MD803 Cc: "json@ietf.org" Subject: Re: [Json] On characters and code points X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 07 Jun 2013 16:09:52 -0000 I think it is useful to distinguish three cases of codepoint: (1) Those which are valid characters in a particular Unicode revision (2) Those which are unallocated codepoints which may become valid characters in a later Unicode revision (3) The noncharacter codepoints which will never be valid (3) includes such beasts as U+FFFE (which you can only get by reading a UTF16 byte order mark with the wrong byte order). The set (1) increases with every Unicode revision to include characters from (2), but (3) is stable (see http://unicode.org/policies/stability_policy.html). I think JSON should allow characters from (1) and (2) to avoid being dependent on a specific Unicode revision. I do not think (3) should be allowed - this would cause problems with many existing parsers which represent JSON strings using another system's native unicode representation. The argument about testsuites does not seem compelling, as any such testsuite testing behaviour of string functions with bad Unicode would also include invalidly-encoded Unicode (such as overlong UTF8 sequences) which cannot be represented at all in JSON, even with escaping. Stephen On Fri, Jun 7, 2013 at 4:56 PM, Paul Hoffman wrote: > > > This may be a part of the spec where some people have to hold their noses= . The Unicode definition of "character" does not include non-characters, an= d the code points for some of those non-characters make sense in JSON strin= gs when those strings. Bjoern has pointed out a good one: strings used for = test cases of other code. The issue not just unpaired surrogates. Do we *re= ally* want to prohibit: > { "End of data marker": "\uFFFF" } > > Proposal: > > Remove the word "character" from the spec except in an explanatory paragr= aph in Section 2.5 that says: > All code points, even those that represent non-characters in the Unico= de specification [UNICODE], are allowed in JSON strings. > > --Paul Hoffman > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json From stefan@drees.name Fri Jun 7 09:16:21 2013 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 75B6321F9957 for ; Fri, 7 Jun 2013 09:16:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.191 X-Spam-Level: X-Spam-Status: No, score=-2.191 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l58wHfIU2IhP for ; Fri, 7 Jun 2013 09:16:15 -0700 (PDT) Received: from mout.web.de (mout.web.de [212.227.15.14]) by ietfa.amsl.com (Postfix) with ESMTP id 3BA3821F964C for ; Fri, 7 Jun 2013 09:15:56 -0700 (PDT) Received: from newyork.local.box ([93.129.186.5]) by smtp.web.de (mrweb102) with ESMTPSA (Nemesis) id 0MCZh8-1Ubfed3PBi-009QLa; Fri, 07 Jun 2013 18:15:46 +0200 Message-ID: <51B20731.3040300@drees.name> Date: Fri, 07 Jun 2013 18:15:45 +0200 From: Stefan Drees User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Tim Bray References: <51B06F38.8050707@crockford.com> <51B1B4E7.8090101@it.aoyama.ac.jp> <9ld3r8pc0tufif18dohb2fmi0ijna1vs4n@hive.bjoern.hoehrmann.de> <56A163E9-E7CD-46B3-9984-8F009EBFF500@vpnc.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V02:K0:oeXGsdWOgc/sTMYAgReaQ8ieM2a2Mo8YE/vlnRPecRs eTBSjoG89c7ngUCCmsoE6dUsyrNK7G9catAALDIINaWTrQ1VxG bkxFpwBOirsprgxZI3kqtTxsqak4fDAzY0THIfKKKKCbagkePy pGGwu15BS3qVeEtMP3/RaPor2QwIKpGfkyIPtswjfMd/YdGSHn 7V/+cKqQX/FCU1voOsiMg== Cc: Paul Hoffman , "json@ietf.org" Subject: Re: [Json] On characters and code points X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stefan@drees.name List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2013 16:16:21 -0000 On 2013-06-07 18:01, Tim Bray wrote: > On Fri, Jun 7, 2013 at 8:56 AM, Paul Hoffman ... wrote: > > This may be a part of the spec where some people have to hold their > noses. The Unicode definition of "character" does not include > non-characters, and the code points for some of those non-characters > make sense in JSON strings when those strings. Bjoern has pointed > out a good one: strings used for test cases of other code. The issue > not just unpaired surrogates. Do we *really* want to prohibit: > { "End of data marker": "\uFFFF" } > > > Yes, I *really* want to prohibit that. The one corner case it buys you > is outweighed by a factor of a thousand or so in not being able to use > general-purpose string processing software to deal with JSON payloads. > BTW, a huge amount of deployed software out there ALREADY processes JSON > text fields using general-purpose string processing libraries, and will > explode unpredictably and in hard-to-debug ways if this starts happening. and what about { "Decorate my slash": "\/" } and "general-purpose string processing software". Isn't this also a case, where you need a "pre-conditioner" that replaces the JSON specific escape sequence "\" with "/" before feeding it into "general-purpose string processing software" :-?) > Also, consider the lovely consequences when unpaired surrogates start > showing up in key fields and are fed to hash functions in every > programming language in the world, which expect to receive Unicode > characters. > -T > For today I better not imagine all these laguages and implementations blindly stuffing some json text transformed into their own memory structures ... maybe later during the weekend > ... Stefan. From tbray@textuality.com Fri Jun 7 09:18:24 2013 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 32BA021F86D5 for ; Fri, 7 Jun 2013 09:18:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.201 X-Spam-Level: * X-Spam-Status: No, score=1.201 tagged_above=-999 required=5 tests=[AWL=-0.756, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QQAvQoRxx+qg for ; Fri, 7 Jun 2013 09:18:08 -0700 (PDT) Received: from mail-ve0-x22b.google.com (mail-ve0-x22b.google.com [IPv6:2607:f8b0:400c:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 9484D21F944F for ; Fri, 7 Jun 2013 09:18:08 -0700 (PDT) Received: by mail-ve0-f171.google.com with SMTP id b10so3242509vea.30 for ; Fri, 07 Jun 2013 09:18:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=Q2dgx2OsPflK7vCc+B8VemqIRvIkysqF9JAw4os3Ks0=; b=omd7rR1OWKlh24ul0kAqcUSSGv4YnaKL+xItqsX6hdg3dDMCUP9GyYmQ/MXPJrhBty tNGyLo4bxOA5FguWY4Y3FHdTcKyIZ1+XeAxi+3lg2DYECztVSoCLuW5g8ZrkE5L7yb7h SK7HkNlznyEA5N/GVNANaxhD+SWFXZGa3OUMASw25KH1X1Z+N7/OT0B0dhgNyjMy9or/ 77yuOOgRK5yVrFqo9KY+Y3TP6C/BHx/JrNWNCrqrNkPC+uy06a5yfdBhIBas0t6CbaEP X3smcBqBR/0f2CwXtd7F0HWxVw435EBzz1RmRdA6KBvAX9+lFVWNy8SXb60Py4X3R4P6 o9Dg== MIME-Version: 1.0 X-Received: by 10.220.193.202 with SMTP id dv10mr10252889vcb.24.1370621887991; Fri, 07 Jun 2013 09:18:07 -0700 (PDT) Received: by 10.220.48.14 with HTTP; Fri, 7 Jun 2013 09:18:07 -0700 (PDT) X-Originating-IP: [24.84.235.32] In-Reply-To: References: <51B06F38.8050707@crockford.com> <51B1B4E7.8090101@it.aoyama.ac.jp> <9ld3r8pc0tufif18dohb2fmi0ijna1vs4n@hive.bjoern.hoehrmann.de> <56A163E9-E7CD-46B3-9984-8F009EBFF500@vpnc.org> Date: Fri, 7 Jun 2013 09:18:07 -0700 Message-ID: From: Tim Bray To: Stephen Dolan Content-Type: multipart/alternative; boundary=047d7b673dbac163bc04de92c6d8 X-Gm-Message-State: ALoCoQmh/VyqayOXQ6/XZBWu88371QeOKlTquIsNoG9TCeNBJnHNidzrBc+M70pYhQN/oC0tUNaK Cc: Paul Hoffman , "json@ietf.org" Subject: Re: [Json] On characters and code points X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 07 Jun 2013 16:18:24 -0000 --047d7b673dbac163bc04de92c6d8 Content-Type: text/plain; charset=UTF-8 I agree 100% with Stephen Dolan. -T On Fri, Jun 7, 2013 at 9:09 AM, Stephen Dolan wrote: > I think it is useful to distinguish three cases of codepoint: > (1) Those which are valid characters in a particular Unicode revision > (2) Those which are unallocated codepoints which may become valid > characters in a later Unicode revision > (3) The noncharacter codepoints which will never be valid > > (3) includes such beasts as U+FFFE (which you can only get by reading > a UTF16 byte order mark with the wrong byte order). The set (1) > increases with every Unicode revision to include characters from (2), > but (3) is stable (see > http://unicode.org/policies/stability_policy.html). > > I think JSON should allow characters from (1) and (2) to avoid being > dependent on a specific Unicode revision. I do not think (3) should be > allowed - this would cause problems with many existing parsers which > represent JSON strings using another system's native unicode > representation. > > The argument about testsuites does not seem compelling, as any such > testsuite testing behaviour of string functions with bad Unicode would > also include invalidly-encoded Unicode (such as overlong UTF8 > sequences) which cannot be represented at all in JSON, even with > escaping. > > Stephen > > On Fri, Jun 7, 2013 at 4:56 PM, Paul Hoffman > wrote: > > > > > > This may be a part of the spec where some people have to hold their > noses. The Unicode definition of "character" does not include > non-characters, and the code points for some of those non-characters make > sense in JSON strings when those strings. Bjoern has pointed out a good > one: strings used for test cases of other code. The issue not just unpaired > surrogates. Do we *really* want to prohibit: > > { "End of data marker": "\uFFFF" } > > > > Proposal: > > > > Remove the word "character" from the spec except in an explanatory > paragraph in Section 2.5 that says: > > All code points, even those that represent non-characters in the > Unicode specification [UNICODE], are allowed in JSON strings. > > > > --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 > --047d7b673dbac163bc04de92c6d8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I agree 100% with Stephen Dolan.=C2=A0 -T

On Fri, Jun 7, 2013 at 9:09 AM= , Stephen Dolan <stephen.dolan@cl.cam.ac.uk> wrote:=
I think it is useful to distinguish three ca= ses of codepoint:
=C2=A0(1) Those which are valid characters in a particular Unicode revision=
=C2=A0(2) Those which are unallocated codepoints which may become valid
characters in a later Unicode revision
=C2=A0(3) The noncharacter codepoints which will never be valid

(3) includes such beasts as U+FFFE (which you can only get by reading
a UTF16 byte order mark with the wrong byte order). The set (1)
increases with every Unicode revision to include characters from (2),
but (3) is stable (see
http://unicode.org/policies/stability_policy.html).

I think JSON should allow characters from (1) and (2) to avoid being
dependent on a specific Unicode revision. I do not think (3) should be
allowed - this would cause problems with many existing parsers which
represent JSON strings using another system's native unicode
representation.

The argument about testsuites does not seem compelling, as any such
testsuite testing behaviour of string functions with bad Unicode would
also include invalidly-encoded Unicode (such as overlong UTF8
sequences) which cannot be represented at all in JSON, even with
escaping.

Stephen

On Fri, Jun 7, 2013 at 4:56 PM, Paul Hoffman <paul.hoffman@vpnc.org> wrote:
> <no hat>
>
> This may be a part of the spec where some people have to hold their no= ses. The Unicode definition of "character" does not include non-c= haracters, and the code points for some of those non-characters make sense = in JSON strings when those strings. Bjoern has pointed out a good one: stri= ngs used for test cases of other code. The issue not just unpaired surrogat= es. Do we *really* want to prohibit:
> =C2=A0 =C2=A0{ "End of data marker": "\uFFFF" } >
> Proposal:
>
> Remove the word "character" from the spec except in an expla= natory paragraph in Section 2.5 that says:
> =C2=A0 =C2=A0All code points, even those that represent non-characters= in the Unicode specification [UNICODE], are allowed in JSON strings.
>
> --Paul Hoffman
> _______________________________________________
> json mailing list
> json@ietf.org
> https://www.ietf.org/mailman/listinfo/json
_______________________________________________
json mailing list
json@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/json

--047d7b673dbac163bc04de92c6d8-- From stefan@drees.name Fri Jun 7 09:18:53 2013 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 895B821F871D for ; Fri, 7 Jun 2013 09:18:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.195 X-Spam-Level: X-Spam-Status: No, score=-2.195 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fHepld2fpaSr for ; Fri, 7 Jun 2013 09:18:49 -0700 (PDT) Received: from mout.web.de (mout.web.de [212.227.15.3]) by ietfa.amsl.com (Postfix) with ESMTP id 9FB2121F86D5 for ; Fri, 7 Jun 2013 09:18:48 -0700 (PDT) Received: from newyork.local.box ([93.129.186.5]) by smtp.web.de (mrweb101) with ESMTPSA (Nemesis) id 0LoYjO-1U9CaP2TLW-00gUVG; Fri, 07 Jun 2013 18:18:44 +0200 Message-ID: <51B207E2.1060403@drees.name> Date: Fri, 07 Jun 2013 18:18:42 +0200 From: Stefan Drees User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: stefan@drees.name References: <51B06F38.8050707@crockford.com> <51B1B4E7.8090101@it.aoyama.ac.jp> <9ld3r8pc0tufif18dohb2fmi0ijna1vs4n@hive.bjoern.hoehrmann.de> <56A163E9-E7CD-46B3-9984-8F009EBFF500@vpnc.org> <51B20731.3040300@drees.name> In-Reply-To: <51B20731.3040300@drees.name> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:NeFeWfSjLdgEBgkjiHeOFbv1E5Smcx6yj64T9kkpCsXKVt22eDd tzv6Y30hv2NPHk2MAyzxwXSv+7SslToMHwB1TuqyXeOwZ3dbbl7ejB+DUxe1xonb11wSBS8 EWE/pugtjTiybhkazbBydUhgTj9krvJRS+w/lk+uSy2NcCLatGNVgBbbOoHqJCZuIkiuQ5p NsnWiLaMWHb0L3sWQ1g1w== Cc: Tim Bray , Paul Hoffman , "json@ietf.org" Subject: Re: [Json] On characters and code points X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stefan@drees.name List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2013 16:18:53 -0000 Sorry, did miss one slash in my text, whci should irritate the reader. c.f. below. Am 07.06.13 18:15, schrieb Stefan Drees: > On 2013-06-07 18:01, Tim Bray wrote: >> On Fri, Jun 7, 2013 at 8:56 AM, Paul Hoffman ... wrote: >> >> This may be a part of the spec where some people have to hold their >> noses. The Unicode definition of "character" does not include >> non-characters, and the code points for some of those non-characters >> make sense in JSON strings when those strings. Bjoern has pointed >> out a good one: strings used for test cases of other code. The issue >> not just unpaired surrogates. Do we *really* want to prohibit: >> { "End of data marker": "\uFFFF" } >> >> >> Yes, I *really* want to prohibit that. The one corner case it buys you >> is outweighed by a factor of a thousand or so in not being able to use >> general-purpose string processing software to deal with JSON payloads. >> BTW, a huge amount of deployed software out there ALREADY processes JSON >> text fields using general-purpose string processing libraries, and will >> explode unpredictably and in hard-to-debug ways if this starts happening. > > and what about { "Decorate my slash": "\/" } and "general-purpose string > processing software". Isn't this also a case, where you need a > "pre-conditioner" that replaces the JSON specific escape sequence "\" above lines should of course read: "pre-conditioner" that replaces the JSON specific escape sequence "\/" > with "/" before feeding it into "general-purpose string processing > software" :-?) > > >> Also, consider the lovely consequences when unpaired surrogates start >> showing up in key fields and are fed to hash functions in every >> programming language in the world, which expect to receive Unicode >> characters. >> -T >> > > For today I better not imagine all these laguages and implementations > blindly stuffing some json text transformed into their own memory > structures ... maybe later during the weekend > > >> ... > > Stefan. > > > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json From tbray@textuality.com Fri Jun 7 09:19:48 2013 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 7B00E21F95DD for ; Fri, 7 Jun 2013 09:19:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.157 X-Spam-Level: X-Spam-Status: No, score=-1.157 tagged_above=-999 required=5 tests=[AWL=1.819, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w6yQvoT1vDUN for ; Fri, 7 Jun 2013 09:19:42 -0700 (PDT) Received: from mail-vc0-f182.google.com (mail-vc0-f182.google.com [209.85.220.182]) by ietfa.amsl.com (Postfix) with ESMTP id 825DA21F9302 for ; Fri, 7 Jun 2013 09:19:42 -0700 (PDT) Received: by mail-vc0-f182.google.com with SMTP id gf12so2925564vcb.13 for ; Fri, 07 Jun 2013 09:19:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=/OO3t5nEI9BvHDUl9ESGAmOYDFEi5592QMfCRY0V/qQ=; b=dOq1/1VanzcX3KcPWtgYxI5jhrYmVEKfV9x6DaeKVQ6We4FCrooNtrjSqBElvgxgtW eZiRgntBg8RRUvnuS3DUFHlBUpT1MH+0aTzb7hUKjQqfPz4U6Ng7TmaZsIRhHNbog4QD BxLtWm9KnkzfZu2yovpnZpeKl/UvhH5FwhjFZ2qa2FPo0aS8UkAiB/N1KTSH8rOaLzYb 2DyHyFU29WwZVwvfsYxQQQLa6pAAqFW9SBCxhbKnNgLbzqJYcxORo7wAm9ccNQUHvehF towo+ySihcORbXyTa069nl/al65YXSH72ydRqstBS2+MS4hTemswk8rgUqcjOFGm+/h8 ejUA== MIME-Version: 1.0 X-Received: by 10.58.88.4 with SMTP id bc4mr1186105veb.48.1370621981869; Fri, 07 Jun 2013 09:19:41 -0700 (PDT) Received: by 10.220.48.14 with HTTP; Fri, 7 Jun 2013 09:19:41 -0700 (PDT) X-Originating-IP: [24.84.235.32] In-Reply-To: <51B20731.3040300@drees.name> References: <51B06F38.8050707@crockford.com> <51B1B4E7.8090101@it.aoyama.ac.jp> <9ld3r8pc0tufif18dohb2fmi0ijna1vs4n@hive.bjoern.hoehrmann.de> <56A163E9-E7CD-46B3-9984-8F009EBFF500@vpnc.org> <51B20731.3040300@drees.name> Date: Fri, 7 Jun 2013 09:19:41 -0700 Message-ID: From: Tim Bray To: stefan@drees.name Content-Type: multipart/alternative; boundary=047d7b33920759e2bd04de92cca2 X-Gm-Message-State: ALoCoQkzzxN0pnWzZSU6xKxPcNhPmHEpCWb7GKO9Nn02M87SxfKqpugUTwh7C0dkpixLgmzNBrcp Cc: Paul Hoffman , "json@ietf.org" Subject: Re: [Json] On characters and code points X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 07 Jun 2013 16:19:48 -0000 --047d7b33920759e2bd04de92cca2 Content-Type: text/plain; charset=UTF-8 On Fri, Jun 7, 2013 at 9:15 AM, Stefan Drees wrote: > and what about { "Decorate my slash": "\/" } and "general-purpose string > processing software". Isn't this also a case, where you need a > "pre-conditioner" that replaces the JSON specific escape sequence "\" with > "/" before feeding it into "general-purpose string processing software" :-?) Red herring. JSON, just like XML, has ways to encode characters that are hard to type. What we're arguing about is the actual content of the payload after the parser/pre-conditioner. -T > > > > Also, consider the lovely consequences when unpaired surrogates start >> showing up in key fields and are fed to hash functions in every >> programming language in the world, which expect to receive Unicode >> characters. >> -T >> >> > For today I better not imagine all these laguages and implementations > blindly stuffing some json text transformed into their own memory > structures ... maybe later during the weekend > > > ... >> > > Stefan. > > > > --047d7b33920759e2bd04de92cca2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Fri, Jun 7, 2013 at 9:15 AM, Stefan Drees <stefan@dree= s.name> wrote:
and what about { "Decorate my slash&quo= t;: "\/" } and "general-purpose string processing software&q= uot;. Isn't this also a case, where you need a "pre-conditioner&qu= ot; that replaces the JSON specific escape sequence "\" with &quo= t;/" before feeding it into "general-purpose string processing so= ftware" :-?)

Red herring.=C2=A0 JSON, just like XML, has ways to enc= ode characters that are hard to type.=C2=A0 What we're arguing about is= the actual content of the payload after the parser/pre-conditioner.=C2=A0 = -T
=C2=A0



Also, consider the lovely consequences when unpaired surrogates start
showing =C2=A0up in key fields and are fed to hash functions in every
programming language in the world, which expect to receive Unicode
characters.
=C2=A0 -T


For today I better not imagine all these laguages and implementations blind= ly stuffing some json text transformed into their own memory structures ...= maybe later during the weekend


=C2=A0 =C2=A0 ...

Stefan.




--047d7b33920759e2bd04de92cca2-- From mamille2@cisco.com Fri Jun 7 09:22:40 2013 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 5410921F8EBC for ; Fri, 7 Jun 2013 09:22:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VWUFt0ygpFJN for ; Fri, 7 Jun 2013 09:22:19 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 3CF0421F8717 for ; Fri, 7 Jun 2013 09:22:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7166; q=dns/txt; s=iport; t=1370622139; x=1371831739; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=RYHWaj3DDZP8QhotP6N3ZzPfcbfHpBCuM+VNdv6yS2Y=; b=QbIcIAsUnBgOIZSUt6I3qEBZZ0uJ+BOPuDFpt8vEuaKJxNT0SEdocQ1A sygRBTOfDqV9fKI11mBKxczpxQ/qEl01KXvIQPA66mKlSDPu6rnewzc6r p+IQlgvm1Pjeq5WDSEs8EAkwEqxG1nHYNeGI9LIbFFenAIXTBtOvOCgFx 4=; X-Files: smime.p7s : 4136 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhEFAMgHslGtJV2Z/2dsb2JhbABZgwm/IH8WdIIjAQEBBHkFCwIBCA4KCiQCMCUBAQQOBQgGh20DD7QoHYhCjwcxB4J7YQOQAYEsgkGVFIMPgic X-IronPort-AV: E=Sophos;i="4.87,823,1363132800"; d="p7s'?scan'208";a="220114306" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-5.cisco.com with ESMTP; 07 Jun 2013 16:22:18 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r57GMIMC030461 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 7 Jun 2013 16:22:18 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.24]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.02.0318.004; Fri, 7 Jun 2013 11:22:18 -0500 From: "Matt Miller (mamille2)" To: Tim Bray Thread-Topic: [Json] Allow any JSON value at the top level Thread-Index: Ac5jMj7wK5i9s5prS+2npykXIGILbgAj1hwAAADfq4A= Date: Fri, 7 Jun 2013 16:22:17 +0000 Message-ID: References: <255B9BB34FB7D647A506DC292726F6E1151B21F9A9@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.129.24.59] Content-Type: multipart/signed; boundary="Apple-Mail=_B52A1494-2A27-4DDF-BADF-B6FA25B54C98"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Cc: "Manger, James H" , "json@ietf.org" Subject: Re: [Json] Allow any JSON value at the top level X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 07 Jun 2013 16:22:40 -0000 --Apple-Mail=_B52A1494-2A27-4DDF-BADF-B6FA25B54C98 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jun 7, 2013, at 9:57 AM, Tim Bray wrote: > On Thu, Jun 6, 2013 at 8:51 PM, Manger, James H < > James.H.Manger@team.telstra.com> wrote: >=20 >> The current spec only allows a JSON text to be an object or array. = Section >> 2. "JSON Grammar" says: >>=20 > ... >=20 >> I propose allowing a JSON text to be any JSON value. >>=20 >=20 > -1. >=20 > 1. Our mandate is not to enhance or improve JSON. > 2. This is a bad idea in general and a terrible idea for network = protocols, > which is where JSON is most valuable. >=20 > -T >=20 >=20 /me doffs hat This is one area where I think we need experimentation before we can = consider such as change. It very well could be that "everyone" (for = some definition of everyone) has ignored this particular restriction in = order to maximize compatibility with ECMAScript, in which case = maintaining this condition means everyone is technically non-compliant. However, I don't know that with any degree of certainty. - m&m Matt Miller < mamille2@cisco.com > Cisco Systems, Inc. --Apple-Mail=_B52A1494-2A27-4DDF-BADF-B6FA25B54C98 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMezCCBjQw ggQcoAMCAQICAR4wDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDE1NVoX DTE3MTAyNDIxMDE1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMcJg8zOLdgasSmkLhOrlr6KMoOMpohBllVHrdRvEg/q6r8jR+EK 75xCGhR8ToREoqe7zM9/UnC6TS2y9UKTpT1v7RSMzR0t6ndl0TWBuUr/UXBhPk+Kmy7bI4yW4urC +y7P3/1/X7U8ocb8VpH/Clt+4iq7nirMcNh6qJR+xjOhV+VHzQMALuGYn5KZmc1NbJQYclsGkDxD z2UbFqE2+6vIZoL+jb9x4Pa5gNf1TwSDkOkikZB1xtB4ZqtXThaABSONdfmv/Z1pua3FYxnCFmdr /+N2JLKutIxMYqQOJebr/f/h5t95m4JgrM3Y/w7YX9d7YAL9jvN4SydHsU6n65cCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRTcu2SnODaywFc fH6WNU7y1LhRgjAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBAAqDCH14qywG XLhjjF6uHLkjd02hcdh9hrw+VUsv+q1eeQWB21jWj3kJ96AUlPCoEGZ/ynJNScWy6QMVQjbbMXlt UfO4n4bGGdKo3awPWp61tjAFgraLJgDk+DsSvUD6EowjMTNx25GQgyYJ5RPIzKKR9tQW8gGK+2+R HxkUCTbYFnL6kl8Ch507rUdPPipJ9CgJFws3kDS3gOS5WFMxcjO5DwKfKSETEPrHh7p5shuuNktv sv6hxHTLhiMKX893gxdT3XLS9OKmCv87vkINQcNEcIIoFWbP9HORz9v3vQwR4e3ksLc2JZOAFK+s sS5XMEoznzpihEP0PLc4dCBYjbvSD7kxgDwZ+Aj8Q9PkbvE9sIPP7ON0fz095HdThKjiVJe6vofq +n6b1NBc8XdrQvBmunwxD5nvtTW4vtN6VY7mUCmxsCieuoBJ9OlqmsVWQvifIYf40dJPZkk9YgGT zWLpXDSfLSplbY2LL9C9U0ptvjcDjefLTvqSFc7tw1sEhF0n/qpA2r0GpvkLRDmcSwVyPvmjFBGq Up/pNy8ZuPGQmHwFi2/14+xeSUDG2bwnsYJQG2EdJCB6luQ57GEnTA/yKZSTKI8dDQa8Sd3zfXb1 9mOgSF0bBdXbuKhEpuP9wirslFe6fQ1t5j5R0xi72MZ8ikMu1RQZKCyDbMwazlHiMIIGPzCCBSeg AwIBAgIDBoRIMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcN MTMwNDMwMjE1NDQyWhcNMTQwNTAyMDUzOTA0WjBbMRkwFwYDVQQNExBiN2F6NndOY0t0R3JtMEpF MRswGQYDVQQDDBJtYW1pbGxlMkBjaXNjby5jb20xITAfBgkqhkiG9w0BCQEWEm1hbWlsbGUyQGNp c2NvLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJbKBMsG+9UFTx9uq/bhhXgu vJvO8z7cwKaqqwZhVf5z/kHFyCNijtmTOE+YXjA8mWR4aoBwB5SvGypI/cJUofJ+AlBTC4g+RMx/ K0Ab4/jQqTQz9CDzMOB+Wm+rt8ZJ7A8ZzOJmNDAsf/VvB8l2A1SQz1UsAixgH16NTr8SlblAXEKk 4hwpCudUiNjjQokqJ0H686UBKVorcZSgXaza8XMqGtJF/8mNhR9GQYi7Xht1ky+9LFOrto2daZto KJRwMeVusVdHUeKEQSu7jztw8HchH3KEb7Q+r5X+hhDZoddfKE8d5eyPuhiZdrzv7OlNZ0fSLdx7 3AE3nx9/R5YlXucCAwEAAaOCAtgwggLUMAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQW MBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQUxGd+/qrdVudHrIKkw5xOMY7eaLUwHwYD VR0jBBgwFoAUU3Ltkpzg2ssBXHx+ljVO8tS4UYIwHQYDVR0RBBYwFIESbWFtaWxsZTJAY2lzY28u Y29tMIIBTAYDVR0gBIIBQzCCAT8wggE7BgsrBgEEAYG1NwECAzCCASowLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0 Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBp c3N1ZWQgYWNjb3JkaW5nIHRvIHRoZSBDbGFzcyAxIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9m IHRoZSBTdGFydENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBw dXJwb3NlIGluIGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMDYG A1UdHwQvMC0wK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUxLWNybC5jcmwwgY4G CCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIv Y2xhc3MxL2NsaWVudC9jYTBCBggrBgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2Vy dHMvc3ViLmNsYXNzMS5jbGllbnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRz c2wuY29tLzANBgkqhkiG9w0BAQUFAAOCAQEAlDhXbGEI7lbqUcu5r2JHZaMsbRZda/99ZqODzWGX 0llou9jGccsAWDPPwRRe2+ROpXfH4cuJZElTcLDeZSp/qpXKhjYieFSX8+Ml9sKEj5UOSqQLyoLk PtrIJV12Jk3nuG2Jc0UeEnGwK/aqtzy7+bfEVI0ziyVM2gChHh0RH74KyiwYWknbOTRIkZcz/ulE DVFQp63uj6wfmDNvAUHBAdhKVqA1S/rfP1KcDZpf1NfvwXJibiqTRA6K1EOxTJOP41n/XdvHqHXL RWL2xrOUI9/URANr/ok3OrsuZEMFnAAGefS1bWS/hFtUGVkHGiKEBbyDW7da2ULXbuC7umrQnzGC A28wggNrAgEBMIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkG A1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwaESDAJBgUrDgMCGgUA oIIBrzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMzA2MDcxNjIy MTdaMCMGCSqGSIb3DQEJBDEWBBSskqkiXpU3hzd2fDm2bh18t8K1VjCBpQYJKwYBBAGCNxAEMYGX MIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3Mg MSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwaESDCBpwYLKoZIhvcNAQkQAgsxgZeg gZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1 cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAx IFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDBoRIMA0GCSqGSIb3DQEBAQUABIIBAESM tYCHFAZGeHnP8VM6yx+FIcgXuhukjZn5ndw6c1tPbw6R4SpN/r+CQY9j1WAscyMJX3yL6rzMmydi cUkdOyYqSYIqAJpG2Jzs4yvjWJLjxqVz5HtDYbjLwUDa2kZsUjJCkRha+DqoF/8fOfmOhg80J9MY kahZrsqy+P6etzj1rbRfF4UvjvoTwc5vnSGRkBbEskrPPpZq7yx0eB+vj3rqluV6RRm6QZHW/Ruu XVk5nacDIFinP34yn+MOG6CmO3lzbppx9hScD8zLAtb+ZA8G8lPgm8CbGomC7Hv+Tcp4It36RmSB i0fg6fjTYLRSiuysF11MHYZNpKQah0ZJZ3AAAAAAAAA= --Apple-Mail=_B52A1494-2A27-4DDF-BADF-B6FA25B54C98-- From petejson@codalogic.com Fri Jun 7 09:31:15 2013 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 263A521F9298 for ; Fri, 7 Jun 2013 09:31:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.668 X-Spam-Level: * X-Spam-Status: No, score=1.668 tagged_above=-999 required=5 tests=[BAYES_50=0.001, SARE_HEAD_XUNSENT=1.666, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d7hde6RSy+DD for ; Fri, 7 Jun 2013 09:31:10 -0700 (PDT) Received: from codalogic.com (codalogic.com [94.136.60.219]) by ietfa.amsl.com (Postfix) with ESMTP id E778D21F925A for ; Fri, 7 Jun 2013 09:31:09 -0700 (PDT) Received: (qmail 20167 invoked from network); 7 Jun 2013 17:31:07 +0100 Received: from host86-169-212-62.range86-169.btcentralplus.com (HELO codalogic) (86.169.212.62) by codalogic.com with (RC4-MD5 encrypted) SMTP; 7 Jun 2013 17:31:07 +0100 Message-ID: <641B1C79FB414811BCBDE8BE0FD165D6@codalogic> From: "Pete Cordell" To: X-Unsent: 1 Date: Fri, 7 Jun 2013 17:31:09 +0100 x-vipre-scanned: 02331E2400484A02331F71 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Subject: [Json] Comments by convention X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 07 Jun 2013 16:31:15 -0000 I along with many wish JSON included comments. Since they can't retrospectively be added, what are the prospects of documenting a convention for including comments in a JSON message? For example, something along the lines of: 2.6 Comments JSON has no native ability to represent comments. Instead, by convention, unless overridden by a protocol definition, comments can be represented by name/value pairs (a.k.a. members) with string values of the form: "//": "This is a comment" Comments can be associated with a particular member within an object using a comment name of the form "// foo" where "foo" is the name of the member to which the comment applies. For example: "order": { "//": "An order item", "// description": "A short description of the item ordered", "description": "1TB HDD", "// price": "The price in USD", "price": 123.45 } How much goes up in smoke if we do that? Pete Cordell Codalogic Ltd C++ tools for C++ programmers, http://codalogic.com Read & write XML in C++, http://www.xml2cpp.com From allen@wirfs-brock.com Thu Jun 6 08:42:44 2013 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 009ED21F971F for ; Thu, 6 Jun 2013 08:42:44 -0700 (PDT) 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=[AWL=-0.601, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_35=0.6, J_CHICKENPOX_45=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id quPK7wM8keJZ for ; Thu, 6 Jun 2013 08:42:38 -0700 (PDT) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) by ietfa.amsl.com (Postfix) with ESMTP id 1F1ED21F9193 for ; Thu, 6 Jun 2013 08:42:38 -0700 (PDT) Received: from 069-064-236-244.pdx.net ([69.64.236.244] helo=[192.168.0.15]) by mho-01-ewr.mailhop.org with esmtpa (Exim 4.72) (envelope-from ) id 1UkcKj-000BTE-71; Thu, 06 Jun 2013 15:42:37 +0000 X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 69.64.236.244 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18V3HjE0XNTMD+CwDySo9QNSyZKLEueGW8= Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: multipart/alternative; boundary=Apple-Mail-42--763355924 From: Allen Wirfs-Brock In-Reply-To: Date: Thu, 6 Jun 2013 08:42:31 -0700 Message-Id: <60141305-DCEA-4EC6-9CDF-82B52B13AE91@wirfs-brock.com> References: <51AF8479.5080002@crockford.com> <51AF9ACF.5020507@cisco.com> <51AFB3F8.8060708@crockford.com> <8F32953C-C788-4DC9-888E-920E2BEB7FDD@yahoo.com> <831B8E46-F239-4353-8F95-8DF3F9BD2E78@yahoo.com> <51AFC924.2030805@crockford.com> To: Paul Hoffman X-Mailer: Apple Mail (2.1085) Cc: "json@ietf.org" Subject: Re: [Json] The names within an object SHOULD be unique. X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 07 Jun 2013 16:36:58 -0000 --Apple-Mail-42--763355924 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Just got signed on to this list... There is also a discussion of this topic going on at = es-discuss@mozilla.org which I'm trying to redirect here. My recommendation from the es-disuss thread is below. Allen Wirfs-Brock ECMAScript Language Spec. Project Editor On Jun 6, 2013, at 8:24 AM, Paul Hoffman wrote: > On Jun 5, 2013, at 4:26 PM, Douglas Crockford = wrote: >=20 >> If duplicate names are encountered, the parse MAY fail (because some = implementations correctly do that), or it MAY succeed by accepting the = last duplicated key:value pair. >=20 > The new text should use language that is already in RFC 4627; "key" is = not such a word. To be fair to implementers, the new document also needs = to deal with both emitters and parsers. >=20 > Proposal: >=20 > In Section 2.2: > Current: > The names within an object SHOULD be unique. > Proposed: > If the names within an object are not unique, the result of parsing = the=20 > object is unpredictable, and the parse may even fail completely. = Thus, > the names within an object SHOULD be unique. >=20 > In Section 4, add a new paragraph: > If a parser encounters an object with duplicate names, the parser = MAY > fail to parse the JSON text; if the parser accepts objects with = duplicate > names, it SHOULD accept only the last name/value pair that has the > duplicate name.=20 >=20 > --Paul Hoffman Some that should be pointed out is that one reason JSON needs to accept = duplicate field names is that some people currently use them to add = comments to JSON datasets: { "//": "This is a comment about my data", "//": "that takes more than one line", "field1" : 1, "field2" : 2 } The above is valid according to the existing RFC and is accepted as = valid JSON by the existing ECMAScript JSON.parse spec. We don't want to = invalid existing JSON datasets that use this technique so duplicate keys = MUST be accepted. What I would say, as a replacement for the current text
= is: The names within an object SHOULD be unique. If a key is = duplicated, a parser MUST take <> only the last of = the duplicated key pairs. I would be willing to loose the first sentence (containing the SHOULD) = entirely as it doesn't add any real normative value. Given that duplicate names have historically been valid, that some = people use them, and that the standard ECMAScript JSON parser accepts = them I don't see why allowing a parser to reject duplicate names is = helpful. --Apple-Mail-42--763355924 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii es-discuss@mozilla.org whi= ch I'm trying to redirect here.

My recommendation = from the es-disuss thread is below.

Allen = Wirfs-Brock
ECMAScript Language Spec. Project = Editor


On Jun 6, 2013, at 8:24 AM, = Paul Hoffman wrote:

On = Jun 5, 2013, at 4:26 PM, Douglas Crockford <douglas@crockford.com> = wrote:

If duplicate names are = encountered, the parse MAY fail (because some implementations correctly = do that), or it MAY succeed by accepting the last duplicated key:value = pair.

The new text should use language that is = already in RFC 4627; "key" is not such a word. To be fair to = implementers, the new document also needs to deal with both emitters and = parsers.

Proposal:

In Section 2.2:
Current:
=   The names within an object SHOULD be = unique.
Proposed:
  If the names within an object are = not unique, the result of parsing the
  object is = unpredictable, and the parse may even fail completely. Thus,
=   the names within an object SHOULD be unique.

In = Section 4, add a new paragraph:
  If a parser encounters = an object with duplicate names, the parser MAY
  fail to = parse the JSON text; if the parser accepts objects with duplicate
=   names, it SHOULD accept only the last name/value pair that = has the
  duplicate name.

--Paul = Hoffman

Some that should be pointed = out is that one reason JSON needs to accept duplicate field names is = that some people currently use them to add  comments to JSON = datasets:

{
"//": "This is a comment about my data",
"//": =  "that takes more than one line",
"field1" : 1,
"field2" : = 2
}

The above is valid according to the existing RFC and is = accepted as valid JSON by the existing ECMAScript  JSON.parse = spec. We don't want to invalid existing JSON datasets that use this = technique so duplicate keys MUST be accepted.

What I would = say, as a replacement for the current text  <section 2.2> = is:

         The = names within an object SHOULD be unique.  If a key is duplicated, a = parser MUST take  <<use?? interpret??>> only the last = of the duplicated key pairs.

I would be willing to loose the = first sentence (containing the SHOULD) entirely as it doesn't add any = real normative value.

Given that duplicate = names have historically been valid, that some people use them, and that = the standard ECMAScript JSON parser accepts them I don't see why = allowing a parser to reject duplicate names is = helpful.



= --Apple-Mail-42--763355924-- From allen@wirfs-brock.com Thu Jun 6 12:51:52 2013 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 5E35811E80F2 for ; Thu, 6 Jun 2013 12:51:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.25 X-Spam-Level: X-Spam-Status: No, score=-2.25 tagged_above=-999 required=5 tests=[AWL=0.426, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5fg70Qaw+YBW for ; Thu, 6 Jun 2013 12:51:46 -0700 (PDT) Received: from smtp.mozilla.org (mx2.corp.phx1.mozilla.com [63.245.216.70]) by ietfa.amsl.com (Postfix) with ESMTP id 8AAE321E80B0 for ; Thu, 6 Jun 2013 12:51:46 -0700 (PDT) Received: from [192.168.0.15] (069-064-236-244.pdx.net [69.64.236.244]) (Authenticated sender: allenwb@mozilla.com) by mx2.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id BE67DF217C; Thu, 6 Jun 2013 12:51:45 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: multipart/alternative; boundary=Apple-Mail-44--748406316 From: Allen Wirfs-Brock In-Reply-To: Date: Thu, 6 Jun 2013 12:51:41 -0700 Message-Id: References: To: Matt Miller (mamille2) X-Mailer: Apple Mail (2.1085) Cc: Paul Hoffman , "json@ietf.org" Subject: Re: [Json] Call for real-world examples of how parsers deal with duplicate keys X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 07 Jun 2013 16:36:59 -0000 --Apple-Mail-44--748406316 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jun 6, 2013, at 11:05 AM, Matt Miller (mamille2) wrote: > On Jun 6, 2013, at 11:41 AM, Paul Hoffman > wrote: >=20 >=20 >=20 > Experiments should always have a control! I think we can consider = this the control: >=20 > -----BEGIN JAVASCRIPT----- > var input =3D '{"a":1,"a":2}'; >=20 > var output; > output =3D JSON.parse(input); > output =3D JSON.stringify(output); >=20 > console.log(output); > -----END JAVASCRIPT----- >=20 > # node.js 0.10.8 > {"a":2} >=20 > # Firefox 22 > {"a":2} >=20 > # Safari 6.5 > {"a":2} >=20 > # Chrome 27 > {"a":2} >=20 The ECMAScript standard requires the behavior shown above. Allen= --Apple-Mail-44--748406316 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On Jun 6, 2013, at 11:41 AM, Paul Hoffman <paul.hoffman@vpnc.org>
= wrote:



Experiments should always have a = control!  I think we can consider this the = control:

-----BEGIN JAVASCRIPT-----
var input =3D = '{"a":1,"a":2}';

var output;
output =3D = JSON.parse(input);
output =3D = JSON.stringify(output);

console.log(output);
-----END = JAVASCRIPT-----

# node.js 0.10.8
{"a":2}

# Firefox = 22
{"a":2}

# Safari 6.5
{"a":2}

# Chrome = 27
{"a":2}


The ECMAScript = standard requires the behavior shown = above.

Allen
= --Apple-Mail-44--748406316-- From allen@wirfs-brock.com Thu Jun 6 10:45:13 2013 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 6F9FE21F9A78 for ; Thu, 6 Jun 2013 10:45:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.737 X-Spam-Level: X-Spam-Status: No, score=-1.737 tagged_above=-999 required=5 tests=[AWL=-0.261, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, HTML_MESSAGE=0.001, J_CHICKENPOX_35=0.6, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WXzhkqUgwy1J for ; Thu, 6 Jun 2013 10:45:07 -0700 (PDT) Received: from smtp.mozilla.org (mx2.corp.phx1.mozilla.com [63.245.216.70]) by ietfa.amsl.com (Postfix) with ESMTP id A490F21F99C7 for ; Thu, 6 Jun 2013 10:45:07 -0700 (PDT) Received: from [192.168.0.15] (069-064-236-244.pdx.net [69.64.236.244]) (Authenticated sender: allenwb@mozilla.com) by mx2.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id B35D6F20CA; Thu, 6 Jun 2013 10:45:06 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: multipart/alternative; boundary=Apple-Mail-43--756005511 From: Allen Wirfs-Brock In-Reply-To: Date: Thu, 6 Jun 2013 10:45:01 -0700 Message-Id: References: <51AF8479.5080002@crockford.com> <51AF9ACF.5020507@cisco.com> <51AFB3F8.8060708@crockford.com> <8F32953C-C788-4DC9-888E-920E2BEB7FDD@yahoo.com> <831B8E46-F239-4353-8F95-8DF3F9BD2E78@yahoo.com> <51AFC924.2030805@crockford.com> To: json@ietf.org X-Mailer: Apple Mail (2.1085) Cc: Paul Hoffman Subject: Re: [Json] The names within an object SHOULD be unique. X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 07 Jun 2013 16:36:59 -0000 --Apple-Mail-43--756005511 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Just got signed on to this list... (and this message didn't seem to make it there the first time, so sorry = if this is duplicated) There is also a discussion of this topic going on at = es-discuss@mozilla.org which I'm trying to redirect here. My recommendation from the es-disuss thread is below. Allen Wirfs-Brock ECMAScript Language Spec. Project Editor On Jun 6, 2013, at 8:24 AM, Paul Hoffman wrote: > On Jun 5, 2013, at 4:26 PM, Douglas Crockford = wrote: >=20 >> If duplicate names are encountered, the parse MAY fail (because some = implementations correctly do that), or it MAY succeed by accepting the = last duplicated key:value pair. >=20 > The new text should use language that is already in RFC 4627; "key" is = not such a word. To be fair to implementers, the new document also needs = to deal with both emitters and parsers. >=20 > Proposal: >=20 > In Section 2.2: > Current: > The names within an object SHOULD be unique. > Proposed: > If the names within an object are not unique, the result of parsing = the=20 > object is unpredictable, and the parse may even fail completely. = Thus, > the names within an object SHOULD be unique. >=20 > In Section 4, add a new paragraph: > If a parser encounters an object with duplicate names, the parser = MAY > fail to parse the JSON text; if the parser accepts objects with = duplicate > names, it SHOULD accept only the last name/value pair that has the > duplicate name.=20 >=20 > --Paul Hoffman Some that should be pointed out is that one reason JSON needs to accept = duplicate field names is that some people currently use them to add = comments to JSON datasets: { "//": "This is a comment about my data", "//": "that takes more than one line", "field1" : 1, "field2" : 2 } The above is valid according to the existing RFC and is accepted as = valid JSON by the existing ECMAScript JSON.parse spec. We don't want to = invalid existing JSON datasets that use this technique so duplicate keys = MUST be accepted. What I would say, as a replacement for the current text
= is: The names within an object SHOULD be unique. If a key is = duplicated, a parser MUST take <> only the last of = the duplicated key pairs. I would be willing to loose the first sentence (containing the SHOULD) = entirely as it doesn't add any real normative value. Given that duplicate names have historically been valid, that some = people use them, and that the standard ECMAScript JSON parser accepts = them I don't see why allowing a parser to reject duplicate names is = helpful. --Apple-Mail-43--756005511 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii es-discuss@mozilla.org whi= ch I'm trying to redirect here.

My recommendation = from the es-disuss thread is below.

Allen = Wirfs-Brock
ECMAScript Language Spec. Project = Editor


On Jun 6, 2013, at 8:24 AM, = Paul Hoffman wrote:

On = Jun 5, 2013, at 4:26 PM, Douglas Crockford <douglas@crockford.com> = wrote:

If duplicate names are = encountered, the parse MAY fail (because some implementations correctly = do that), or it MAY succeed by accepting the last duplicated key:value = pair.

The new text should use language that is = already in RFC 4627; "key" is not such a word. To be fair to = implementers, the new document also needs to deal with both emitters and = parsers.

Proposal:

In Section 2.2:
Current:
=   The names within an object SHOULD be = unique.
Proposed:
  If the names within an object are = not unique, the result of parsing the
  object is = unpredictable, and the parse may even fail completely. Thus,
=   the names within an object SHOULD be unique.

In = Section 4, add a new paragraph:
  If a parser encounters = an object with duplicate names, the parser MAY
  fail to = parse the JSON text; if the parser accepts objects with duplicate
=   names, it SHOULD accept only the last name/value pair that = has the
  duplicate name.

--Paul = Hoffman

Some that should be pointed = out is that one reason JSON needs to accept duplicate field names is = that some people currently use them to add  comments to JSON = datasets:

{
"//": "This is a comment about my data",
"//": =  "that takes more than one line",
"field1" : 1,
"field2" : = 2
}

The above is valid according to the existing RFC and is = accepted as valid JSON by the existing ECMAScript  JSON.parse = spec. We don't want to invalid existing JSON datasets that use this = technique so duplicate keys MUST be accepted.

What I would = say, as a replacement for the current text  <section 2.2> = is:

         The = names within an object SHOULD be unique.  If a key is duplicated, a = parser MUST take  <<use?? interpret??>> only the last = of the duplicated key pairs.

I would be willing to loose the = first sentence (containing the SHOULD) entirely as it doesn't add any = real normative value.

Given that duplicate = names have historically been valid, that some people use them, and that = the standard ECMAScript JSON parser accepts them I don't see why = allowing a parser to reject duplicate names is = helpful.



= --Apple-Mail-43--756005511-- From stefan@drees.name Fri Jun 7 09:37:08 2013 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 15E4921F9704 for ; Fri, 7 Jun 2013 09:37:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.199 X-Spam-Level: X-Spam-Status: No, score=-2.199 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zDJjAX+vSWkI for ; Fri, 7 Jun 2013 09:37:02 -0700 (PDT) Received: from mout.web.de (mout.web.de [212.227.17.11]) by ietfa.amsl.com (Postfix) with ESMTP id 69A1E21F88A9 for ; Fri, 7 Jun 2013 09:37:00 -0700 (PDT) Received: from newyork.local.box ([93.129.186.5]) by smtp.web.de (mrweb001) with ESMTPSA (Nemesis) id 0LkyXt-1UDIzx2pW9-00al5Y; Fri, 07 Jun 2013 18:36:53 +0200 Message-ID: <51B20C23.6080303@drees.name> Date: Fri, 07 Jun 2013 18:36:51 +0200 From: Stefan Drees User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Paul Hoffman References: <51B0E02E.4070209@crockford.com> <1BD0044B-D7A6-4C7F-899E-5D3E72C62956@vpnc.org> <51B116FE.9050406@crockford.com> <51B1885F.3080908@drees.name> <9D5D948B-BD1E-4195-9B05-3376D6EFFAEA@vpnc.org> In-Reply-To: <9D5D948B-BD1E-4195-9B05-3376D6EFFAEA@vpnc.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:gP+tyzfUhEUgudcSV0KYCT7OANEsRlvWiTkxGaFCMF0a0KFTJ08 VtuwE67Fi/qY52UuPlb8Rss722Te/TUlxF6EYAFHV69jW9085IJ6LBaRQsMzsb6EwKCxFY4 G5Hz/Dp5muivPTaaSS6PkieulZUIKvgR5Bj0mCVsWJivdgnw21E4zJ+32qxJz9wQn7hbgJN 4fqVqf/VjoNmhsNZnRA2Q== Cc: Douglas Crockford , "json@ietf.org" Subject: Re: [Json] Security Considerations X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stefan@drees.name List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2013 16:37:08 -0000 On 2013-06-07 17:58, Paul Hoffman wrote: > > On Jun 7, 2013, at 12:14 AM, Stefan Drees wrote: > >> On 07.06.13 01:10, Douglas Crockford wrote: >>> On 6/6/2013 4:04 PM, Paul Hoffman wrote: >>>> >>>> On Jun 6, 2013, at 12:17 PM, Douglas Crockford >>>> wrote: >>>> >>>>> Proposal: >>>>> >>>>> With any data format, it is important to encode correctly. Care must >>>>> be taken when constructing JSON texts by concatenation. For example: >>>>> >>>>> account = 4627; >>>>> comment = "\",\"account\":262"; // provided by attacker >>>>> json_text = "(\"account\":" + account + ",\"comment\":\"" + >>>>> comment + "\"}"; >>>> The example is language-specific and, due to the escaping, hard to read. >>> Which specific language would you say it is? Confusion attacks are often >>> hard to read. That is why they work. ... >> >> I propose to keep the example, but remove the need for quoting by switching to single quotes where needed: >> >> """ >> account = 4627; >> comment = '","account":262'; // provided by attacker >> json_text = '("account":' + account + ',"comment":"' + comment + '"}'; >> """ >> >> this is valid (Java|ECMA)Script, right and also much more readable, isn't it? > > I can live with this, but I think doing it in English wording is better. Proposal in English wording: replace OLD(++): """ With any data format, it is important to encode correctly. Care must be taken when constructing JSON texts by concatenation. For example: account = 4627; comment = '","account":262'; // provided by attacker json_text = '("account":' + account + ',"comment":"' + comment + '"}'; """ with: NEW: """ With any data format, it is important to encode correctly. Care must be taken when constructing JSON texts by concatenation in part from untrusted data, this data may inject a mix of structural characters and quotes, that changes the structure of the resulting JSON text. For example: When trying to compose an object like {"account": 4627, "comment": "foo"} from user input data for "foo", the attacking user might instead inject ","account":262,"comment":"hacked so that the resulting naively concatenated JSON text would become: {"account": 4627, "comment": "","account":262,"comment":"hacked"} """ What do you think? All the best, Stefan. From jhildebr@cisco.com Fri Jun 7 09:43:51 2013 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 CB3F821F96F2 for ; Fri, 7 Jun 2013 09:43:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3zZlaWaw-Q3A for ; Fri, 7 Jun 2013 09:43:43 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 9F8BC21F95EF for ; Fri, 7 Jun 2013 09:43:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1473; q=dns/txt; s=iport; t=1370623423; x=1371833023; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=bouo8B2mdbE4Jp2vfy1zkLcSfLZTwG+IuapTv5o3cHo=; b=gqqpU6niZehEqAcYcGSqz1bYJQ76SiVRWYDA4F81/pnTupUSZ0+IxKim DUmGSVBmn2fuO4jB7dGk1kBOc8sLsQUUs18StQ7RHnZlWdJSJJxfZo7hL 8QWs+vWQtXpQnMpzqxW0sttM6AMNI5m3zSS+fQiGNOoLqeaBh6tEuU/uN E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhIFALUMslGtJV2b/2dsb2JhbABZgwkwvm+BABZ0giUBBAEBAWsdAQgiSwslAQEEARIIh3MDDwy0HR2IQo8HOIJ7YQOpAoMPgic X-IronPort-AV: E=Sophos;i="4.87,823,1363132800"; d="scan'208";a="220126064" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-5.cisco.com with ESMTP; 07 Jun 2013 16:43:43 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r57Ghggc021773 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 7 Jun 2013 16:43:42 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.56]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.02.0318.004; Fri, 7 Jun 2013 11:43:42 -0500 From: "Joe Hildebrand (jhildebr)" To: "Manger, James H" , "json@ietf.org" Thread-Topic: [Json] Allow any JSON value at the top level Thread-Index: Ac5jMj7wK5i9s5prS+2npykXIGILbgAY4nWA Date: Fri, 7 Jun 2013 16:43:42 +0000 Message-ID: In-Reply-To: <255B9BB34FB7D647A506DC292726F6E1151B21F9A9@WSMSG3153V.srv.dir.telstra.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [64.101.72.72] Content-Type: text/plain; charset="iso-8859-2" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Json] Allow any JSON value at the top level X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 07 Jun 2013 16:43:51 -0000 I like this change, but it has impact on section three. These JSON docs: 0 "" "?" means that the table should probably look like: 00 00 00 xx UTF-32BE 00 xx ?? xx UTF-16BE xx 00 00 00 UTF-32LE xx 00 xx ?? UTF-16LE xx xx ?? ?? UTF-8 algorithmically: if length<2 return UTF-8 if buf[0] if buf[1] return UTF-8 if length<4 or buf[2] return UTF-16LE return UTF-32LE if buf[1] return UTF-16BE return UTF-32BE On 6/6/13 9:51 PM, "Manger, James H" wrote: >The current spec only allows a JSON text to be an object or array. >Section 2. "JSON Grammar" says: > > A JSON text is a serialized object or array. > > JSON-text =3D object / array > > >I propose allowing a JSON text to be any JSON value. > > A JSON text is a serialization of any JSON value. > > JSON-text =3D value > > value =3D false / null / true / object / array / number / string > > >ECMAScript already allows this. >http://www.ecma-international.org/ecma-262/5.1/#sec-15.12 > > * The top level JSONText production of the ECMAScript JSON grammar > may consist of any JSONValue rather than being restricted to being > a JSONObject or a JSONArray as specified by RFC 4627. > >-- >James Manger > > >_______________________________________________ >json mailing list >json@ietf.org >https://www.ietf.org/mailman/listinfo/json > --=20 Joe Hildebrand From jsontest@yahoo.com Fri Jun 7 09:45:47 2013 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 AAEB221F9925 for ; Fri, 7 Jun 2013 09:45:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.997 X-Spam-Level: * X-Spam-Status: No, score=1.997 tagged_above=-999 required=5 tests=[BAYES_50=0.001, J_CHICKENPOX_45=0.6, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AOFwkykRtIk5 for ; Fri, 7 Jun 2013 09:45:35 -0700 (PDT) Received: from nm49-vm4.bullet.mail.ne1.yahoo.com (nm49-vm4.bullet.mail.ne1.yahoo.com [98.138.121.132]) by ietfa.amsl.com (Postfix) with ESMTP id 0619E21F848A for ; Fri, 7 Jun 2013 09:45:34 -0700 (PDT) Received: from [98.138.90.52] by nm49.bullet.mail.ne1.yahoo.com with NNFMP; 07 Jun 2013 16:45:34 -0000 Received: from [98.138.84.42] by tm5.bullet.mail.ne1.yahoo.com with NNFMP; 07 Jun 2013 16:45:34 -0000 Received: from [127.0.0.1] by smtp110.mail.ne1.yahoo.com with NNFMP; 07 Jun 2013 16:45:34 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1370623534; bh=nlgEJS3jYCdaMElYBpMBv1FniAHJjAnsD6djrliB8Zg=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:References:In-Reply-To:Mime-Version:Content-Transfer-Encoding:Content-Type:Message-Id:Cc:X-Mailer:From:Subject:Date:To; b=lztfkBEcUnv9i89UkoPex/IPhAgj0IQGmQWqaYIXFdfCqbBwHCPr0ZNTkxY/hOpb2MjG59nVuzGFhrTkxWxfXMhGNnAT9bXveReWt7453Bz8iWinxdIGsDTLkcxq6uD8XwsJiR4O/kwBzX0LuXrg6T910//cGUOKvXvHbjCT4+8= X-Yahoo-Newman-Id: 271071.13062.bm@smtp110.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: VU2zV64VM1lOa741_7ee62TxvJRPKJJJTI1hWccKNN14xdz SRCwIVaL4.mlbNugMtR6BhJ43KQQ7jV.XdBe_0xyEZK1DIhe57Pemd1dwq2V anzSAjl_csDtkvTtkxQl0goP_SWKQTXtZQSRIj5vzZn5OFkwGVLz5HlJ8d_9 olwIGpb0bjhrTr76invU5clr1oxfU_S.HfLoPr9W5qbFekKpES9oFrGpJC0k EL9hH50HS4mjLucZgRGp5gp77nAuLw65RJvlzq.kLFxIO9r4PFwB4N22xb76 Bu1CCsyFyOfPBwB_VUEYRroTiW_812l_Qi5KFrXV3QVWDDFZ6lC8kWqWsUKO NCM3BmAmrlcqmBMx6TcYxhYuBpOefTbTV2xQER7oROMyv_wzpVBLhF_5szPa VTeSQwQmxlP40Ht1fRX8IYbzQKHXAl1OBokhDnLeSqU5U2q.qXJ99CaJ40im 1HKVXD6p1swfifOydwASftZ9PKuJ_EvUE5HyKy_yI.clQtbiF65xdwgIfUiw Tcze3Zh35rWRSqjnuZwT8HH_YESlwWZOH_01.ZOt0xz_1VrI20WwnUdPRJ9W zpkdInpO5acm2J6P46EuDpf_vXRk770wnCcWOYP2PG5pr_HCu7ZyG2OIwh_Y - X-Yahoo-SMTP: indQcmSswBC8IKsm6t4aCAPskK3T X-Rocket-Received: from [192.168.10.95] (jsontest@64.134.39.87 with ) by smtp110.mail.ne1.yahoo.com with SMTP; 07 Jun 2013 09:45:34 -0700 PDT References: <641B1C79FB414811BCBDE8BE0FD165D6@codalogic> In-Reply-To: <641B1C79FB414811BCBDE8BE0FD165D6@codalogic> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <32388664-98E4-4197-B4F1-2799E18AA429@yahoo.com> X-Mailer: iPod Mail (9B206) From: Vinny A Date: Fri, 7 Jun 2013 11:45:24 -0500 To: Pete Cordell Cc: "" Subject: Re: [Json] Comments by convention X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 07 Jun 2013 16:45:47 -0000 Adding to your proposal, I'd like it stated that comments are also first cla= ss name:value data pairs; ie if I call (pseudo code): Jsonobject.get("// description"); Then I will get the value "A short description of the item ordered". Obvious= ly this is also backward compatible. ----------------- Vinny www.jsontest.com On Jun 7, 2013, at 11:31 AM, "Pete Cordell" wrote: > I along with many wish JSON included comments. Since they can't retrospec= tively be added, what are the prospects of documenting a convention for incl= uding comments in a JSON message? >=20 > For example, something along the lines of: >=20 > 2.6 Comments >=20 > JSON has no native ability to represent comments. Instead, by convention,= unless overridden by a protocol definition, comments can be represented by n= ame/value pairs (a.k.a. members) with string values of the form: >=20 > "//": "This is a comment" >=20 > Comments can be associated with a particular member within an object using= a comment name of the form "// foo" where "foo" is the name of the member t= o which the comment applies. >=20 > For example: >=20 > "order": { > "//": "An order item", > "// description": "A short description of the item ordered", > "description": "1TB HDD", > "// price": "The price in USD", > "price": 123.45 } >=20 > How much goes up in smoke if we do that? >=20 > Pete Cordell > Codalogic Ltd > C++ tools for C++ programmers, http://codalogic.com > Read & write XML in C++, http://www.xml2cpp.com >=20 > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json From douglas@crockford.com Fri Jun 7 09:46:28 2013 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 5C7C821F9925 for ; Fri, 7 Jun 2013 09:46:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_45=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3jA6WKw63OiL for ; Fri, 7 Jun 2013 09:46:22 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id AB52B21F9920 for ; Fri, 7 Jun 2013 09:46:20 -0700 (PDT) Received: from [192.168.114.223] ([216.113.168.135]) by mrelay.perfora.net (node=mrus2) with ESMTP (Nemesis) id 0Lhf6P-1Tz44L1H61-00mudK; Fri, 07 Jun 2013 12:46:15 -0400 Message-ID: <51B20E48.8040109@crockford.com> Date: Fri, 07 Jun 2013 09:46:00 -0700 From: Douglas Crockford User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Allen Wirfs-Brock References: <51AF8479.5080002@crockford.com> <51AF9ACF.5020507@cisco.com> <51AFB3F8.8060708@crockford.com> <8F32953C-C788-4DC9-888E-920E2BEB7FDD@yahoo.com> <831B8E46-F239-4353-8F95-8DF3F9BD2E78@yahoo.com> <51AFC924.2030805@crockford.com> <60141305-DCEA-4EC6-9CDF-82B52B13AE91@wirfs-brock.com> In-Reply-To: <60141305-DCEA-4EC6-9CDF-82B52B13AE91@wirfs-brock.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V02:K0:zw1/zBnE76NJha1Je82pMMz/8q9WQlgYnkf71cM3XCp P7g99b3mmNbHHfMnD5UCjbT/uL1NJXo0Qci2REhF7RR3xYCfZm sglfGuXyA5YX1dVtZZB6IZoFEIRuRRV0XPVpBWaH+uB8kzNSwD yr99agWTb4YOprGJAsuBrKaehDU7IQ6knn/dlcgtTuibg+tWO7 RkrlWdyJ8jt0Ae7+F2K7S2AngvlvUkqlz7IlpQnFm9tcawHnKf eMFCzY5jy+VlXvnMBphI2PKXdbxXIuF7A9sxRxFEQLFCwQ+UYI 9Vj8FoQIrQWtBz0WF39Apgcl9Ods1uURvRNfW3frlDCwGgelh1 4VqiYkUMQxzjueMTdN991hbO2HMjqd7UzwKrth6Pu Cc: Paul Hoffman , "json@ietf.org" Subject: Re: [Json] The names within an object SHOULD be unique. X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 07 Jun 2013 16:46:28 -0000 On 6/6/2013 8:42 AM, Allen Wirfs-Brock wrote: > Given that duplicate names have historically been valid, that some > people use them, and that the standard ECMAScript JSON parser accepts > them I don't see why allowing a parser to reject duplicate names is > helpful. > > > Because some parsers do so, and have for years. JSON.parse is not the only JSON parser. Our purpose here is not to attempt to fix this thing, because fixing it will break it. There were unfortunately ambiguities in the RFC. If we can, we should remove the ambiguities, but we must do so without changing the meaning of what JSON is. From nico@cryptonector.com Fri Jun 7 09:47:11 2013 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 B293921F8613 for ; Fri, 7 Jun 2013 09:47:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qA0M0rVDqyJ6 for ; Fri, 7 Jun 2013 09:47:06 -0700 (PDT) Received: from homiemail-a34.g.dreamhost.com (caiajhbdccac.dreamhost.com [208.97.132.202]) by ietfa.amsl.com (Postfix) with ESMTP id 96AC721F8546 for ; Fri, 7 Jun 2013 09:47:05 -0700 (PDT) Received: from homiemail-a34.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a34.g.dreamhost.com (Postfix) with ESMTP id 0EA4E1006E for ; Fri, 7 Jun 2013 09:47:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=uS20ml4AoNdWbebot8xC nda5+XQ=; b=djl4+KFSGouarfst3dm5lXjJiByBhTNMYlb9JNTCWYsr8Zej6nEF 3mw/kSzUab/TV9oZ9oXf4Q5XDzCgas8I1fHNc/wGV0qrfM62FsdMULl/Rdxyyfxk BikAcb/dmPRbGVFnHCrkZuK1FzZrpUKsLF2VdwO+bK8OSrhIhegMoho= Received: from mail-wi0-f169.google.com (mail-wi0-f169.google.com [209.85.212.169]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a34.g.dreamhost.com (Postfix) with ESMTPSA id AD56A10062 for ; Fri, 7 Jun 2013 09:47:04 -0700 (PDT) Received: by mail-wi0-f169.google.com with SMTP id hn14so1568827wib.2 for ; Fri, 07 Jun 2013 09:47:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Ic3qEgFgnnw/PdQQuLa1uMuOFdOV4fy+aRJTIshah+k=; b=QpEDfmFGzZuRYt5hxz/4iDawALDHiTnJlSo/JKP6gt3/WWmtFf1hwRPCCQqcAxkNr6 kgsUWseBd2C4zxmQXnaNpw/PH/jqurwby1vxGuk7tMyGYQvOC/MPMIUKYB6/qbxxSEY1 BF8mHQ46cAKyFRYcHMAGvOU6rmDeuPfEYp2Df/+zZhaTBUTW2nqhCRR8zJ6dTU0yqSh4 GTCU0APTStP3Mz0GYUXRFPkNtV8Qb0xjCmDZBXsHZtrh2+3RibieSBYFJFXXhJEjE33W MaZx31gjNLP6DnkZ96GICDEM5gHLwi4rFpX6oQugYh8Rrj40LRBGsXFzkor/qA2WAEwz ZxdQ== MIME-Version: 1.0 X-Received: by 10.180.12.72 with SMTP id w8mr2405842wib.4.1370623623084; Fri, 07 Jun 2013 09:47:03 -0700 (PDT) Received: by 10.216.63.136 with HTTP; Fri, 7 Jun 2013 09:47:02 -0700 (PDT) In-Reply-To: <51b1a370.4521320a.62df.ffffcf2bSMTPIN_ADDED_BROKEN@mx.google.com> References: <51AF8479.5080002@crockford.com> <51b1168c.e686440a.5339.5fc4SMTPIN_ADDED_BROKEN@mx.google.com> <51b1a370.4521320a.62df.ffffcf2bSMTPIN_ADDED_BROKEN@mx.google.com> Date: Fri, 7 Jun 2013 11:47:02 -0500 Message-ID: From: Nico Williams To: Markus Lanthaler Content-Type: text/plain; charset=UTF-8 Cc: json@ietf.org Subject: Re: [Json] The names within an object SHOULD be unique. X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 07 Jun 2013 16:47:11 -0000 On Fri, Jun 7, 2013 at 4:04 AM, Markus Lanthaler wrote: > If your "handle" implies that an error might be raised then it would be OK but I believe most people wouldn't understand it that way. I meant "not crash" :) However, the note by Allen Wirfs-Brock convinces me that parsers SHOULD NOT reject dups. Nico -- From cowan@ccil.org Fri Jun 7 09:48:12 2013 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 DFCFB21F9943 for ; Fri, 7 Jun 2013 09:48:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.167 X-Spam-Level: X-Spam-Status: No, score=-3.167 tagged_above=-999 required=5 tests=[AWL=0.432, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c1PY7LrCRB6d for ; Fri, 7 Jun 2013 09:48:08 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id 0C81121F84CE for ; Fri, 7 Jun 2013 09:48:05 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1Ukzpb-0004Se-It; Fri, 07 Jun 2013 12:48:03 -0400 Date: Fri, 7 Jun 2013 12:48:03 -0400 From: John Cowan To: Paul Hoffman Message-ID: <20130607164803.GA13569@mercury.ccil.org> References: <255B9BB34FB7D647A506DC292726F6E1151B21F9A9@WSMSG3153V.srv.dir.telstra.com> <3B4E7F65-B9B9-4C95-B077-D178B8DD8216@vpnc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3B4E7F65-B9B9-4C95-B077-D178B8DD8216@vpnc.org> User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Cc: "json@ietf.org" Subject: Re: [Json] Allow any JSON value at the top level X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 07 Jun 2013 16:48:13 -0000 Paul Hoffman scripsit: > I am interested to hear examples of where this change would cause > breakage, particularly given that ECMAScript already has this rule. I think the self-bounding nature of current JSON is important to preserve. -- In politics, obedience and support John Cowan are the same thing. --Hannah Arendt http://www.ccil.org/~cowan From sayrer@gmail.com Fri Jun 7 09:51:02 2013 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 3D57621F9926 for ; Fri, 7 Jun 2013 09:51:02 -0700 (PDT) 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=[AWL=0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MlV24japGhNF for ; Fri, 7 Jun 2013 09:51:01 -0700 (PDT) Received: from mail-we0-x229.google.com (mail-we0-x229.google.com [IPv6:2a00:1450:400c:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id 9F62F21F8613 for ; Fri, 7 Jun 2013 09:51:00 -0700 (PDT) Received: by mail-we0-f169.google.com with SMTP id n57so3318373wev.0 for ; Fri, 07 Jun 2013 09:50:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=9AbNaHW6Jpt2kLrOf00ks5TvErW0hnP9uiSwtD2V/Ek=; b=GSwmRIDDOKf4Ec6XS3k/YjgP7zdQy10PuTqM71HzfNEDYHi5Ri+09HiZ+D698H2ePe AW8hcvhzZw4wRnORFayBBVY16ciMxJQreOiDW90UdTPF53B7/QspJ+M7DH5YpsT89lMz +l1gJjPtAJyz6Qzn6PwND+jvVEHblenWW0fCmf625Bb9EQM0YEtMRF6cfHW1O8jkOLm+ Ws+KuUlJJFY86E6dboqq2UpzbkQtfSgVz+ONHuF7+CPeUYNTGce1lHN3ZI5QQN8IdAt2 rc08L+yWdWZMOVFYMnfQI2O6AV+/BgHPUPV9ky3y7y8aAJ8OuBR3KX6BNrZlcGWV1I29 TkYg== MIME-Version: 1.0 X-Received: by 10.194.63.229 with SMTP id j5mr4767105wjs.79.1370623859652; Fri, 07 Jun 2013 09:50:59 -0700 (PDT) Received: by 10.194.83.35 with HTTP; Fri, 7 Jun 2013 09:50:59 -0700 (PDT) In-Reply-To: References: <255B9BB34FB7D647A506DC292726F6E1151B21F9A9@WSMSG3153V.srv.dir.telstra.com> Date: Fri, 7 Jun 2013 09:50:59 -0700 Message-ID: From: R S To: "Matt Miller (mamille2)" Content-Type: multipart/alternative; boundary=047d7ba9751846802704de933cf4 Cc: "Manger, James H" , Tim Bray , "json@ietf.org" Subject: Re: [Json] Allow any JSON value at the top level X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 07 Jun 2013 16:51:02 -0000 --047d7ba9751846802704de933cf4 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Jun 7, 2013 at 9:22 AM, Matt Miller (mamille2) wrote: > > This is one area where I think we need experimentation before we can > consider such as change. It very well could be that "everyone" (for some > definition of everyone) has ignored this particular restriction in order to > maximize compatibility with ECMAScript, in which case maintaining this > condition means everyone is technically non-compliant. > RFC 4627 says "A JSON parser MAY accept non-JSON forms or extensions." and implementations that are compatible with ECMAScript are common enough that it seems this extension to RFC 4627 actually doesn't cause problems with applications expecting only arrays or objects at the root. Does anyone have examples of this behavior creating problems in the wild? They must be out there, since support for this extension is so common. - Rob --047d7ba9751846802704de933cf4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, Jun 7, 2013 at 9:22 AM, Matt Miller (mamille2) <= mamille2@cisco.com> wrote:

This is one area where I think we need experimentation before we can consid= er such as change. =A0It very well could be that "everyone" (for = some definition of everyone) has ignored this particular restriction in ord= er to maximize compatibility with ECMAScript, in which case maintaining thi= s condition means everyone is technically non-compliant.


RFC 4627 says "A JSON = parser MAY accept non-JSON forms or extensions." and implementations t= hat are compatible with ECMAScript are common enough that it seems this ext= ension to RFC 4627 actually doesn't cause problems with applications ex= pecting only arrays or objects at the root.

Does anyone have examples of this behavior creating pro= blems in the wild? They must be out there, since support for this extension= is so common.

- Rob
--047d7ba9751846802704de933cf4-- From nico@cryptonector.com Fri Jun 7 09:52:53 2013 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 EBAA621F86D5 for ; Fri, 7 Jun 2013 09:52:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZBuyzF4H5qpa for ; Fri, 7 Jun 2013 09:52:47 -0700 (PDT) Received: from homiemail-a70.g.dreamhost.com (caiajhbdcbhh.dreamhost.com [208.97.132.177]) by ietfa.amsl.com (Postfix) with ESMTP id ED78921F8717 for ; Fri, 7 Jun 2013 09:52:46 -0700 (PDT) Received: from homiemail-a70.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a70.g.dreamhost.com (Postfix) with ESMTP id 951B376806D for ; Fri, 7 Jun 2013 09:52:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=wiYgxv06NyxghDIC6yVN g9vft6c=; b=MHVzVEHCYrlzhmWKxdj37UUxJpk1/EIe6RMr/Asj3dS2cSSkthpY XwP0YYcvtxpsXPn1dcnlqydHUXeHyylbMFCsJB8byY1pIHu7GCycHKweBHnPtCha wyl1rH7yrwbODiK9ilNZ8VHI6j71PcfIKAWDWKH6/A0T231GQZgfX+M= Received: from mail-we0-f175.google.com (mail-we0-f175.google.com [74.125.82.175]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a70.g.dreamhost.com (Postfix) with ESMTPSA id 49EEE768070 for ; Fri, 7 Jun 2013 09:52:46 -0700 (PDT) Received: by mail-we0-f175.google.com with SMTP id t59so3305844wes.34 for ; Fri, 07 Jun 2013 09:52:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=tWXFLnOin8yOk+1usxyl0KJG9DBrfFPTip49kg2PUAE=; b=RVNYs//DIZP0n+Qy+UIqM/DG/qYztPzcfqkOj1zE9F7i7Lx0hPHYctUtriUV3o94X4 wNhuRlmMCBzPRlXH3PWPY6PegpFd8Gp0MlWE2tJSfIFh/bfVAaXy/KIjZVD1p6xdm8zK Lk7EvJI0cg8Z3LpDp6gI2plYg8Dci3dVulqbLGsZUToBHxWBv5X9WH9MonNRt9S9KUzF ws9LvzFV88xfoY1SNQnIh9s5uISw5tyXqorBI8Kq098zRCQ9Wci/otI0FHU+yD/uj734 mvT7noN+JDBkVLXNWrii2NBxg9LJaK9aYdRK8SwQyuoCzQBbhWx3YDUd6V0KEYJW6u/C N6Zw== MIME-Version: 1.0 X-Received: by 10.194.24.8 with SMTP id q8mr4919450wjf.81.1370623964889; Fri, 07 Jun 2013 09:52:44 -0700 (PDT) Received: by 10.216.63.136 with HTTP; Fri, 7 Jun 2013 09:52:44 -0700 (PDT) In-Reply-To: <51B20529.2040906@drees.name> References: <255B9BB34FB7D647A506DC292726F6E1151B21F9A9@WSMSG3153V.srv.dir.telstra.com> <3B4E7F65-B9B9-4C95-B077-D178B8DD8216@vpnc.org> <51B20529.2040906@drees.name> Date: Fri, 7 Jun 2013 11:52:44 -0500 Message-ID: From: Nico Williams To: stefan@drees.name Content-Type: text/plain; charset=UTF-8 Cc: Paul Hoffman , "json@ietf.org" Subject: Re: [Json] Allow any JSON value at the top level X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 07 Jun 2013 16:52:53 -0000 On Fri, Jun 7, 2013 at 11:07 AM, Stefan Drees wrote: > On 07.06.13 17:40, Paul Hoffman wrote: >> >> >> >> On Jun 6, 2013, at 8:51 PM, "Manger, James H" >> wrote: >> >>> The current spec only allows a JSON text to be an object or array. >>> Section 2. "JSON Grammar" says: >>> >>> A JSON text is a serialized object or array. >>> >>> JSON-text = object / array >>> >>> >>> I propose allowing a JSON text to be any JSON value. >>> >>> A JSON text is a serialization of any JSON value. >>> >>> JSON-text = value >>> >>> value = false / null / true / object / array / number / string >> >> >> +1 to this, and to removing the "how to tell if you are looking at a >> JSON text" from the parser section. That rule is fragile and not useful. >> > > +0 as long as the future encoding detection tricks in section 3 are coherent > with it. If the top-level may be any value then we still have the first character being ASCII and the section 3 encoding detection algorithm still works: 00 00 00 xx UTF-32BE 00 xx UTF-16BE xx 00 UTF-32LE xx 00 UTF-16LE xx xx UTF-8 I'm in favor of this change, but I'd be happy to have the new RFC allow for parsers that can't handle this. Nico -- From douglas@crockford.com Fri Jun 7 09:56:17 2013 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 425B221F92E3 for ; Fri, 7 Jun 2013 09:56:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WpfOaoenOrrP for ; Fri, 7 Jun 2013 09:56:11 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id 5B08821F9079 for ; Fri, 7 Jun 2013 09:56:11 -0700 (PDT) Received: from [192.168.114.223] ([216.113.168.135]) by mrelay.perfora.net (node=mrus4) with ESMTP (Nemesis) id 0LsCqF-1UNsgz0rjr-013CdR; Fri, 07 Jun 2013 12:56:08 -0400 Message-ID: <51B2109A.30506@crockford.com> Date: Fri, 07 Jun 2013 09:55:54 -0700 From: Douglas Crockford User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Pete Cordell , "json@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V02:K0:M6i6YCClH9HUFTdYR6a02JNBnGn0uJAQTfhFjqG37Pe aC7BMWoQh+v/yCJf6K+Dd8gyuYxvZ9jEXef/fzocUpSRAPQt3W prVNjwWYRt+jQ8zSTkznWj+hSPSKXidwuo9z3YpXIUHnCJeWSf 8Cjx9IxGqvzDjP6fVj7obXWgpE3x3EYqW51K3sN71jFU0j1Yvp lFzA6uRo5Q2Mcv7ZoiwQn99iPEL6RRrBiLVeu+70vp8LCw3Ikb fhTZav0U6NNJ7NZkzKRKbsAPdpOBA1YEyFuT1JrQuqQVNB9hfH gI6iYPEZvfbSCH6emPRikq+ISvCUYm8XhBv5wviJ1EW/jr7Oeo yI50XQLZqti2K8oWKkvU= Subject: Re: [Json] Comments by convention X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 07 Jun 2013 16:56:17 -0000 On 6/7/2013 9:31 AM, Pete Cordell wrote: > I along with many wish JSON included comments. Since they can't > retrospectively be added, what are the prospects of documenting a > convention for including comments in a JSON message? > > For example, something along the lines of: > > 2.6 Comments > > JSON has no native ability to represent comments. Instead, by > convention, unless overridden by a protocol definition, comments can > be represented by name/value pairs (a.k.a. members) with string values > of the form: > > "//": "This is a comment" > > Comments can be associated with a particular member within an object > using a comment name of the form "// foo" where "foo" is the name of > the member to which the comment applies. > > For example: > > "order": { > "//": "An order item", > "// description": "A short description of the item ordered", > "description": "1TB HDD", > "// price": "The price in USD", > "price": 123.45 } > > How much goes up in smoke if we do that? That belongs in the best practices document. From jhildebr@cisco.com Fri Jun 7 09:57:07 2013 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 31E2E21F8994 for ; Fri, 7 Jun 2013 09:57:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dE1NsrROfAWC for ; Fri, 7 Jun 2013 09:57:01 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 50A6821F85BF for ; Fri, 7 Jun 2013 09:57:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=426; q=dns/txt; s=iport; t=1370624221; x=1371833821; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=BZolNwZL6ANb77qeAD8z4UlsbSWbHfEgh+C7f/nwHuc=; b=Nx3oKfK/e8MwtjEKQuww/Wd2LuRYN4AnIlFM7eGzRwHoqOC4rD1YTjVY GVMR4wTNrAkjNHGAqvoGyt9xbNRb/NK3zHct2oHb3lQuJqT8fD76D2qpv 97F8b/VKo/VUpL3AvFqMoPki5iTXcGms4mw6QbdwZ0SOTM64Uwe3+xT6v s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqUFADoQslGtJV2Y/2dsb2JhbABZgwmDJbt6gQAWdIIjAQEBBDo/EgEIGAoUQiUCBAENBQiIBb0NjwcxB4J7YQOpAoMPgic X-IronPort-AV: E=Sophos;i="4.87,823,1363132800"; d="scan'208";a="220213286" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-4.cisco.com with ESMTP; 07 Jun 2013 16:56:55 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r57GuteE019128 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 7 Jun 2013 16:56:55 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.56]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.02.0318.004; Fri, 7 Jun 2013 11:56:54 -0500 From: "Joe Hildebrand (jhildebr)" To: "stefan@drees.name" , "Matt Miller (mamille2)" Thread-Topic: [Json] ABNF nits Thread-Index: AQHOYxhuLNPlu69CpUeh/eSpf1GKTZkpg97A///1nACAABksoIAAjFoAgACAJYCAAAT9AP//xO0A Date: Fri, 7 Jun 2013 16:56:53 +0000 Message-ID: In-Reply-To: <51B1EE02.4090804@drees.name> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [64.101.72.72] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Carsten Bormann , "Manger, James H" , "json@ietf.org" Subject: Re: [Json] ABNF nits X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 07 Jun 2013 16:57:07 -0000 On 6/7/13 8:28 AM, "Stefan Drees" wrote: >Did it catch everything? indentation, which is less of a nit in ABNF than other syntaxes. >Or do we want to explain, that 4HEXDIG means >exactly 4 hex digits? I guess no, as the comment is depicting this nice >and it is common ABNF practice to deal with multiplicity. See section 3.7 of 5234. 4HEXDIG means exactly 4 HEXDIG. --=20 Joe Hildebrand From allen@wirfs-brock.com Fri Jun 7 09:59:42 2013 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 BEB6021F93D2 for ; Fri, 7 Jun 2013 09:59:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.018 X-Spam-Level: X-Spam-Status: No, score=-2.018 tagged_above=-999 required=5 tests=[AWL=-0.019, BAYES_00=-2.599, J_CHICKENPOX_45=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RCbSQjz1pMXI for ; Fri, 7 Jun 2013 09:59:37 -0700 (PDT) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by ietfa.amsl.com (Postfix) with ESMTP id F138821F9079 for ; Fri, 7 Jun 2013 09:59:36 -0700 (PDT) Received: from 069-064-236-244.pdx.net ([69.64.236.244] helo=[192.168.0.15]) by mho-02-ewr.mailhop.org with esmtpa (Exim 4.72) (envelope-from ) id 1Ul00l-000LLL-Gu; Fri, 07 Jun 2013 16:59:35 +0000 X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 69.64.236.244 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/yS0Ckx/4UIb8wZi+3OGBwJW37KTUKEDw= Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Allen Wirfs-Brock In-Reply-To: <51B20E48.8040109@crockford.com> Date: Fri, 7 Jun 2013 09:59:29 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <944ECA7F-A548-4903-9526-847065066E8E@wirfs-brock.com> References: <51AF8479.5080002@crockford.com> <51AF9ACF.5020507@cisco.com> <51AFB3F8.8060708@crockford.com> <8F32953C-C788-4DC9-888E-920E2BEB7FDD@yahoo.com> <831B8E46-F239-4353-8F95-8DF3F9BD2E78@yahoo.com> <51AFC924.2030805@crockford.com> <60141305-DCEA-4EC6-9CDF-82B52B13AE91@wirfs-brock.com> <51B20E48.8040109@crockford.com> To: Douglas Crockford X-Mailer: Apple Mail (2.1085) Cc: Paul Hoffman , "json@ietf.org" Subject: Re: [Json] The names within an object SHOULD be unique. X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 07 Jun 2013 16:59:42 -0000 On Jun 7, 2013, at 9:46 AM, Douglas Crockford wrote: > On 6/6/2013 8:42 AM, Allen Wirfs-Brock wrote: >> Given that duplicate names have historically been valid, that some = people use them, and that the standard ECMAScript JSON parser accepts = them I don't see why allowing a parser to reject duplicate names is = helpful. >>=20 >>=20 >>=20 > Because some parsers do so, and have for years. JSON.parse is not the = only JSON parser. Our purpose here is not to attempt to fix this thing, = because fixing it will break it. There were unfortunately ambiguities in = the RFC. If we can, we should remove the ambiguities, but we must do so = without changing the meaning of what JSON is. I think it is more important to preserve the validity of existing = archival datasets then it is to preserve the validity of existing = parsers that throw on duplicate keys.=20 Allen= From douglas@crockford.com Fri Jun 7 10:03:01 2013 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 7722021F9385 for ; Fri, 7 Jun 2013 10:02:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, J_CHICKENPOX_45=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IxIBKskwexGP for ; Fri, 7 Jun 2013 10:02:40 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id 652CC21F92E3 for ; Fri, 7 Jun 2013 10:02:39 -0700 (PDT) Received: from [192.168.114.223] ([216.113.168.135]) by mrelay.perfora.net (node=mrus2) with ESMTP (Nemesis) id 0Lq9Xs-1U7WVi1quu-00do2j; Fri, 07 Jun 2013 13:02:33 -0400 Message-ID: <51B2121B.5080801@crockford.com> Date: Fri, 07 Jun 2013 10:02:19 -0700 From: Douglas Crockford User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Allen Wirfs-Brock References: <51AF8479.5080002@crockford.com> <51AF9ACF.5020507@cisco.com> <51AFB3F8.8060708@crockford.com> <8F32953C-C788-4DC9-888E-920E2BEB7FDD@yahoo.com> <831B8E46-F239-4353-8F95-8DF3F9BD2E78@yahoo.com> <51AFC924.2030805@crockford.com> <60141305-DCEA-4EC6-9CDF-82B52B13AE91@wirfs-brock.com> <51B20E48.8040109@crockford.com> <944ECA7F-A548-4903-9526-847065066E8E@wirfs-brock.com> In-Reply-To: <944ECA7F-A548-4903-9526-847065066E8E@wirfs-brock.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V02:K0:srROkvQXWBkVt+PwjWr8hVt8lRO1mMdHTNmhcOAjIbU 2eLt9+DCWuKLIZrgNGGOhbCSXKKpXSn3ETwsWiAcg3JwiKI1LD GQqluNavIF9CWOZ4SiuN7z0OQejLcsSgl6YZniUz+aUFiWSP6G ifdH97oHEfPXSQdeMJ0w2RK++McocO0+m964gWwlAZL3VGXMtj P/AgsTYvFh1L9MAAiywjPi6j/PHKEAUSQYQxJSFhpZnaiCwATy v0vot52HYAUS0HP5hzb5gH3rtS4s0v7DORDXM77aZWhA5f5EU+ QmSuMcFgXX3uQNeJv3RgIXjv1uyTSbT7LgRMDn9ehiEouRnvjy Kq1lINLCaKJ4Q9rSwQ+3k6nAklKo6oJXQ2KNeZZ/j Cc: Paul Hoffman , "json@ietf.org" Subject: Re: [Json] The names within an object SHOULD be unique. X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 07 Jun 2013 17:03:01 -0000 On 6/7/2013 9:59 AM, Allen Wirfs-Brock wrote: > On Jun 7, 2013, at 9:46 AM, Douglas Crockford wrote: > >> On 6/6/2013 8:42 AM, Allen Wirfs-Brock wrote: >>> Given that duplicate names have historically been valid, that some people use them, and that the standard ECMAScript JSON parser accepts them I don't see why allowing a parser to reject duplicate names is helpful. >>> >>> >>> >> Because some parsers do so, and have for years. JSON.parse is not the only JSON parser. Our purpose here is not to attempt to fix this thing, because fixing it will break it. There were unfortunately ambiguities in the RFC. If we can, we should remove the ambiguities, but we must do so without changing the meaning of what JSON is. > I think it is more important to preserve the validity of existing archival datasets then it is to preserve the validity of existing parsers that throw on duplicate keys. > We should not be invalidating data or programs. We should only be explaining better. No breakage is acceptable. No breakage. From cowan@ccil.org Fri Jun 7 10:03:22 2013 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 1D3B621F95EF for ; Fri, 7 Jun 2013 10:03:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.044 X-Spam-Level: X-Spam-Status: No, score=-4.044 tagged_above=-999 required=5 tests=[AWL=1.255, BAYES_00=-2.599, GB_I_LETTER=-2, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cNnz9kOTk3wp for ; Fri, 7 Jun 2013 10:03:17 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id 4CB1421F93D2 for ; Fri, 7 Jun 2013 10:03:17 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1Ul04H-0006HD-0i; Fri, 07 Jun 2013 13:03:13 -0400 Date: Fri, 7 Jun 2013 13:03:12 -0400 From: John Cowan To: =?iso-8859-1?B?Ik1hcnRpbiBKLiBE/HJzdCI=?= Message-ID: <20130607170312.GB13569@mercury.ccil.org> References: <51B1A1E2.7020202@it.aoyama.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <51B1A1E2.7020202@it.aoyama.ac.jp> User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Cc: Jacob Davies , "Joe Hildebrand \(jhildebr\)" , "json@ietf.org" Subject: Re: [Json] The parts of JSON (a possible aid to discussion) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 07 Jun 2013 17:03:22 -0000 "Martin J. Dürst" scripsit: > You don't need to use an Unicode encoding for concrete > representation. You may not need an Unicode encoding for byte > serialization. But you need a concrete representation, and a byte > encoding, than will handle all strings of Unicode code points and no > other strings. Not really. The whole point of the escapes is so that you can encode JSON in pure ASCII or any other encoding. As long as the letters a, b, c, d, e, f, l, n, r, s, t, and u, the digits 0-9, and the symbols and punctuation marks left and right square bracket, left and right brace, comma, period, minus sign, colon, double quote, and backslash are representable, JSON is representable. (You could design a 5-bit encoding to do so.) -- John Cowan http://ccil.org/~cowan cowan@ccil.org The work of Henry James has always seemed divisible by a simple dynastic arrangement into three reigns: James I, James II, and the Old Pretender. --Philip Guedalla From jhildebr@cisco.com Fri Jun 7 10:08:48 2013 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 E54F521F947C for ; Fri, 7 Jun 2013 10:08:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hJZ0qVB6+poj for ; Fri, 7 Jun 2013 10:08:42 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 05A2221F94DC for ; Fri, 7 Jun 2013 10:08:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=632; q=dns/txt; s=iport; t=1370624922; x=1371834522; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=76FivhxpsqOF7SqAmSiroLna5elhSED2m3VbZspyZHg=; b=D8ObldYwy/6XRe0F/FaXAAAHWgT4qQvhIuxPS/d6+GdrHXxIZ+FWfhBj M6IzmuEoGhhaWcpuyslhyCCNljHv8eZAH3cKCVEDEszjTlTa0teJYuL7f 2iPSzrUWyNzHWvF6EppCPSVBPHFT+eebWMu5cAhlFYvciw6AcvU0Lrc82 I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqUFAKwSslGtJV2b/2dsb2JhbABZgwmDJbt6gQAWdIIjAQEBBDpRAQgYChRCJQEBBAESCIdzAw+9A4xbgiw4gnthA6kCgw+CJw X-IronPort-AV: E=Sophos;i="4.87,823,1363132800"; d="scan'208";a="220132444" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-8.cisco.com with ESMTP; 07 Jun 2013 17:08:41 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r57H8eLN032186 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 7 Jun 2013 17:08:40 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.56]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.02.0318.004; Fri, 7 Jun 2013 12:08:40 -0500 From: "Joe Hildebrand (jhildebr)" To: Markus Lanthaler , "json@ietf.org" Thread-Topic: [Json] Allow any JSON value at the top level Thread-Index: Ac5jMj7wK5i9s5prS+2npykXIGILbgALg8dAAA49wAA= Date: Fri, 7 Jun 2013 17:08:40 +0000 Message-ID: In-Reply-To: <00d601ce6360$52acce30$f8066a90$@lanthaler@gmx.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [64.101.72.72] Content-Type: text/plain; charset="us-ascii" Content-ID: <85B58DF4B4C8E74B865F4CEC8C4899B6@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Json] Allow any JSON value at the top level X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 07 Jun 2013 17:08:48 -0000 On 6/7/13 3:20 AM, "Markus Lanthaler" wrote: >On Friday, June 07, 2013 5:51 AM, Manger, James H wrote: >> I propose allowing a JSON text to be any JSON value. >>=20 >> A JSON text is a serialization of any JSON value. >>=20 >> JSON-text =3D value >>=20 >> value =3D false / null / true / object / array / number / string > >I'm strictly against this. Not only would it break many implementations >but >also specs build on top of JSON that rely on JSON-text =3D object / array. What about a new production in parallel to JSON-text, like 'JSON-document'? --=20 Joe Hildebrand From cowan@ccil.org Fri Jun 7 10:09:04 2013 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 9E22A21F9691 for ; Fri, 7 Jun 2013 10:09:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.118 X-Spam-Level: X-Spam-Status: No, score=-3.118 tagged_above=-999 required=5 tests=[AWL=0.181, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UfkZ0iA2ya-n for ; Fri, 7 Jun 2013 10:08:59 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id 0272421F947C for ; Fri, 7 Jun 2013 10:08:59 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1Ul09p-0006rV-Em; Fri, 07 Jun 2013 13:08:57 -0400 Date: Fri, 7 Jun 2013 13:08:57 -0400 From: John Cowan To: =?iso-8859-1?B?Ik1hcnRpbiBKLiBE/HJzdCI=?= Message-ID: <20130607170857.GC13569@mercury.ccil.org> References: <51B06F38.8050707@crockford.com> <51B1B4E7.8090101@it.aoyama.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <51B1B4E7.8090101@it.aoyama.ac.jp> User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Cc: "Joe Hildebrand \(jhildebr\)" , Tim Bray , Paul Hoffman , Douglas Crockford , "json@ietf.org" Subject: Re: [Json] Unpaired surrogates in JSON strings X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 07 Jun 2013 17:09:04 -0000 "Martin J. Dürst" scripsit: > But we should try to do whatever we can in the spec to make it perfectly > clear that there are no good reasons whatsoever to actually do that. That's a little stronger than the truth. You can use Java(Script) strings, which are sequences of arbitrary 16-bit code units, to represent an immutable vector of unsigned integers bounded by 65535, and I have actually done so. However, it is not a good idea to do so in open interchange. > Any Unicode code point except high-surrogate and low-surrogate code > points. In other words, the ranges of integers 0 to D7FF16 and E00016 > to 10FFFF16 inclusive. (See definition D76 in Section 3.9, Unicode > Encoding Forms.) Yes, we should use either "Unicode scalar value" or "Unicode 16-bit code unit", depending on what we decide on. -- That you can cover for the plentiful John Cowan and often gaping errors, misconstruals, http://www.ccil.org/~cowan and disinformation in your posts cowan@ccil.org through sheer volume -- that is another misconception. --Mike to Peter From cowan@ccil.org Fri Jun 7 10:20:05 2013 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 DBAB521F91BC for ; Fri, 7 Jun 2013 10:20:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.978 X-Spam-Level: X-Spam-Status: No, score=-2.978 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oo09jLyBgtBV for ; Fri, 7 Jun 2013 10:20:01 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id 0817421F8EC3 for ; Fri, 7 Jun 2013 10:20:00 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1Ul0KN-0007uR-42; Fri, 07 Jun 2013 13:19:51 -0400 Date: Fri, 7 Jun 2013 13:19:51 -0400 From: John Cowan To: Tim Bray Message-ID: <20130607171950.GD13569@mercury.ccil.org> References: <51B06F38.8050707@crockford.com> <51B1B4E7.8090101@it.aoyama.ac.jp> <9ld3r8pc0tufif18dohb2fmi0ijna1vs4n@hive.bjoern.hoehrmann.de> <56A163E9-E7CD-46B3-9984-8F009EBFF500@vpnc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Cc: Paul Hoffman , "json@ietf.org" Subject: Re: [Json] On characters and code points X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 07 Jun 2013 17:20:05 -0000 Tim Bray scripsit: > > { "End of data marker": "\uFFFF" } > > > > Yes, I *really* want to prohibit that. The one corner case it buys you is > outweighed by a factor of a thousand or so in not being able to use > general-purpose string processing software to deal with JSON payloads. Most general-purpose string processing software is perfectly happy with U+FFFF. There are three different kinds of code points here, and it doesn't help to conflate them: 1) Surrogate code points. These will never be assigned to any characters, and reserved for use as UTF-16 code units. There are exactly 2048 of these, from U+DC00 to U+DFFF. 2) Non-character code points. These will never be assigned to any characters, and are not meant to be interchanged, but internal software is expected to handle them. There are exactly 66 of these, and U+FFFF is one. See for more about this group. 3) Unassigned code points. These are not assigned to any characters today, but may be assigned in future. They may be interchanged. Internal libraries should process them. My view is that group 1 are and should be disallowed in JSON; others disagree. Group 2 should be avoided by JSON creators, but accepted by JSON parsers, which may choose to change them to U+FFFD (replacement character). Group 3 are and should be valid in JSON. -- Values of beeta will give rise to dom! John Cowan (5th/6th edition 'mv' said this if you tried http://www.ccil.org/~cowan to rename '.' or '..' entries; see cowan@ccil.org http://cm.bell-labs.com/cm/cs/who/dmr/odd.html) From cowan@ccil.org Fri Jun 7 10:20:28 2013 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 C0A2321F9246 for ; Fri, 7 Jun 2013 10:20:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.279 X-Spam-Level: X-Spam-Status: No, score=-3.279 tagged_above=-999 required=5 tests=[AWL=0.320, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JIOQ1JZM8XTR for ; Fri, 7 Jun 2013 10:20:24 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id 4EA4B21F8EC3 for ; Fri, 7 Jun 2013 10:20:24 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1Ul0Ks-0007wr-L4; Fri, 07 Jun 2013 13:20:22 -0400 Date: Fri, 7 Jun 2013 13:20:22 -0400 From: John Cowan To: Stefan Drees Message-ID: <20130607172022.GE13569@mercury.ccil.org> References: <51B06F38.8050707@crockford.com> <51B1B4E7.8090101@it.aoyama.ac.jp> <9ld3r8pc0tufif18dohb2fmi0ijna1vs4n@hive.bjoern.hoehrmann.de> <56A163E9-E7CD-46B3-9984-8F009EBFF500@vpnc.org> <51B20731.3040300@drees.name> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <51B20731.3040300@drees.name> User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Cc: Tim Bray , Paul Hoffman , "json@ietf.org" Subject: Re: [Json] On characters and code points X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 07 Jun 2013 17:20:28 -0000 Stefan Drees scripsit: > and what about { "Decorate my slash": "\/" } and "general-purpose > string processing software". Isn't this also a case, where you need > a "pre-conditioner" that replaces the JSON specific escape sequence > "\" with "/" before feeding it into "general-purpose string > processing software" :-?) That would be the JSON parser. -- We pledge allegiance to the penguin John Cowan and to the intellectual property regime cowan@ccil.org for which he stands, one world under http://www.ccil.org/~cowan Linux, with free music and open source software for all. --Julian Dibbell on Brazil, edited From mmorley@mpcm.com Fri Jun 7 10:22:04 2013 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 1051321F8605 for ; Fri, 7 Jun 2013 10:22:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.677 X-Spam-Level: X-Spam-Status: No, score=-1.677 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3uemOlrjRxFC for ; Fri, 7 Jun 2013 10:21:57 -0700 (PDT) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by ietfa.amsl.com (Postfix) with ESMTP id 37F1F21F9007 for ; Fri, 7 Jun 2013 10:21:57 -0700 (PDT) Received: by mail-lb0-f182.google.com with SMTP id r11so3359329lbv.41 for ; Fri, 07 Jun 2013 10:21:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :x-gm-message-state; bh=zoWJgv2YLG3nMkSjT7jmG10kvwf5cGpF2nCXK7NUIn8=; b=eBQI0UyeVK9LmUJujXmAqSyOIW9BLGCJzTBpf5ozxE6G2ZlLRGWB3TtYHvc3OowyUG XtULyn2V+vm+3P5tuuxuTukiCl0BGHQcuwznkH5uepYuYQuIHndOhk2g3AEupBnC+qyE dahamcfYy91uKHGh6RofLfEd01p9g5ao4y12ldBUS/P6huzEL+NccXLwNoNi8kSLFqnv 6Opz5CegnMW0hBm2XEtWth2KIwvdV98nOsZT23tjKLpd/h4PtfUN9Kl7hf1CUGqmcz1z LehJZfAyfoqoDXBJUPFJ4enJJJfh6OHe/0XFm4ZybNc3wWEsBFCEfbipoywgPz6ok3HI UCNA== MIME-Version: 1.0 X-Received: by 10.112.78.73 with SMTP id z9mr1682720lbw.14.1370625715998; Fri, 07 Jun 2013 10:21:55 -0700 (PDT) Sender: mmorley@mpcm.com Received: by 10.114.160.69 with HTTP; Fri, 7 Jun 2013 10:21:55 -0700 (PDT) In-Reply-To: <51B2109A.30506@crockford.com> References: <51B2109A.30506@crockford.com> Date: Fri, 7 Jun 2013 13:21:55 -0400 X-Google-Sender-Auth: B0v9wIvS0lHru_J7Eq0f_0MOcp8 Message-ID: From: Matthew Morley To: Douglas Crockford Content-Type: multipart/alternative; boundary=001a11c3c51cec1e5f04de93aa51 X-Gm-Message-State: ALoCoQlpi1wfvT+3e3UuTnqcLprbHW9NGdxoB0pkQkRf8p+5ycDzt0yV3gjke5pgt4MiKk4Jz5K8 Cc: Pete Cordell , "json@ietf.org" Subject: Re: [Json] Comments by convention X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 07 Jun 2013 17:22:04 -0000 --001a11c3c51cec1e5f04de93aa51 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Jun 7, 2013 at 12:55 PM, Douglas Crockford wrote: > On 6/7/2013 9:31 AM, Pete Cordell wrote: > >> I along with many wish JSON included comments. Since they can't >> retrospectively be added, what are the prospects of documenting a >> convention for including comments in a JSON message? >> >> For example, something along the lines of: >> >> 2.6 Comments >> >> JSON has no native ability to represent comments. Instead, by >> convention, unless overridden by a protocol definition, comments can be >> represented by name/value pairs (a.k.a. members) with string values of the >> form: >> >> "//": "This is a comment" >> >> Comments can be associated with a particular member within an object >> using a comment name of the form "// foo" where "foo" is the name of the >> member to which the comment applies. >> >> For example: >> >> "order": { >> "//": "An order item", >> "// description": "A short description of the item ordered", >> "description": "1TB HDD", >> "// price": "The price in USD", >> "price": 123.45 } >> >> How much goes up in smoke if we do that? >> > That belongs in the best practices document. +1 -- Matthew P. C. Morley --001a11c3c51cec1e5f04de93aa51 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, Jun 7, 2013 at 12:55 PM, Douglas Crockford <d= ouglas@crockford.com> wrote:
On 6/7/2013 9:31 AM, Pete = Cordell wrote:
I along with many wish JSON included comments. =A0Since they can't retr= ospectively be added, what are the prospects of documenting a convention fo= r including comments in a JSON message?

For example, something along the lines of:

2.6 Comments

JSON has no native ability to represent comments. =A0Instead, by convention= , unless overridden by a protocol definition, comments can be represented b= y name/value pairs (a.k.a. members) with string values of the form:

=A0 =A0"//": "This is a comment"

Comments can be associated with a particular member within an object using = a comment name of the form "// foo" where "foo" is the = name of the member to which the comment applies.

For example:

=A0 =A0"order": {
=A0 =A0 =A0 =A0 =A0 =A0"//": "An order item",
=A0 =A0 =A0 =A0 =A0 =A0"// description": "A short descriptio= n of the item ordered",
=A0 =A0 =A0 =A0 =A0 =A0"description": "1TB HDD",
=A0 =A0 =A0 =A0 =A0 =A0"// price": "The price in USD",<= br> =A0 =A0 =A0 =A0 =A0 =A0"price": 123.45 }

How much goes up in smoke if we do that?
That belongs in the best practices document.

+1

--
Matthew P. C. Morley
--001a11c3c51cec1e5f04de93aa51-- From cromis@gmail.com Fri Jun 7 10:24:10 2013 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 E50D321F96FF for ; Fri, 7 Jun 2013 10:24:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MLSMIEPD3jCf for ; Fri, 7 Jun 2013 10:24:10 -0700 (PDT) Received: from mail-qa0-x231.google.com (mail-qa0-x231.google.com [IPv6:2607:f8b0:400d:c00::231]) by ietfa.amsl.com (Postfix) with ESMTP id A3BAE21F8F09 for ; Fri, 7 Jun 2013 10:23:42 -0700 (PDT) Received: by mail-qa0-f49.google.com with SMTP id hu16so1212979qab.1 for ; Fri, 07 Jun 2013 10:23:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=kWLKs9LtP9qbQmOHtwM7o8CjQPaXv/QZnuUoK6IgEvk=; b=hrnmELrGMb9NzT6p2PdQ8QBmz3wxAA6sAQ8L9ZSpXr36o8KqufdHZ9g6t4tYuIVE4n K9pAw5wQmPQLOams5xipDaD9GLoubDNPmzsBsJaJpHWzu+rdVGBaccV1Nqouor1ALi2l l4zvCsw4fBLZPQQzre9ZD+yANctCVX6vsH3pcBCfDurw6XPkWOAUtVBgQZb8erZIiHFw AKb39FG/pLVP9gqpEEDodBuI7EwY2sGvWJnO+di9SqsFfa5JfTzH03x8alWMTuL5o1WR faLOBEw5RtKn+82mQ+1oTAdp2uczeNvq2wWZ7mloph/CMXvNhN7u/g3iiD+UKt+NHofw q2SQ== X-Received: by 10.229.141.69 with SMTP id l5mr1736595qcu.23.1370625820717; Fri, 07 Jun 2013 10:23:40 -0700 (PDT) MIME-Version: 1.0 Sender: cromis@gmail.com Received: by 10.49.106.228 with HTTP; Fri, 7 Jun 2013 10:23:20 -0700 (PDT) In-Reply-To: References: From: Jacob Davies Date: Fri, 7 Jun 2013 10:23:20 -0700 X-Google-Sender-Auth: VxfDYH9yaPNvI2vCfQVnbTlZQHw Message-ID: To: "Joe Hildebrand (jhildebr)" Content-Type: text/plain; charset=ISO-8859-1 Cc: "json@ietf.org" Subject: Re: [Json] The parts of JSON (a possible aid to discussion) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 07 Jun 2013 17:24:11 -0000 On Thu, Jun 6, 2013 at 2:31 PM, Joe Hildebrand (jhildebr) wrote: > The rest of your message, while probably technically correct, effectively > says we're defining an infoset for JSON. I don't like where that got XML, > but the multiple potential wire encodings for JSON may necessitate the > extra level of abstraction, if we're going to be super-clear. > > Or we may elect to remain slightly fuzzy, and a lot easier to read. I'm cool with fuzzy, and I think formalizing this model for public consumption is probably pointless since it is intuitively quite clear in the original RFC. But I thought it would be useful for the purposes of this discussion to give some terms of reference for the different parts of JSON-the-thing, since they are not broken out so distinctly in the RFC. I should have made the point regarding Unicode separately - speaking of separating things - but that was that it is unnecessary to mention Unicode anywhere except when discussing the interpretation of \u escapes and in the discussion of the application/json media-type, and that doing so in other places is a little confusing. (If I write a JSON text on a whiteboard, am I using "Unicode characters"? This seems like a map/territory issue - Unicode is a way of representing characters as integers, but characters are the things under discussion in the abstract model and textual language, not a particular mapping of integers to characters.) From tbray@textuality.com Fri Jun 7 10:26:22 2013 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 4684121F994A for ; Fri, 7 Jun 2013 10:26:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.221 X-Spam-Level: X-Spam-Status: No, score=-1.221 tagged_above=-999 required=5 tests=[AWL=1.155, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IFBYSXfFOupT for ; Fri, 7 Jun 2013 10:26:04 -0700 (PDT) Received: from mail-vc0-f178.google.com (mail-vc0-f178.google.com [209.85.220.178]) by ietfa.amsl.com (Postfix) with ESMTP id 2EA3621F94DF for ; Fri, 7 Jun 2013 10:26:00 -0700 (PDT) Received: by mail-vc0-f178.google.com with SMTP id id13so2966970vcb.9 for ; Fri, 07 Jun 2013 10:25:59 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=d7dQP0Y1BfsS/fB2qsq5Hq9WzaGCU5idg8kmiA5Pk8w=; b=LDfQq6v+YQ4D1EHYyBo7WjzjF1f05FJJrWyGUp4fsSftF8RXyKxhZyM6T0pYErweb7 +iPnzNRdu3E9q4r1nbEalGbIz6ECeZqhhEtAXok5V11krMIJZhSkUerEQ4thR23ewzcv aapqoRddW+zxHlGJAn6FMQQrjpiwfDX/2UzgY2vUgIAw0xEnADwu9v6g6P+pUanAmmRh ibhRZebfpL2hOaYhkZDwqRI/qernqyP/j/TIRCaaXgq0T0FJiFhPgwgYsS2iYzj3LIlf IjLfA7aCrIujL/g5VXl03qwPScbpNrHzJdCShnA33LkFcvEDOzzug9GqZSo/qX+jR4HG ccPA== MIME-Version: 1.0 X-Received: by 10.52.112.5 with SMTP id im5mr5013020vdb.4.1370625959222; Fri, 07 Jun 2013 10:25:59 -0700 (PDT) Received: by 10.220.48.14 with HTTP; Fri, 7 Jun 2013 10:25:59 -0700 (PDT) X-Originating-IP: [96.49.81.176] In-Reply-To: <20130607171950.GD13569@mercury.ccil.org> References: <51B06F38.8050707@crockford.com> <51B1B4E7.8090101@it.aoyama.ac.jp> <9ld3r8pc0tufif18dohb2fmi0ijna1vs4n@hive.bjoern.hoehrmann.de> <56A163E9-E7CD-46B3-9984-8F009EBFF500@vpnc.org> <20130607171950.GD13569@mercury.ccil.org> Date: Fri, 7 Jun 2013 10:25:59 -0700 Message-ID: From: Tim Bray To: John Cowan Content-Type: multipart/alternative; boundary=bcaec54857e86ba1f304de93b985 X-Gm-Message-State: ALoCoQlXu0N1JvQD+xGbneujQbGg94br8fR6gWsVv8igSTFL+cJtlYoEE8mjLOaqt5nbYw2ZZFFs Cc: Paul Hoffman , "json@ietf.org" Subject: Re: [Json] On characters and code points X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 07 Jun 2013 17:26:25 -0000 --bcaec54857e86ba1f304de93b985 Content-Type: text/plain; charset=UTF-8 John is right and I am wrong. What I really want to legislate against is: { "Mis-use of UTF-16 surrogates" : "\udf46\ud800AB\udf11CD\ud812EF", "Mis-use of flipped BOM" : "AB\ufffeCD" } On Fri, Jun 7, 2013 at 10:19 AM, John Cowan wrote: > Tim Bray scripsit: > > > > { "End of data marker": "\uFFFF" } > > > > > > > Yes, I *really* want to prohibit that. The one corner case it buys you is > > outweighed by a factor of a thousand or so in not being able to use > > general-purpose string processing software to deal with JSON payloads. > > Most general-purpose string processing software is perfectly happy > with U+FFFF. There are three different kinds of code points here, > and it doesn't help to conflate them: > > 1) Surrogate code points. These will never be assigned to any characters, > and reserved for use as UTF-16 code units. There are exactly 2048 of > these, from U+DC00 to U+DFFF. > > 2) Non-character code points. These will never be assigned to any > characters, and are not meant to be interchanged, but internal software > is expected to handle them. There are exactly 66 of these, and U+FFFF > is one. See > for more about this group. > > 3) Unassigned code points. These are not assigned to any characters > today, but may be assigned in future. They may be interchanged. > Internal libraries should process them. > > My view is that group 1 are and should be disallowed in JSON; others > disagree. Group 2 should be avoided by JSON creators, but accepted by > JSON parsers, which may choose to change them to U+FFFD (replacement > character). Group 3 are and should be valid in JSON. > > -- > Values of beeta will give rise to dom! John Cowan > (5th/6th edition 'mv' said this if you tried http://www.ccil.org/~cowan > to rename '.' or '..' entries; see cowan@ccil.org > http://cm.bell-labs.com/cm/cs/who/dmr/odd.html) > --bcaec54857e86ba1f304de93b985 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
John is right and I am wrong.=C2=A0 What I reall= y want to legislate against is:

{
=C2=A0"Mis-use of UT= F-16 surrogates" : "\udf46\ud800AB\udf11CD\ud812EF",
=C2=A0"Mis-use of flipped BOM" : "AB\ufffeCD"
}


On Fri, Jun 7, 2013 at 10:19 AM, John Cowan <= cowan@mercury.c= cil.org> wrote:
Tim Bray scripsit:

> > =C2=A0 =C2=A0{ "End of data marker": "\uFFFF"= }
> >
>
> Yes, I *really* want to prohibit that. The one corner case it buys you= is
> outweighed by a factor of a thousand or so in not being able to use > general-purpose string processing software to deal with JSON payloads.=

Most general-purpose string processing software is perfectly happy with U+FFFF. =C2=A0There are three different kinds of code points here,
and it doesn't help to conflate them:

1) Surrogate code points. =C2=A0These will never be assigned to any charact= ers,
and reserved for use as UTF-16 code units. =C2=A0There are exactly 2048 of<= br> these, from U+DC00 to U+DFFF.

2) Non-character code points. =C2=A0These will never be assigned to any
characters, and are not meant to be interchanged, but internal software
is expected to handle them. =C2=A0There are exactly 66 of these, and U+FFFF=
is one. =C2=A0See <http://www.unicode.org/faq/private_use.h= tml#noncharacters>
for more about this group.

3) Unassigned code points. =C2=A0These are not assigned to any characters today, but may be assigned in future. =C2=A0They may be interchanged.
Internal libraries should process them.

My view is that group 1 are and should be disallowed in JSON; others
disagree. =C2=A0Group 2 should be avoided by JSON creators, but accepted by=
JSON parsers, which may choose to change them to U+FFFD (replacement
character). =C2=A0Group 3 are and should be valid in JSON.

--
Values of beeta will give rise to dom! =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jo= hn Cowan
(5th/6th edition 'mv' said this if you tried =C2=A0 =C2=A0http://www.ccil.org/~cowa= n
to rename '.' or '..' entries; see =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0cowan@ccil.org
http://cm.bell-labs.com/cm/cs/who/dmr/odd.html)

--bcaec54857e86ba1f304de93b985-- From cowan@ccil.org Fri Jun 7 10:31:03 2013 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 71F6721F88D8 for ; Fri, 7 Jun 2013 10:31:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.295 X-Spam-Level: X-Spam-Status: No, score=-3.295 tagged_above=-999 required=5 tests=[AWL=0.304, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id srCpKyWLecjp for ; Fri, 7 Jun 2013 10:30:59 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id F1FB721F89A5 for ; Fri, 7 Jun 2013 10:30:58 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1Ul0V6-0000Yq-L8; Fri, 07 Jun 2013 13:30:56 -0400 Date: Fri, 7 Jun 2013 13:30:56 -0400 From: John Cowan To: Tim Bray Message-ID: <20130607173054.GF13569@mercury.ccil.org> References: <51B06F38.8050707@crockford.com> <51B1B4E7.8090101@it.aoyama.ac.jp> <9ld3r8pc0tufif18dohb2fmi0ijna1vs4n@hive.bjoern.hoehrmann.de> <56A163E9-E7CD-46B3-9984-8F009EBFF500@vpnc.org> <20130607171950.GD13569@mercury.ccil.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Cc: Paul Hoffman , "json@ietf.org" Subject: Re: [Json] On characters and code points X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 07 Jun 2013 17:31:03 -0000 Tim Bray scripsit: > John is right and I am wrong. What I really want to legislate against is: > > { > "Mis-use of UTF-16 surrogates" : "\udf46\ud800AB\udf11CD\ud812EF", > "Mis-use of flipped BOM" : "AB\ufffeCD" > } FFEF/FFFE only have their magic meanings at the beginning of a text; otherwise, FFFE and FFFF are formally equivalent (they are both non-characters, my group 2). -- Do what you will, John Cowan this Life's a Fiction cowan@ccil.org And is made up of http://www.ccil.org/~cowan Contradiction. --William Blake From cromis@gmail.com Fri Jun 7 10:31:06 2013 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 533A521F88D8 for ; Fri, 7 Jun 2013 10:31:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N7s+3S4Xk8kB for ; Fri, 7 Jun 2013 10:31:06 -0700 (PDT) Received: from mail-qa0-x233.google.com (mail-qa0-x233.google.com [IPv6:2607:f8b0:400d:c00::233]) by ietfa.amsl.com (Postfix) with ESMTP id D1AAA21F96FF for ; Fri, 7 Jun 2013 10:31:05 -0700 (PDT) Received: by mail-qa0-f51.google.com with SMTP id f11so1217248qae.10 for ; Fri, 07 Jun 2013 10:31:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=Ocieh+0/A+nl1IIv/yUtQbHwRMDsfeuA5JRRiD+UxxU=; b=ZdybbO+DB80soobFzumMvCOZ1xMwdLjrZW0a/sATRSVXPoReOhirq+HoeiAoYAqKh4 PnOPfek+7Vct2sAwWxbKJcbtmQDwBzRj68TSXkR8GRG1YSmxuR+UM63jUnQV6d1+Pw9t l1rqIJXSX+4OmdyDrgib6jUTpPT+7dAfFR2zQ3p3qT4/GmGSvujXyiSCM4Ula78X1Zpp QN6rcJAtNmIKiTvhin9zw9WAOsX4Ikxnid58MIoglMlYtihZie1/LqUNDMV1doA/B/Fo KSuCnjSvcynoaMgQhRd3YI/xztguGndtzohalS+IFA9+4xa0NhAXZ1LPp998qWcN8p+u IDVA== X-Received: by 10.49.101.74 with SMTP id fe10mr17699608qeb.11.1370626265334; Fri, 07 Jun 2013 10:31:05 -0700 (PDT) MIME-Version: 1.0 Sender: cromis@gmail.com Received: by 10.49.106.228 with HTTP; Fri, 7 Jun 2013 10:30:44 -0700 (PDT) In-Reply-To: References: <51AF8479.5080002@crockford.com> <51b1168c.e686440a.5339.5fc4SMTPIN_ADDED_BROKEN@mx.google.com> From: Jacob Davies Date: Fri, 7 Jun 2013 10:30:44 -0700 X-Google-Sender-Auth: 2ZZOvyvBTRmQOLtUH4-SfK8sz7c Message-ID: To: R S Content-Type: text/plain; charset=ISO-8859-1 Cc: Nico Williams , Markus Lanthaler , "json@ietf.org" Subject: Re: [Json] The names within an object SHOULD be unique. X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 07 Jun 2013 17:31:06 -0000 On Thu, Jun 6, 2013 at 7:59 PM, R S wrote: > The text from RFC 4627 should stay unchanged. The suggestions for > requirements on encoders are prescriptive and therefore inaccurate at this > stage in JSON's adoption. +1 I don't think there is anything you can do about this in the specification except give the doctor's advice: "Don't do that." It is better to leave the behavior unspecified and advise against using it than to try to specify some one way of handling it that can't be relied on in the real world. From cromis@gmail.com Fri Jun 7 10:33:22 2013 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 78FD821F8F5C for ; Fri, 7 Jun 2013 10:33:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RzYK4XdIMIlv for ; Fri, 7 Jun 2013 10:33:22 -0700 (PDT) Received: from mail-qa0-x22f.google.com (mail-qa0-x22f.google.com [IPv6:2607:f8b0:400d:c00::22f]) by ietfa.amsl.com (Postfix) with ESMTP id E5D9621F8F0C for ; Fri, 7 Jun 2013 10:33:21 -0700 (PDT) Received: by mail-qa0-f47.google.com with SMTP id i13so1054028qae.20 for ; Fri, 07 Jun 2013 10:33:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=lp0xq85PJqaU9kuBDM+jjIgNfLBbspKDv+qdMvJF6dI=; b=gN23VYDc+rl6cq4tKGkjmwkb5kiAsLTqcJtIBlaCdpV/g0Sgv8V394AX+PI/zvs0gp nuS3/KP+0CGiNeWMtKe3zgIWSxkhXgpCOKKT9rXXMIa6VD9gKyrnhkwK+L4KeDGtVTwq xrH9mRh/eOICSzhIdGTZfb6SFQgqpJmMk5QeCilZZDs6sTTClG63f9xSssO/KX8ls8fH GIoEO77t+Kx/s0DRl4sUWnN5UscUZ0UO2w1pXEOhwghX0M0ttN/Fz+sZM8P9rou/tH6V r+wk+D2V7bOyk/xtgrsuhGALegqmex0V9gyjJGGx5idccKiyV9+r8c+6GxLA6MPcxXsH Lb5Q== X-Received: by 10.49.96.104 with SMTP id dr8mr48504439qeb.43.1370626401430; Fri, 07 Jun 2013 10:33:21 -0700 (PDT) MIME-Version: 1.0 Sender: cromis@gmail.com Received: by 10.49.106.228 with HTTP; Fri, 7 Jun 2013 10:33:01 -0700 (PDT) In-Reply-To: <3B4E7F65-B9B9-4C95-B077-D178B8DD8216@vpnc.org> References: <255B9BB34FB7D647A506DC292726F6E1151B21F9A9@WSMSG3153V.srv.dir.telstra.com> <3B4E7F65-B9B9-4C95-B077-D178B8DD8216@vpnc.org> From: Jacob Davies Date: Fri, 7 Jun 2013 10:33:01 -0700 X-Google-Sender-Auth: St8RbA2t8APSaRpUfiuQ-7In71w Message-ID: To: Paul Hoffman Content-Type: text/plain; charset=ISO-8859-1 Cc: "json@ietf.org" Subject: Re: [Json] Allow any JSON value at the top level X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 07 Jun 2013 17:33:22 -0000 On Fri, Jun 7, 2013 at 8:40 AM, Paul Hoffman wrote: > +1 to this, and to removing the "how to tell if you are looking at a JSON text" from the parser section. That rule is fragile and not useful. > > I am interested to hear examples of where this change would cause breakage, particularly given that ECMAScript already has this rule. +1 So do many parsers. Since parsers can reject values they don't like, I don't think this will cause breakage (parsers that reject non-object/non-array values are still compliant, they just aren't interested in your part of the value space). This would just allow what lots of people do already with no apparent harm. From tbray@textuality.com Fri Jun 7 10:34:14 2013 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 2619821F8F5C for ; Fri, 7 Jun 2013 10:34:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.714 X-Spam-Level: X-Spam-Status: No, score=-1.714 tagged_above=-999 required=5 tests=[AWL=1.262, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jpxUABlYW-Tu for ; Fri, 7 Jun 2013 10:34:09 -0700 (PDT) Received: from mail-vc0-f170.google.com (mail-vc0-f170.google.com [209.85.220.170]) by ietfa.amsl.com (Postfix) with ESMTP id 3D17921F955A for ; Fri, 7 Jun 2013 10:34:09 -0700 (PDT) Received: by mail-vc0-f170.google.com with SMTP id hf12so2975129vcb.15 for ; Fri, 07 Jun 2013 10:34:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=EByY7aH5/yYCZo079509YM/HsEb1breSpgk6OBTYjcg=; b=NHLwrVgwpZvl5kVhuKSeWnNcNmkhyOUGPSdUzgsLQ+hRWNAjJ70GZix+3DRZQ9tiQl io4Nm0/OioGB9cwreEPldHqCI0I2k6wr8y/fogXU9svSJkF/LotnJETvGrCpCBCvRJXr 1z4E+iyMWTDhis4JoilvngvQtTD9u0WnWSTDHCwav9y8sRmE0Ih6NQBRdZMGB4v2CkoE jYmxQwybBJJ7aOhlji1hwAXgR1vEWtPOHYpqULqwczmEmrXtUCjIMd8XAO8Yt/QSIOY+ 2tXEfmfLWpQnaSwMNTNwy3B418qReD9253ZxOtMbEGVF4UuHNAXKMAos5lS+Rd3fP6ru Q9XQ== MIME-Version: 1.0 X-Received: by 10.58.6.141 with SMTP id b13mr1308090vea.45.1370626448546; Fri, 07 Jun 2013 10:34:08 -0700 (PDT) Received: by 10.220.48.14 with HTTP; Fri, 7 Jun 2013 10:34:08 -0700 (PDT) X-Originating-IP: [96.49.81.176] In-Reply-To: References: <51AF8479.5080002@crockford.com> <51b1168c.e686440a.5339.5fc4SMTPIN_ADDED_BROKEN@mx.google.com> Date: Fri, 7 Jun 2013 10:34:08 -0700 Message-ID: From: Tim Bray To: Jacob Davies Content-Type: multipart/alternative; boundary=047d7b672c48976b9204de93d6b1 X-Gm-Message-State: ALoCoQkta9/+glcEm4Gk7uAFmArkd5t9VVelj77WSHcaOoxDVJtDyx1ZaH9DjP6cMn0lFINzSjss Cc: Nico Williams , "json@ietf.org" , Markus Lanthaler , R S Subject: Re: [Json] The names within an object SHOULD be unique. X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 07 Jun 2013 17:34:14 -0000 --047d7b672c48976b9204de93d6b1 Content-Type: text/plain; charset=UTF-8 +1 On Fri, Jun 7, 2013 at 10:30 AM, Jacob Davies wrote: > On Thu, Jun 6, 2013 at 7:59 PM, R S wrote: > > The text from RFC 4627 should stay unchanged. The suggestions for > > requirements on encoders are prescriptive and therefore inaccurate at > this > > stage in JSON's adoption. > > +1 > > I don't think there is anything you can do about this in the > specification except give the doctor's advice: "Don't do that." It is > better to leave the behavior unspecified and advise against using it > than to try to specify some one way of handling it that can't be > relied on in the real world. > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > --047d7b672c48976b9204de93d6b1 Content-Type: text/html; charset=UTF-8
+1


On Fri, Jun 7, 2013 at 10:30 AM, Jacob Davies <jacob@well.com> wrote:
On Thu, Jun 6, 2013 at 7:59 PM, R S <sayrer@gmail.com> wrote:
> The text from RFC 4627 should stay unchanged. The suggestions for
> requirements on encoders are prescriptive and therefore inaccurate at this
> stage in JSON's adoption.

+1

I don't think there is anything you can do about this in the
specification except give the doctor's advice: "Don't do that." It is
better to leave the behavior unspecified and advise against using it
than to try to specify some one way of handling it that can't be
relied on in the real world.
_______________________________________________
json mailing list
json@ietf.org
https://www.ietf.org/mailman/listinfo/json

--047d7b672c48976b9204de93d6b1-- From cowan@ccil.org Fri Jun 7 10:41:59 2013 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 5A11421F8613 for ; Fri, 7 Jun 2013 10:41:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.31 X-Spam-Level: X-Spam-Status: No, score=-3.31 tagged_above=-999 required=5 tests=[AWL=0.289, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7bNcwGy2z3rt for ; Fri, 7 Jun 2013 10:41:55 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id 0483721F915B for ; Fri, 7 Jun 2013 10:41:55 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1Ul0fi-0001bd-0w; Fri, 07 Jun 2013 13:41:54 -0400 Date: Fri, 7 Jun 2013 13:41:54 -0400 From: John Cowan To: Jacob Davies Message-ID: <20130607174153.GG13569@mercury.ccil.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Cc: "Joe Hildebrand \(jhildebr\)" , "json@ietf.org" Subject: Re: [Json] The parts of JSON (a possible aid to discussion) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 07 Jun 2013 17:41:59 -0000 Jacob Davies scripsit: > I should have made the point regarding Unicode separately - speaking > of separating things - but that was that it is unnecessary to mention > Unicode anywhere except when discussing the interpretation of \u > escapes and in the discussion of the application/json media-type, and > that doing so in other places is a little confusing. (If I write a > JSON text on a whiteboard, am I using "Unicode characters"? This seems > like a map/territory issue - Unicode is a way of representing > characters as integers, but characters are the things under discussion > in the abstract model and textual language, not a particular mapping > of integers to characters.) +1 Note that Unicode actually provides two things: it maps every character to an integer v, called a Unicode scalar value, such that 0 <= v < 56320 or 56575 < v <= 1114111; and it provides a variety of mappings between Unicode scalar values and sequences of 8-bit, 16-bit, or 32-bit unsigned integers, called code units. This is the law; all else is commentary. -- John Cowan cowan@ccil.org http://ccil.org/~cowan [R]eversing the apostolic precept to be all things to all men, I usually [before Darwin] defended the tenability of the received doctrines, when I had to do with the [evolution]ists; and stood up for the possibility of [evolution] among the orthodox --thereby, no doubt, increasing an already current, but quite undeserved, reputation for needless combativeness. --T. H. Huxley From nico@cryptonector.com Fri Jun 7 10:52:24 2013 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 5D62D21F8994 for ; Fri, 7 Jun 2013 10:52:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SCeT5C1IeAVb for ; Fri, 7 Jun 2013 10:52:19 -0700 (PDT) Received: from homiemail-a35.g.dreamhost.com (caiajhbdccah.dreamhost.com [208.97.132.207]) by ietfa.amsl.com (Postfix) with ESMTP id BBB5221F8A68 for ; Fri, 7 Jun 2013 10:52:16 -0700 (PDT) Received: from homiemail-a35.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a35.g.dreamhost.com (Postfix) with ESMTP id DF9E55406F for ; Fri, 7 Jun 2013 10:52:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=jmub4OESUJKuuk2igX0X OhbJemk=; b=yScT15QXS4Cz9fR/CflGjyoX5XEwvMEOTKv0CMB2cilJWLhBWdGx KAkcVYsljwOGiKvuZc4REMhpsCgdv9+tVam9Ct5hJbT2nXxHtzc2SAWgjHbO4qI9 uXunYgipCW/1RixwbcVA7iEnHxXWpY92g6/34m32564vm78E5nzu1Q8= Received: from mail-wi0-f177.google.com (mail-wi0-f177.google.com [209.85.212.177]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a35.g.dreamhost.com (Postfix) with ESMTPSA id D05D754058 for ; Fri, 7 Jun 2013 10:52:07 -0700 (PDT) Received: by mail-wi0-f177.google.com with SMTP id ey16so1577558wid.4 for ; Fri, 07 Jun 2013 10:52:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=MrACdg6vWa2YcHnCtZ8yhetZCBZj8XaK+T4UfcVbHj4=; b=H5Gz743EhyYqZ70aCG1XMW17MytS0uqkpbDnL2kiUOT8pkuzeQgRZtkbljobfrqIkP JK5tBWJF4l0YcsppE3ZcNvdk9DfNXxCdcUG1+vDEC2FTr52VbkQiQCGToJzJEjvsNyVP tNiR3ci4groqUe1n5T6Mjo2TkjwJZQqubBlmpHcN2jolShbBCiMSiKtwY/pD1f10smZD SEtoqWQSDlNhiD+jGkG2PrwbTQReEDLUd3rjyhZlo4JlFJoavdWpRYO929nC6pQz4ytM 0+hrCjS5/PwUeiFF5bdpvPe+EbfXazePtClkQOjKmvxIzMtLZUN0lkebGCRB3NqnQ6kt KhCw== MIME-Version: 1.0 X-Received: by 10.181.12.1 with SMTP id em1mr2186990wid.4.1370627524518; Fri, 07 Jun 2013 10:52:04 -0700 (PDT) Received: by 10.216.63.136 with HTTP; Fri, 7 Jun 2013 10:52:04 -0700 (PDT) In-Reply-To: References: <20130606042921.GC1362@mercury.ccil.org> Date: Fri, 7 Jun 2013 12:52:04 -0500 Message-ID: From: Nico Williams To: "Joe Hildebrand (jhildebr)" Content-Type: text/plain; charset=UTF-8 Cc: Carsten Bormann , John Cowan , Paul Hoffman , "json@ietf.org" Subject: Re: [Json] Unpaired surrogates in JSON strings X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 07 Jun 2013 17:52:24 -0000 On Thu, Jun 6, 2013 at 1:59 AM, Joe Hildebrand (jhildebr) wrote: > On 6/5/13 10:29 PM, "John Cowan" wrote: > >>Carsten Bormann scripsit: >> >>> Code points can refer to those of the characters or those of the code >>> units (byte for UTF-8, etc.). >> >>Code points are (mathematical) integers corresponding to Unicode >>characters, though not all of them are assigned to characters. > > The intro to the Unicode standard makes this pretty clear: > > http://www.unicode.org/versions/Unicode6.2.0/ch01.pdf > > > This is why I wanted to decouple from a particular version of Unicode. If > the reference remained at version 4, for example, the word "character" > means that any code point not in that version of Unicode is not > technically legal JSON (although we know it will interop just fine in > practice, which is why it's pretty safe to do the update). We already know to allow the user of unassigned code points. We can't avoid having a normative reference to a Unicode version, if that was your goal. Nico -- From tsaloranta@gmail.com Fri Jun 7 10:54:56 2013 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 2703621F9968 for ; Fri, 7 Jun 2013 10:54:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.332 X-Spam-Level: X-Spam-Status: No, score=-2.332 tagged_above=-999 required=5 tests=[AWL=0.267, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7oHKADI6cFbR for ; Fri, 7 Jun 2013 10:54:55 -0700 (PDT) Received: from mail-we0-x22a.google.com (mail-we0-x22a.google.com [IPv6:2a00:1450:400c:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id EA81321F9954 for ; Fri, 7 Jun 2013 10:54:54 -0700 (PDT) Received: by mail-we0-f170.google.com with SMTP id w57so3370738wes.29 for ; Fri, 07 Jun 2013 10:54:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=D92M9jyR9EXavPx/DP0sdJTWQQq1NAy0CxGZ6WmkI0M=; b=oebWJ/+RyP7fuNWfDXSovmtDbznFaZRTbU7mW6JDMM6cv6rQ0Uu199FECB9AMxwcd8 vimVxSHp45CtQUr9nWR77fn5hsVqFJJhucmhfF1fWFILyjxyUWcVy4+eUla+iRqMB6y5 KWyyhSnaDJUL6GMTIKHQmH5QKwGn3ly7kk2GO6ntEdzsCwLAcu8u4xYIv9jBmPx7nP8b iIlvzmCgh8EZ4bjB3OhJJIQsiisnoZP250d0tWBV9hhUaMnffriwuo4f+Hm0joNkSXiu zjDIXybfJiaHTW1kSYSeVoZ/S6gtAtDOC2+ex/o8/eN/WP+PR9/IMEyfca8ZOU85mQQ/ PHnQ== MIME-Version: 1.0 X-Received: by 10.180.185.44 with SMTP id ez12mr2492645wic.7.1370627692647; Fri, 07 Jun 2013 10:54:52 -0700 (PDT) Received: by 10.227.97.6 with HTTP; Fri, 7 Jun 2013 10:54:52 -0700 (PDT) In-Reply-To: References: <255B9BB34FB7D647A506DC292726F6E1151B21F9A9@WSMSG3153V.srv.dir.telstra.com> Date: Fri, 7 Jun 2013 10:54:52 -0700 Message-ID: From: Tatu Saloranta To: Carsten Bormann Content-Type: multipart/alternative; boundary=001a11c22574bd5cf504de942024 Cc: "Manger, James H" , "json@ietf.org" Subject: Re: [Json] Allow any JSON value at the top level X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 07 Jun 2013 17:54:56 -0000 --001a11c22574bd5cf504de942024 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Jun 7, 2013 at 1:59 AM, Carsten Bormann wrote: > On Jun 7, 2013, at 05:51, "Manger, James H" < > James.H.Manger@team.telstra.com> wrote: > > > I propose allowing a JSON text to be any JSON value. > > > > A JSON text is a serialization of any JSON value. > > > > JSON-text = value > > Apart from the (intellectually nicely challenging, but practically > irrelevant) auto-detection thing, Irrelevant based on what? I thought this is what any half-decent JSON parser did; unless platform does not expose byte sequence as input, case for some scripting languages. I have written multiple parsers (json, xml) that do just this, and know that others exist as well. I don't know what leads to assumption of irrelevancy here, and it should be fully spelled out. one other result is that JSON texts no longer stream. RFC 4627 texts are > self-delimiting, the new ones wouldn't always be. Of course, if you want > to stream sequences of JSON texts, you could always limit those back to > arrays or maps ("objects"). > I don't see this as any less self-delimiting, although best-practices would probably dictate suggestion to add white space between root-level values. Which is what existing tools that allow this do, as expected. -+ Tatu +- --001a11c22574bd5cf504de942024 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, Jun 7, 2013 at 1:59 AM, Carsten Bormann <cabo@tzi.org= > wrote:
On Jun 7, 2013, at 05:51, "Manger, James H" <= ;James.H.Manger@team.tel= stra.com> wrote:

> I propose allowing a JSON text to be any JSON value.
>
> =A0 A JSON text is a serialization of any JSON value.
>
> =A0 JSON-text =3D value

Apart from the (intellectually nicely challenging, but practically ir= relevant) auto-detection thing,

Irrel= evant based on what? I thought this is what any half-decent JSON parser did= ; unless platform does not expose byte sequence as input, case for some scr= ipting languages.
I have written multiple parsers (json, xml) that do just this, a= nd know that others exist as well.

I d= on't know what leads to assumption of irrelevancy here, and it should b= e fully spelled out.

one other result is tha= t JSON texts no longer stream. =A0RFC 4627 texts are self-delimiting, the n= ew ones wouldn't always be. =A0Of course, if you want to stream sequenc= es of JSON texts, you could always limit those back to arrays or maps (&quo= t;objects").


I don't see this = as any less self-delimiting, although best-practices would probably dictate= suggestion to add white space between root-level values.

Which is what existing tools that allow this do, as ex= pected.

-+ Tatu +-=A0
=
--001a11c22574bd5cf504de942024-- From tsaloranta@gmail.com Fri Jun 7 10:56:22 2013 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 3318021F9989 for ; Fri, 7 Jun 2013 10:56:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.362 X-Spam-Level: X-Spam-Status: No, score=-2.362 tagged_above=-999 required=5 tests=[AWL=0.237, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P5J4VlBHKeS0 for ; Fri, 7 Jun 2013 10:56:21 -0700 (PDT) Received: from mail-wg0-x22d.google.com (mail-wg0-x22d.google.com [IPv6:2a00:1450:400c:c00::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 7B06121F9984 for ; Fri, 7 Jun 2013 10:56:19 -0700 (PDT) Received: by mail-wg0-f45.google.com with SMTP id n12so3435490wgh.24 for ; Fri, 07 Jun 2013 10:56:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=B8IF1feOT/7BVMPKPP4zq/aZqjyQrmdlbEHUr++YAp4=; b=UGx7StNq1vjFG681IV4f4dNDyKUOvmtQKcK+akTVNW3oAN2M7WcwVPJ36P99OfhE3e aPCtF9IItcPaWdWEo0g6YfuYHRCpot0IdHB9SEY1U9XUw7hb+BHPbUGSVlkxbHBc6QA/ 1Ie4kznZTJ9+m/MdR2hL30KE3hExhE5IPfSOEJSf+k04ZGK8ow6XspQ1D7DxX8Ivm/3e 3TDFGGr88F/nYxNUGMejdWpmlb5q3GRxqKnoqmpK6LGMjnQuMRNa0mh2HqhNqGhwljd6 2JZivwXNVCecrC0p02YEVZDYbh+BMC5IPNt+lbprxbA0mcQytGrO6bOZQmTKrDioKUJr IfWA== MIME-Version: 1.0 X-Received: by 10.180.206.70 with SMTP id lm6mr1386870wic.50.1370627778549; Fri, 07 Jun 2013 10:56:18 -0700 (PDT) Received: by 10.227.97.6 with HTTP; Fri, 7 Jun 2013 10:56:18 -0700 (PDT) In-Reply-To: References: <255B9BB34FB7D647A506DC292726F6E1151B21F9A9@WSMSG3153V.srv.dir.telstra.com> Date: Fri, 7 Jun 2013 10:56:18 -0700 Message-ID: From: Tatu Saloranta To: Vinny A Content-Type: multipart/alternative; boundary=001a11c265bedc1f5d04de9425df Cc: Carsten Bormann , "Manger, James H" , "json@ietf.org" Subject: Re: [Json] Allow any JSON value at the top level X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 07 Jun 2013 17:56:22 -0000 --001a11c265bedc1f5d04de9425df Content-Type: text/plain; charset=ISO-8859-1 On Fri, Jun 7, 2013 at 6:38 AM, Vinny A wrote: > > On Jun 7, 2013, at 3:59 AM, Carsten Bormann wrote: > > Apart from auto-detection, one other result is that JSON texts no longer > stream. RFC 4627 texts are self-delimiting, the new ones wouldn't always > be. Of course, if you want to stream sequences of JSON texts, you could > always limit those back to arrays or maps > > I'm +0 on this topic, partly for Carsten's reason, but also because this > looks to be a breaking change. > > Do commonly used parsers support top level JSON values > Yes, at least on Java platform. Follow-up question would be whether use cases exist for sending root-level non-structured values: that I do not know. I do know that some JSON validators struggle with this question (should it be allowed but flagged or marked as error); and that suggests that usage exists. -+ Tatu +- --001a11c265bedc1f5d04de9425df Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, Jun 7, 2013 at 6:38 AM, Vinny A = <jsontest@yahoo.= com> wrote:

On Jun 7, 2013, at 3:59 AM, Carsten Bormann <cabo@tzi.org> wrote:
> Apart from auto-detection, one other result is that JSON texts no long= er stream. =A0RFC 4627 texts are self-delimiting, the new ones wouldn't= always be. =A0Of course, if you want to stream sequences of JSON texts, yo= u could always limit those back to arrays or maps

I'm +0 on this topic, partly for Carsten's reason, but also because= this looks to be a breaking change.

Do commonly used parsers support top level JSON values


Yes, at least on Java platform.
<= div style>
Follow-up question would be whether use case= s exist for sending root-level non-structured values: that I do not know. I= do know that some JSON validators struggle with this question (should it b= e allowed but flagged or marked as error); and that suggests that usage exi= sts.

-+ Tatu +-
=A0
<= /div> --001a11c265bedc1f5d04de9425df-- From nico@cryptonector.com Fri Jun 7 11:09:54 2013 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 D545021F9950 for ; Fri, 7 Jun 2013 11:09:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kcGjwzfjSqYy for ; Fri, 7 Jun 2013 11:09:49 -0700 (PDT) Received: from homiemail-a25.g.dreamhost.com (caiajhbdccac.dreamhost.com [208.97.132.202]) by ietfa.amsl.com (Postfix) with ESMTP id C769721F994F for ; Fri, 7 Jun 2013 11:09:49 -0700 (PDT) Received: from homiemail-a25.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a25.g.dreamhost.com (Postfix) with ESMTP id E5A0C678063 for ; Fri, 7 Jun 2013 11:09:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=9TYD84NnoqlQqiW1m8hI s0SjmdE=; b=KIXQ+pdnLt85nb7dCDmTsUgFLRWRkzslZckfclP9lsDVgKSJWds4 tU8qUB0X+WXD8B+AWRqP5XoUzOE2v9ryosHTAutzc25SFGkSQBOCVwl2q/GBt3/3 9wy5UCWepo43hMlecmyO+9AOIjt9MIg6rjLueiT//dkyZydrENMZrgc= Received: from mail-wi0-f177.google.com (mail-wi0-f177.google.com [209.85.212.177]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a25.g.dreamhost.com (Postfix) with ESMTPSA id 8871D67803E for ; Fri, 7 Jun 2013 11:09:48 -0700 (PDT) Received: by mail-wi0-f177.google.com with SMTP id ey16so1589411wid.16 for ; Fri, 07 Jun 2013 11:09:47 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=fweog52hrYsyjjwScVjtM1j4voWO45wEFk7b506kCUA=; b=G96fXj6I4BmfTlKdA0v9OafQDC7WWfL267a/nZ2UwLz9LmE82Hl8zpqesi74qucgug Q4ScECQxnkOTmxYCX/4CtK0Z2UO9b1YG/RpOZm3W9ArsEnx4qJCebkjXa14eQ1B9qyiM tC71/FqF9iKfic6E4hr5t52vsqgCtdR+qypicxWFeUnRex2dvPSzxkHlGU38XHJDRzNY rm/E/Q/nj0IGV1ya5dAEdPcyWdSRSsBS6j3CVSy0ykVTp8Twpgrw1vrWL51vRSiBLFkB QUuskgykWvt761M5jBWELpqhHJF3UzBN+rV+G+zhYBj8fG8HHktvsmsWKVL73pbR2zLX hCTQ== MIME-Version: 1.0 X-Received: by 10.194.79.74 with SMTP id h10mr4978625wjx.84.1370628587165; Fri, 07 Jun 2013 11:09:47 -0700 (PDT) Received: by 10.216.63.136 with HTTP; Fri, 7 Jun 2013 11:09:47 -0700 (PDT) In-Reply-To: <9ld3r8pc0tufif18dohb2fmi0ijna1vs4n@hive.bjoern.hoehrmann.de> References: <51B06F38.8050707@crockford.com> <51B1B4E7.8090101@it.aoyama.ac.jp> <9ld3r8pc0tufif18dohb2fmi0ijna1vs4n@hive.bjoern.hoehrmann.de> Date: Fri, 7 Jun 2013 13:09:47 -0500 Message-ID: From: Nico Williams To: Bjoern Hoehrmann Content-Type: text/plain; charset=UTF-8 Cc: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= , "json@ietf.org" Subject: Re: [Json] Unpaired surrogates in JSON strings X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 07 Jun 2013 18:09:55 -0000 On Fri, Jun 7, 2013 at 5:42 AM, Bjoern Hoehrmann wrote: > Actually there are many good reasons for having unpaired surrogates in > JSON documents. A simple example would be a test suite for string APIs. Or what heck, if ECMAScript allows any 16-bit values, 0x0000..0xFFFF to be used (escaped as \uXXXX if necessary) then one very useful use of that is encoding binary data: when parsing you know if you have binary data when you see any 16-bit code units that don't make any sense in Unicode text. Not that I'm advocating this... but if we did allow this then it wouldn't preclude us from saying that a string of text must not include unpaired surrogates. Nico -- From tsaloranta@gmail.com Fri Jun 7 11:15:56 2013 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 53A6E21F9951 for ; Fri, 7 Jun 2013 11:15:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.386 X-Spam-Level: X-Spam-Status: No, score=-2.386 tagged_above=-999 required=5 tests=[AWL=0.213, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9alNQx+TOECr for ; Fri, 7 Jun 2013 11:15:55 -0700 (PDT) Received: from mail-wg0-x22d.google.com (mail-wg0-x22d.google.com [IPv6:2a00:1450:400c:c00::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 117C121F96C6 for ; Fri, 7 Jun 2013 11:15:47 -0700 (PDT) Received: by mail-wg0-f45.google.com with SMTP id n12so3345053wgh.0 for ; Fri, 07 Jun 2013 11:15:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=LVDp4NsqAQMVCOxHbfWFDJMbML1aY9/VllZyAUNqZoU=; b=kayb+vlm4b9P1H3OwoRDW0fiW6bK3vKn8jfy9T1u3/igIjaDiKw4lA3XSWhq5S26F6 kRzBUGvOO7SRKbMaSdDyyyK4clMV14MF6WGq2IlU8PsLEG7sjx7rNKwdNeA5AMG21ECc cZWTmlRsFhqUU4vcacZUpMaswTcKB88O2Ps4tl32D2tfZqqLQfm2bcCUCqZyJt7qnvcj tYcqBKWGLrqOSt3EAY6sz2y3aocMiiLL2KCcAR6AWnOt+dPS+UZ7DKxieF5BRLL9sYPB QlNtRnFkOQfZ+CyjMyy14LKacGsf+hUY6REUUACYAqFlF8UKYcM+9CRTEDXIgBfp7D8c C6Pw== MIME-Version: 1.0 X-Received: by 10.194.134.73 with SMTP id pi9mr36684970wjb.38.1370628947178; Fri, 07 Jun 2013 11:15:47 -0700 (PDT) Received: by 10.227.97.6 with HTTP; Fri, 7 Jun 2013 11:15:47 -0700 (PDT) In-Reply-To: References: <51B06F38.8050707@crockford.com> <51B1B4E7.8090101@it.aoyama.ac.jp> <9ld3r8pc0tufif18dohb2fmi0ijna1vs4n@hive.bjoern.hoehrmann.de> Date: Fri, 7 Jun 2013 11:15:47 -0700 Message-ID: From: Tatu Saloranta To: Nico Williams Content-Type: multipart/alternative; boundary=e89a8f3ba28b83fc3404de946ba4 Cc: =?ISO-8859-1?Q?Martin_J=2E_D=FCrst?= , Bjoern Hoehrmann , "json@ietf.org" Subject: Re: [Json] Unpaired surrogates in JSON strings X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 07 Jun 2013 18:15:56 -0000 --e89a8f3ba28b83fc3404de946ba4 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Jun 7, 2013 at 11:09 AM, Nico Williams wrote: > On Fri, Jun 7, 2013 at 5:42 AM, Bjoern Hoehrmann > wrote: > > Actually there are many good reasons for having unpaired surrogates in > > JSON documents. A simple example would be a test suite for string APIs. > > Or what heck, if ECMAScript allows any 16-bit values, 0x0000..0xFFFF > to be used (escaped as \uXXXX if necessary) then one very useful use > of that is encoding binary data: when parsing you know if you have > binary data when you see any 16-bit code units that don't make any > sense in Unicode text. Not that I'm advocating this... but if we did > allow this then it wouldn't preclude us from saying that a string of > text must not include unpaired surrogates. Not really. Since most content is exchanged as UTF-8, it gives you 3-to-2 conversion, which is no better than Base64 (4-to-3), nor necessarily any faster. It would only help when using UTF-16. APIs would expose this as text, requiring conversion or coercion (depending on platform), so it would not even be a short-cut. -+ Tatu +- --e89a8f3ba28b83fc3404de946ba4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, Jun 7, 2013 at 11:09 AM, Nico Williams <nic= o@cryptonector.com> wrote:
On Fri, Jun 7, 2013 at 5:4= 2 AM, Bjoern Hoehrmann <derhoermi@g= mx.net> wrote:
> Actually there are many good reasons for having unpaired surrogates in=
> JSON documents. A simple example would be a test suite for string APIs= .

Or what heck, if ECMAScript allows any 16-bit values, 0x0000..0xFFFF<= br> to be used (escaped as \uXXXX if necessary) then one very useful use
of that is encoding binary data: when parsing you know if you have
binary data when you see any 16-bit code units that don't make any
sense in Unicode text. =A0Not that I'm advocating this... but if we did=
allow this then it wouldn't preclude us from saying that a string of text must not include unpaired surrogates.

Not really. Since most content is exchanged as UTF-8, it gives you 3-= to-2 conversion, which is no better than Base64 (4-to-3), nor necessarily a= ny faster. It would only help when using UTF-16.
APIs would expose this as text, requiring conversion or coercion= (depending on platform), so it would not even be a short-cut.

-+ Tatu +-
=A0
--e89a8f3ba28b83fc3404de946ba4-- From jsontest@yahoo.com Fri Jun 7 11:24:15 2013 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 C223C21F96ED for ; Fri, 7 Jun 2013 11:24:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.119 X-Spam-Level: X-Spam-Status: No, score=-0.119 tagged_above=-999 required=5 tests=[AWL=1.083, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NvKs6C-H0rej for ; Fri, 7 Jun 2013 11:24:09 -0700 (PDT) Received: from nm29-vm1.bullet.mail.bf1.yahoo.com (nm29-vm1.bullet.mail.bf1.yahoo.com [98.139.213.144]) by ietfa.amsl.com (Postfix) with ESMTP id DC68321F96EC for ; Fri, 7 Jun 2013 11:24:08 -0700 (PDT) Received: from [98.139.212.150] by nm29.bullet.mail.bf1.yahoo.com with NNFMP; 07 Jun 2013 18:24:08 -0000 Received: from [98.139.211.202] by tm7.bullet.mail.bf1.yahoo.com with NNFMP; 07 Jun 2013 18:24:08 -0000 Received: from [127.0.0.1] by smtp211.mail.bf1.yahoo.com with NNFMP; 07 Jun 2013 18:24:08 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1370629448; bh=FoyphOlYJaXZp2SkoxHDjQUqT7WG0di8Y56vQPVRFbI=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:Subject:References:Cc:From:Content-Type:In-Reply-To:Message-Id:Date:To:Content-Transfer-Encoding:Mime-Version:X-Mailer; b=3wcjol6HFsmyWXLi5Dbc3kDLtreygZx96SG0Q19ZGUDvHf7YOr0BU4pts/jqZ+b2bOPMGbkKFPrJXOvFcgwA8KOy+mSRr6mH5D7iXXTVAdK8raadeuA1WCG0NXJP6WWzwiiy+dOfs6SppHRlOgzndqQWAzExkCpfuS1jc6HzgEQ= X-Yahoo-Newman-Id: 203158.22713.bm@smtp211.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: HHbGYvMVM1k_kpxiXYSiiDPsTkH7zSoZ.UEJN.MHUgegDce CGlXjoutq14UJ.GVETWA2lsjQkxJQdHmAWoqurNi3Yf0kBFfl93.z20ndRQG _QFBZ9hdWs9UEm0iBAYI_1xju_MVuv5wojFSXLviDtWnQRo.fWKpvc.J5VFf 8ewKARPulhROShSydzXnU3Ly6eApMmnLwB81WYZuSRbvMYQnLcIJqBjOah_0 gU9dCFfETDlCa4HiRfHqw5GSwgVCa_CZIABARhDUB0sEsl.U.RYr7e30el7u G_LsBBQ2sftm8tpCOySAYAr..zleYV2wDoEuLVm73Ep_e8_aZztSnMoztAXB edwtQt5JQMHUNqTTX0L1J2XSdhqy8maZYvQpB7sKpyvKm.gMZKnHL81Xp8ja 6ATwOElYNLLo2pxjrHChgHF3w4JMya_VqMn9.stcjwTknss2fKkPGWpLeNJB _sa_ITL6Nzmd_7XIZPVHrr2S9EUh3Jn9i9TFPJ1_s_y6W84ZtpkGtx0cRflX 3ndAHuoGaxWCz6yh6Nm_NQTtsgg-- X-Yahoo-SMTP: indQcmSswBC8IKsm6t4aCAPskK3T X-Rocket-Received: from [192.168.10.95] (jsontest@64.134.39.87 with ) by smtp211.mail.bf1.yahoo.com with SMTP; 07 Jun 2013 11:24:08 -0700 PDT References: <51AF8479.5080002@crockford.com> <51AF9ACF.5020507@cisco.com> <51AFB3F8.8060708@crockford.com> <8F32953C-C788-4DC9-888E-920E2BEB7FDD@yahoo.com> <831B8E46-F239-4353-8F95-8DF3F9BD2E78@yahoo.com> <51AFC924.2030805@crockford.com> From: Vinny A Content-Type: multipart/alternative; boundary=Apple-Mail-CD366FD4-314A-4C09-80B3-8E75969346C4 In-Reply-To: Message-Id: <8E679529-8663-4552-A905-529E732AEB7B@yahoo.com> Date: Fri, 7 Jun 2013 12:43:15 -0500 To: Allen Wirfs-Brock Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (1.0) X-Mailer: iPod Mail (9B206) Cc: Paul Hoffman , "json@ietf.org" Subject: Re: [Json] The names within an object SHOULD be unique. X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 07 Jun 2013 18:24:15 -0000 --Apple-Mail-CD366FD4-314A-4C09-80B3-8E75969346C4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jun 6, 2013, at 12:45 PM, Allen Wirfs-Brock wrote= : > Allen Wirfs-Brock > ECMAScript Language Spec. Project Editor > What I would say, as a replacement for the current text
is:= >=20 > The names within an object SHOULD be unique. If a key is duplicat= ed, a parser MUST take <> only the last of the duplicate= d key pairs. Just to be clear here, ECMA is OK with using MUST in regards to the last key= pair? =20 Because we already have proposed language that says that, but one of the poi= nts under contention on this list is what to do with duplicated key pairs. Is the following language acceptable to ECMA (disclaimer: original text by P= aul, modifications by me): On Jun 6, 2013, at 10:24 AM, Paul Hoffman wrote: > The new text should use language that is already in RFC 4627; "key" is not= such a word. To be fair to implementers, the new document also needs to dea= l with both emitters and parsers. >=20 > Proposal: >=20 > In Section 2.2: > Current: > The names within an object SHOULD be unique. > Proposed: > If the names within an object are not unique, the result of parsing the=20= > object is unpredictable, and the parse may even fail completely. Thus, > the names within an object SHOULD be unique. >=20 > In Section 4, add a new paragraph: > If a parser encounters an object with duplicate names, the parser MAY > fail to parse the JSON text; if the parser accepts objects with duplicat= e > names, it SHOULD accept only the last name/value pair that has the > duplicate name.=20 If we have to recommend to both parsers and emitters, I'd like to make a sli= ght change to your wording: In Section 2.2: Current: The names within an object SHOULD be unique. Proposed: The names within an object SHOULD be unique. Non-unique names have unpred= ictable effects (refer to sections 4 & 5). In Section 4 (Parsers) add a new paragraph: If a parser encounters an object with duplicate names, the parser MAY fail= to parse the JSON text; if the parser accepts objects with duplicate names,= it MUST accept only the last name/value pair that has the duplicate name.=20= In Section 5 (Generators) add a new paragraph: A JSON generator SHOULD not duplicate names. If duplicate names are gener= ated, the authoritative name/value pair MUST be listed last. ----------------- Vinny www.jsontest.com --Apple-Mail-CD366FD4-314A-4C09-80B3-8E75969346C4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8


On Jun 6, 2013, at 12:45 PM, Allen Wirfs-Brock <allen@wirfs-brock.com> wrote:
Allen Wirfs-Brock
ECMAScript Language Spec. Project Editor

What I wo= uld say, as a replacement for the current text  <section 2.2> is:=

      &nb= sp; The names within an object SHOULD be unique.  If a key is dupl= icated, a parser MUST take  <<use?? interpret??>> only the l= ast of the duplicated key pairs.

Just to be clear here, ECMA is OK with using MUST in regards to the last k= ey pair?  

Because we already have pro= posed language that says that, but one of the points under contention on thi= s list is what to do with duplicated key pairs.

<= span>Is the following language acceptable to ECMA (disclaimer: original text= by Paul,  modifications by me):


=
On Jun 6, 2013, at 10:24 AM, Paul Hoffman <paul.hoffman@vpnc.org> wrote:
<= blockquote type=3D"cite">
The new text should use language that is already in RFC 4627; "ke= y" is not such a word. To be fair to implementers, the new document also nee= ds to deal with both emitters and parsers.

= Proposal:

In Section 2.2:
C= urrent:
  The names within an object SHOULD be uni= que.
Proposed:
  If the names with= in an object are not unique, the result of parsing the 
  object is unpredictable, and the parse may even fail completely= . Thus,
  the names within an object SHOULD be uni= que.

In Section 4, add a new paragraph:
  If a parser encounters an object with duplicate nam= es, the parser MAY
  fail to parse the JSON text; i= f the parser accepts objects with duplicate
  name= s, it SHOULD accept only the last name/value pair that has the
  duplicate name. 
<= /span>
If we have to recommend to both parsers and emitters, I'd li= ke to make a slight change to your wording:

In Section 2.2:
Current:
    = ;The names within an object SHOULD be unique.
Proposed:
   The names within an object SHOULD be u= nique. Non-unique names have unpredictable effects (refer to sections 4 &= ; 5).

In Section 4 (Parsers) add a new p= aragraph:
  If a parser encounters an object wi= th duplicate names, the parser MAY fail to parse the JSON text; if the p= arser accepts objects with duplicate names, it MUST accept only the las= t name/value pair that has the duplicate name. 

In Section 5 (Generators) add a new paragraph:
   A JSON generator SHOULD not duplicate names. If duplicate n= ames are generated, the authoritative name/value pair MUST be listed last.


-------------= ----
Vinny
www.jsontest.com
= --Apple-Mail-CD366FD4-314A-4C09-80B3-8E75969346C4-- From jhildebr@cisco.com Fri Jun 7 11:27:51 2013 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 0DE0F21F8617 for ; Fri, 7 Jun 2013 11:27:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4GTckn3fxrdh for ; Fri, 7 Jun 2013 11:27:44 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 373BE21F9928 for ; Fri, 7 Jun 2013 11:27:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=819; q=dns/txt; s=iport; t=1370629664; x=1371839264; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=l6rssFWD62jP+ChqofoDcKeAci4dt1FEMV+uZiH+FrI=; b=AHwFa/uZ3bXLeBM2nNLaEONaRJ9irn93gIYrVhEuc6YRD6N5MnQ4jheu F126aWboqRqyGsoyiCPFqftfArw4iYIJrC/ukU8BYmFuk94sSZgxx1bn9 X2SOZJcBLn6ILExg+VW7n9Aylo2aGFdYu1yB6JttJZiAYftAP8Ix+WHhT o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqUFAE0lslGtJV2Z/2dsb2JhbABZgwmDJbt6gQAWdIIjAQEBAwE6PxIBCCIUQiUCBA4FCId/Brx7jwcxB4J7YQOpAoMPgic X-IronPort-AV: E=Sophos;i="4.87,824,1363132800"; d="scan'208";a="220181812" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-5.cisco.com with ESMTP; 07 Jun 2013 18:27:43 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r57IRhqb030798 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 7 Jun 2013 18:27:43 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.56]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.02.0318.004; Fri, 7 Jun 2013 13:27:43 -0500 From: "Joe Hildebrand (jhildebr)" To: Nico Williams Thread-Topic: [Json] Unpaired surrogates in JSON strings Thread-Index: AQHOYgjwaH+sWe/75UqTmsr195d0xpknuQ0AgAAQ1ACAAALZgP//6RgAgAB73ICAADeTgIAAA1OA///FRgCAAq1WAP//pV6A Date: Fri, 7 Jun 2013 18:27:42 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [64.101.72.72] Content-Type: text/plain; charset="us-ascii" Content-ID: <3BEC2CB0C28A5241BC68097BDEE32902@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Carsten Bormann , John Cowan , Paul Hoffman , "json@ietf.org" Subject: Re: [Json] Unpaired surrogates in JSON strings X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 07 Jun 2013 18:27:51 -0000 On 6/7/13 11:52 AM, "Nico Williams" wrote: >> This is why I wanted to decouple from a particular version of Unicode. >>If >> the reference remained at version 4, for example, the word "character" >> means that any code point not in that version of Unicode is not >> technically legal JSON (although we know it will interop just fine in >> practice, which is why it's pretty safe to do the update). > >We already know to allow the user of unassigned code points. We can't >avoid having a normative reference to a Unicode version, if that was >your goal. "character" implies "assigned", I think. We need a Unicode ref, and we need to ensure that the text allows the use of code points unassigned in that version we refer to, which isn't clear in 4627. --=20 Joe Hildebrand From derhoermi@gmx.net Fri Jun 7 11:40:55 2013 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 AD84B21F9948 for ; Fri, 7 Jun 2013 11:40:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, J_CHICKENPOX_14=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PBgZgxn2fsJK for ; Fri, 7 Jun 2013 11:40:51 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) by ietfa.amsl.com (Postfix) with ESMTP id 5E3BF21F8D0D for ; Fri, 7 Jun 2013 11:40:51 -0700 (PDT) Received: from mailout-de.gmx.net ([10.1.76.20]) by mrigmx.server.lan (mrigmx002) with ESMTP (Nemesis) id 0LfDpm-1U0wKA1irw-00on2a for ; Fri, 07 Jun 2013 20:40:50 +0200 Received: (qmail invoked by alias); 07 Jun 2013 18:40:50 -0000 Received: from p5B2339AC.dip0.t-ipconnect.de (EHLO netb.Speedport_W_700V) [91.35.57.172] by mail.gmx.net (mp020) with SMTP; 07 Jun 2013 20:40:50 +0200 X-Authenticated: #723575 X-Provags-ID: V01U2FsdGVkX1+mbUEBOQCmXU+1aH5YS39VuZ0wRcx6KVTtxPdT67 oLwJzjB4EehZzl From: Bjoern Hoehrmann To: Stephen Dolan Date: Fri, 07 Jun 2013 20:40:51 +0200 Message-ID: References: <51B06F38.8050707@crockford.com> <51B1B4E7.8090101@it.aoyama.ac.jp> <9ld3r8pc0tufif18dohb2fmi0ijna1vs4n@hive.bjoern.hoehrmann.de> <56A163E9-E7CD-46B3-9984-8F009EBFF500@vpnc.org> In-Reply-To: X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 Cc: Paul Hoffman , "json@ietf.org" Subject: Re: [Json] On characters and code points X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 07 Jun 2013 18:40:55 -0000 * Stephen Dolan wrote: >(3) includes such beasts as U+FFFE (which you can only get by reading >a UTF16 byte order mark with the wrong byte order). The set (1) >increases with every Unicode revision to include characters from (2), >but (3) is stable (see >http://unicode.org/policies/stability_policy.html). >I think JSON should allow characters from (1) and (2) to avoid being >dependent on a specific Unicode revision. I do not think (3) should be >allowed - this would cause problems with many existing parsers which >represent JSON strings using another system's native unicode >representation. Please see . -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ From petejson@codalogic.com Fri Jun 7 11:41:36 2013 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 2912B21F9948 for ; Fri, 7 Jun 2013 11:41:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.667 X-Spam-Level: * X-Spam-Status: No, score=1.667 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_50=0.001, SARE_HEAD_XUNSENT=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DE-pEm4ROhge for ; Fri, 7 Jun 2013 11:41:30 -0700 (PDT) Received: from codalogic.com (codalogic.com [94.136.60.219]) by ietfa.amsl.com (Postfix) with ESMTP id DE37821F8793 for ; Fri, 7 Jun 2013 11:41:29 -0700 (PDT) Received: (qmail 23617 invoked from network); 7 Jun 2013 19:41:28 +0100 Received: from host86-169-212-62.range86-169.btcentralplus.com (HELO codalogic) (86.169.212.62) by codalogic.com with (RC4-MD5 encrypted) SMTP; 7 Jun 2013 19:41:28 +0100 Message-ID: <1650E434884344059BCABB683DA92C99@codalogic> From: "Pete Cordell" To: "Douglas Crockford" , References: <51B2109A.30506@crockford.com> Date: Fri, 7 Jun 2013 19:41:11 +0100 X-Unsent: 1 MIME-Version: 1.0 x-vipre-scanned: 00123EA700484A00123FF4 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Subject: Re: [Json] Comments by convention X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 07 Jun 2013 18:41:36 -0000 Original Message From: "Douglas Crockford" > On 6/7/2013 9:31 AM, Pete Cordell wrote: >> For example: >> >> "order": { >> "//": "An order item", >> "// description": "A short description of the item ordered", >> "description": "1TB HDD", >> "// price": "The price in USD", >> "price": 123.45 } >> >> How much goes up in smoke if we do that? > That belongs in the best practices document. OK. I'll try to remember to shake the tree then. Pete Cordell Codalogic Ltd From petejson@codalogic.com Fri Jun 7 11:41:36 2013 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 2E58821F994A for ; Fri, 7 Jun 2013 11:41:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.968 X-Spam-Level: * X-Spam-Status: No, score=1.968 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_50=0.001, J_CHICKENPOX_45=0.6, SARE_HEAD_XUNSENT=1.666, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ntgB4ibxbZHZ for ; Fri, 7 Jun 2013 11:41:30 -0700 (PDT) Received: from codalogic.com (codalogic.com [94.136.60.219]) by ietfa.amsl.com (Postfix) with ESMTP id DE4C421F8D0D for ; Fri, 7 Jun 2013 11:41:29 -0700 (PDT) Received: (qmail 23609 invoked from network); 7 Jun 2013 19:41:28 +0100 Received: from host86-169-212-62.range86-169.btcentralplus.com (HELO codalogic) (86.169.212.62) by codalogic.com with (RC4-MD5 encrypted) SMTP; 7 Jun 2013 19:41:28 +0100 Message-ID: <605DA80154A443DCA1B8A2D10F075FAD@codalogic> From: "Pete Cordell" To: "Vinny A" References: <641B1C79FB414811BCBDE8BE0FD165D6@codalogic> <32388664-98E4-4197-B4F1-2799E18AA429@yahoo.com> X-Unsent: 1 Date: Fri, 7 Jun 2013 19:38:32 +0100 MIME-Version: 1.0 x-vipre-scanned: 000FCF0E00484A000FD05B Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Cc: json@ietf.org Subject: Re: [Json] Comments by convention X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 07 Jun 2013 18:41:36 -0000 Original Message From: "Vinny A" > Adding to your proposal, I'd like it stated that comments are also first > class name:value data pairs; ie if I call (pseudo code): > > Jsonobject.get("// description"); > > Then I will get the value "A short description of the item ordered". > Obviously this is also backward compatible. Agreed. It seems a nice feature, and you basically get it for free. There's not many days you can say that! Pete. From tbray@textuality.com Fri Jun 7 11:49:42 2013 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 9809321F9950 for ; Fri, 7 Jun 2013 11:49:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.594 X-Spam-Level: X-Spam-Status: No, score=-1.594 tagged_above=-999 required=5 tests=[AWL=0.782, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zf0VE0ScPFi6 for ; Fri, 7 Jun 2013 11:49:38 -0700 (PDT) Received: from mail-vc0-f174.google.com (mail-vc0-f174.google.com [209.85.220.174]) by ietfa.amsl.com (Postfix) with ESMTP id 79B5121F994F for ; Fri, 7 Jun 2013 11:49:38 -0700 (PDT) Received: by mail-vc0-f174.google.com with SMTP id kw10so2958348vcb.19 for ; Fri, 07 Jun 2013 11:49:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=NpjdujwFZBdG7kJWoFZhJIp9xdjN75vDtu4yeFqnA4A=; b=de6LB5aVKFyhsR+HB0EBJz1pbS7+kZkjCfzJhZx3QYwaU3v8Y412v0GGZqxVM8UUMA G+HLpLeJzbFh2vqrj8VGXTXRTPnGgcAiWhLwRJKvjfhmYcG3e3hgohFLNSg0VxPCViNs wxNJH18GGGU2Vump+83H4W6iBS8+bnZq7J8+XfEMeTYukW02rz6G58oeE5D3W8xFWXv8 pvT1t8nbTx6NdtTFNGU4qqAcY59KuwXmJOx/yvlpmD7hLHH2U9MMH3JyIDnnxHdbGKFS fPPgrLxvdyK1BGN6A/4LLyICOofeaY2e1/OpziY5B0eK4RR5x34fCMMw/6HkxQxVzCm+ ed4w== MIME-Version: 1.0 X-Received: by 10.52.93.8 with SMTP id cq8mr6639836vdb.77.1370630977711; Fri, 07 Jun 2013 11:49:37 -0700 (PDT) Received: by 10.220.48.14 with HTTP; Fri, 7 Jun 2013 11:49:37 -0700 (PDT) X-Originating-IP: [96.49.81.176] In-Reply-To: References: <51B06F38.8050707@crockford.com> <51B1B4E7.8090101@it.aoyama.ac.jp> <9ld3r8pc0tufif18dohb2fmi0ijna1vs4n@hive.bjoern.hoehrmann.de> <56A163E9-E7CD-46B3-9984-8F009EBFF500@vpnc.org> Date: Fri, 7 Jun 2013 11:49:37 -0700 Message-ID: From: Tim Bray To: Bjoern Hoehrmann Content-Type: multipart/alternative; boundary=20cf307f3ad88bab8804de94e4ea X-Gm-Message-State: ALoCoQnupOCLuKm/WCREDfzitn+g+dtbcRNC+qkPIYXB8wg4Bq8aZIeNX5j/Eoxbiwp3VG5mVOMo Cc: Stephen Dolan , Paul Hoffman , "json@ietf.org" Subject: Re: [Json] On characters and code points X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 07 Jun 2013 18:49:42 -0000 --20cf307f3ad88bab8804de94e4ea Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Interestingly, that doesn=E2=80=99t mention surrogates. -T On Fri, Jun 7, 2013 at 11:40 AM, Bjoern Hoehrmann wrote= : > * Stephen Dolan wrote: > >(3) includes such beasts as U+FFFE (which you can only get by reading > >a UTF16 byte order mark with the wrong byte order). The set (1) > >increases with every Unicode revision to include characters from (2), > >but (3) is stable (see > >http://unicode.org/policies/stability_policy.html). > > >I think JSON should allow characters from (1) and (2) to avoid being > >dependent on a specific Unicode revision. I do not think (3) should be > >allowed - this would cause problems with many existing parsers which > >represent JSON strings using another system's native unicode > >representation. > > Please see . > -- > Bj=C3=B6rn H=C3=B6hrmann =C2=B7 mailto:bjoern@hoehrmann.de =C2=B7 http://= bjoern.hoehrmann.de > Am Badedeich 7 =C2=B7 Telefon: +49(0)160/4415681 =C2=B7 http://www.bjoern= sworld.de > 25899 Dageb=C3=BCll =C2=B7 PGP Pub. KeyID: 0xA4357E78 =C2=B7 http://www.w= ebsitedev.de/ > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > --20cf307f3ad88bab8804de94e4ea Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Interestingly, that doesn=E2=80=99t mention surrogates. -T=


On = Fri, Jun 7, 2013 at 11:40 AM, Bjoern Hoehrmann <derhoermi@gmx.net><= /span> wrote:
* Stephen Dolan wrote:
>(3) includes such beasts as U+FFFE (which you can only get by reading >a UTF16 byte order mark with the wrong byte order). The set (1)
>increases with every Unicode revision to include characters from (2), >but (3) is stable (see
>http://unicode.org/policies/stability_policy.html).

>I think JSON should allow characters from (1) and (2) to avoid being >dependent on a specific Unicode revision. I do not think (3) should be<= br> >allowed - this would cause problems with many existing parsers which >represent JSON strings using another system's native unicode
>representation.

Please see <http://www.unicode.org/versions/corrigendum9.html= >.
--
Bj=C3=B6rn H=C3=B6hrmann =C2=B7 mailto:bjoern@hoehrmann.de =C2=B7 http://bjoern.hoehrmann.de
Am Badedeich 7 =C2=B7 Telefon: +49(0)160/4415681 =C2=B7 http://www.bjoernsworld.de
25899 Dageb=C3=BCll =C2=B7 PGP Pub. KeyID: 0xA4357E78 =C2=B7 http://www.websitedev.de/
_____________________= __________________________
json mailing list
json@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/json

--20cf307f3ad88bab8804de94e4ea-- From cowan@ccil.org Fri Jun 7 12:48:16 2013 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 0DD7821F96EB for ; Fri, 7 Jun 2013 12:48:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.323 X-Spam-Level: X-Spam-Status: No, score=-3.323 tagged_above=-999 required=5 tests=[AWL=0.276, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 75lafQKcvnsC for ; Fri, 7 Jun 2013 12:48:11 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id 9F7BD21F96E4 for ; Fri, 7 Jun 2013 12:48:11 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1Ul2do-00061R-CP; Fri, 07 Jun 2013 15:48:04 -0400 Date: Fri, 7 Jun 2013 15:48:04 -0400 From: John Cowan To: Nico Williams Message-ID: <20130607194803.GJ13569@mercury.ccil.org> References: <20130606042921.GC1362@mercury.ccil.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Cc: Carsten Bormann , Paul Hoffman , "Joe Hildebrand \(jhildebr\)" , "json@ietf.org" Subject: Re: [Json] Unpaired surrogates in JSON strings X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 07 Jun 2013 19:48:16 -0000 Nico Williams scripsit: > We already know to allow the user of unassigned code points. We can't > avoid having a normative reference to a Unicode version, if that was > your goal. As long as it's recent enough to incorporate non-characters, that's enough. -- John Cowan cowan@ccil.org http://www.ccil.org/~cowan Most languages are dramatically underdescribed, and at least one is dramatically overdescribed. Still other languages are simultaneously overdescribed and underdescribed. Welsh pertains to the third category. --Alan King From markus.lanthaler@gmx.net Fri Jun 7 13:11:22 2013 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 759AC21F998C for ; Fri, 7 Jun 2013 13:11:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.15 X-Spam-Level: X-Spam-Status: No, score=-1.15 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B9RoehaHXROh for ; Fri, 7 Jun 2013 13:11:16 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) by ietfa.amsl.com (Postfix) with ESMTP id 985D621F9992 for ; Fri, 7 Jun 2013 13:11:14 -0700 (PDT) Received: from mailout-de.gmx.net ([10.1.76.10]) by mrigmx.server.lan (mrigmx002) with ESMTP (Nemesis) id 0MEHXK-1UZzJZ345A-00FSDD for ; Fri, 07 Jun 2013 22:11:13 +0200 Received: (qmail invoked by alias); 07 Jun 2013 20:11:13 -0000 Received: from 84-115-182-43.dynamic.surfer.at (EHLO Vostro3500) [84.115.182.43] by mail.gmx.net (mp010) with SMTP; 07 Jun 2013 22:11:13 +0200 X-Authenticated: #419883 X-Provags-ID: V01U2FsdGVkX182gct+dH42RerTnqNAGtl5SuFe8IO+Jm8raWdI0y /5T/DPMRm5HsxT From: "Markus Lanthaler" To: References: <00d601ce6360$52acce30$f8066a90$@lanthaler@gmx.net> In-Reply-To: Date: Fri, 7 Jun 2013 22:11:06 +0200 Message-ID: <031a01ce63bb$25218130$6f648390$@lanthaler@gmx.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac5jMj7wK5i9s5prS+2npykXIGILbgALg8dAAA49wAAACFzgIA== Content-Language: de X-Y-GMX-Trusted: 0 Subject: Re: [Json] Allow any JSON value at the top level X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 07 Jun 2013 20:11:22 -0000 On Friday, June 07, 2013 7:09 PM, Joe Hildebrand (jhildebr) wrote: > On 6/7/13 3:20 AM, "Markus Lanthaler" wrote: > > >On Friday, June 07, 2013 5:51 AM, Manger, James H wrote: > >> I propose allowing a JSON text to be any JSON value. > >> > >> A JSON text is a serialization of any JSON value. > >> > >> JSON-text = value > >> > >> value = false / null / true / object / array / number / string > > > >I'm strictly against this. Not only would it break many > implementations but also specs build on top of JSON that rely on > JSON-text = object / array. > > What about a new production in parallel to JSON-text, like 'JSON- > document'? And how is that production used? A "JSON document", i.e., a representation labeled as application/json must be an array or an object at the top-level. If you want something else, then it's clearly out of scope for this WG IMO. You can of course write another RFC standardizing JSON+ :-P -- Markus Lanthaler @markuslanthaler From nico@cryptonector.com Fri Jun 7 13:19:56 2013 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 1235521F99C2 for ; Fri, 7 Jun 2013 13:19:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ivgxQ13pluap for ; Fri, 7 Jun 2013 13:19:51 -0700 (PDT) Received: from homiemail-a54.g.dreamhost.com (mailbigip.dreamhost.com [208.97.132.5]) by ietfa.amsl.com (Postfix) with ESMTP id 2E42521F99C1 for ; Fri, 7 Jun 2013 13:19:51 -0700 (PDT) Received: from homiemail-a54.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a54.g.dreamhost.com (Postfix) with ESMTP id 67FFD40122422 for ; Fri, 7 Jun 2013 13:19:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=W96foJVjAbPU9RifG40O 8NS2GzM=; b=bYkpvXTvBsiR8MTxmP15X66WxqFuk4r5SJWtjpxGpWyD3y/iuVnL 0MrecYK/zHb3UrIYsPw/9A0vIc4jE8ptCbJNzYd4S/R5P1CkEoZpAp0Ux6FsEOuW qETYnygmrCvAcpend2M7pzwpLaJe/zXQIgbV9hpjkRQrg1Tyl6Dszs4= Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a54.g.dreamhost.com (Postfix) with ESMTPSA id 0F3FA4012241B for ; Fri, 7 Jun 2013 13:19:49 -0700 (PDT) Received: by mail-wi0-f182.google.com with SMTP id cb5so1564853wib.15 for ; Fri, 07 Jun 2013 13:19:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=aCQeRp4LQYtA/iGBKOsw2erL7sKXZYHA0TdQWgDsqx0=; b=P4qyMy629pDUIDRzMR9CB6DvDJ4IzGNrMXb5moVqQmN0UCiesOYo7qK3SI5jTDkh98 XYOh9ea7TZ8ZxP/ZhUCbBZqpEqS1wQTsckVDLk7bqlRTpBerM9BHQrkifKl3L5l9nUD9 FfIbwfOW3SMFcX8pyJS9UeW9P9fMvschPfmoHaN+xis1BqI2T5seXi5afWIpcD02kuFu jlFyh52564uFnHA1bhruOCs6Feh96a9Rp/t946ES7Kg3FuJGh6B1VDgyhCE6CdS9w651 T1WN/RpKEC75ijGXcAay9Q4ljSrlAm6FK0XLwj0lz93ePxrdJPL+sKI9DHUfzQXbozgB gUHg== MIME-Version: 1.0 X-Received: by 10.194.79.74 with SMTP id h10mr119900wjx.84.1370636388405; Fri, 07 Jun 2013 13:19:48 -0700 (PDT) Received: by 10.216.63.136 with HTTP; Fri, 7 Jun 2013 13:19:48 -0700 (PDT) In-Reply-To: References: <255B9BB34FB7D647A506DC292726F6E1151B21F9A9@WSMSG3153V.srv.dir.telstra.com> <3B4E7F65-B9B9-4C95-B077-D178B8DD8216@vpnc.org> <51B20529.2040906@drees.name> Date: Fri, 7 Jun 2013 15:19:48 -0500 Message-ID: From: Nico Williams To: stefan@drees.name Content-Type: text/plain; charset=UTF-8 Cc: Paul Hoffman , "json@ietf.org" Subject: Re: [Json] Allow any JSON value at the top level X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 07 Jun 2013 20:19:56 -0000 On Fri, Jun 7, 2013 at 11:52 AM, Nico Williams wrote: > If the top-level may be any value then we still have the first > character being ASCII and the section 3 encoding detection algorithm > still works: > > 00 00 00 xx UTF-32BE > 00 xx UTF-16BE > xx 00 UTF-32LE > xx 00 UTF-16LE > xx xx UTF-8 Ah, no, what a braino. /me is embarrassed. From nico@cryptonector.com Fri Jun 7 13:53:25 2013 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 4BE9F21F996F for ; Fri, 7 Jun 2013 13:53:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dAJ4x46gy7Zn for ; Fri, 7 Jun 2013 13:53:20 -0700 (PDT) Received: from homiemail-a70.g.dreamhost.com (caiajhbdcbef.dreamhost.com [208.97.132.145]) by ietfa.amsl.com (Postfix) with ESMTP id 68F0A21F99A1 for ; Fri, 7 Jun 2013 13:53:19 -0700 (PDT) Received: from homiemail-a70.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a70.g.dreamhost.com (Postfix) with ESMTP id C6117768064 for ; Fri, 7 Jun 2013 13:53:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=1ulp7wTM0+FaqPCun/Uc V3HLWFA=; b=mdLK3mERHlTvquLLhAanVqDJLtN26Xzbuibp6+wCTWhADsQxkGxL fbkGIj58ARG7F/wnyPvIczGxOdiHnw4UFH8p96n7PS13DoVXFibJP1EiAVNRY7Sm PIDHquh5Kv8N1vTV8nm/OBwIj+g9S5XRm3FHnh+OgVgWQ1xf25BVjdw= Received: from mail-we0-f176.google.com (mail-we0-f176.google.com [74.125.82.176]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a70.g.dreamhost.com (Postfix) with ESMTPSA id 65EA6768059 for ; Fri, 7 Jun 2013 13:53:17 -0700 (PDT) Received: by mail-we0-f176.google.com with SMTP id t56so3358216wes.7 for ; Fri, 07 Jun 2013 13:53:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=0o4Oalib/5IaNCJKZ/LELPWQWoSN29GJlHN/tLxMbc8=; b=RaAiA8Mg60sHrdBhTAn6lRdM6airuRzezbVwP5ZUBMVAB05iIgWAbnnowJ0oS8sDYn 4DSvNuqLegxpY4v9TxOLN3FJwfItpcqKg5xqHBj7+kXc3O4DRNT+ytRbEwYT/04d43NG bsWd8vN3+wHSWfkOzZp8NPv6vRtrmTijAHw18lTihB+CseJ8d3VMnilzLD3JoVHgqwko gtksWGd0WVG2QNTzSgkR8LLp9G2ANhuYTQ2zH1te5Le3ppOyBrkZfduV7VGwPLQ8yG+B q6uNwAyDpWknVR1JQXCW10eKVnHaWduVgT+VyMtGdY6ekN9MV8CIpXS+hyQuyUlIHpfi 0czA== MIME-Version: 1.0 X-Received: by 10.194.79.74 with SMTP id h10mr175255wjx.84.1370638395488; Fri, 07 Jun 2013 13:53:15 -0700 (PDT) Received: by 10.216.63.136 with HTTP; Fri, 7 Jun 2013 13:53:15 -0700 (PDT) In-Reply-To: References: <255B9BB34FB7D647A506DC292726F6E1151B21F9A9@WSMSG3153V.srv.dir.telstra.com> <3B4E7F65-B9B9-4C95-B077-D178B8DD8216@vpnc.org> <51B20529.2040906@drees.name> Date: Fri, 7 Jun 2013 15:53:15 -0500 Message-ID: From: Nico Williams To: stefan@drees.name Content-Type: text/plain; charset=UTF-8 Cc: Paul Hoffman , "json@ietf.org" Subject: Re: [Json] Allow any JSON value at the top level X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 07 Jun 2013 20:53:25 -0000 On Fri, Jun 7, 2013 at 3:19 PM, Nico Williams wrote: > Ah, no, what a braino. /me is embarrassed. No, not a braino after all. Since we'd not have two NUL bytes in a row in any encoding other than UTF-32. There'd be no ambiguity, even with single-character values (numbers). From jorge@jorgechamorro.com Fri Jun 7 13:08:01 2013 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 0211921F995F for ; Fri, 7 Jun 2013 13:08:01 -0700 (PDT) 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=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wmAg9EPadRte for ; Fri, 7 Jun 2013 13:08:00 -0700 (PDT) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 3843721F995E for ; Fri, 7 Jun 2013 13:08:00 -0700 (PDT) Received: by mail-wi0-f172.google.com with SMTP id c10so1541990wiw.17 for ; Fri, 07 Jun 2013 13:07:59 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=HAD7+MCcc84rwGFtVdiLYctaa9DJSAVukNlhNECv1C4=; b=Axa64gWaEM9UL8rwBkbibXgPf0w/ZYfF/kuoAJv+PA4F8WRMmxVMOct364LsXSIuf3 VU1IXEWWXKQw63+BmMWPdpn5S48f2Gb4ZNqMV/Jy/YCka9Zvg8gQK91CADWZSfjTbuDc xC/B7D99aqF3Ud4KpC9Y5UB/Zx47vcDx3M/FjjNKf7+qgnLktYipM2DHQ2eUd4VNyllg TnoE0nsJSkG+Jg0ntMIcP4Na/DQvKv4Mv0TPZD75Qovz1+6I0VRnsHkx91QXSABvd5nZ 14H9//nz1esYYKt83fLuXdtuN64uUGXZPYPxhDGaxx9z5omBPFmhUllQDmZSYrEiL7Vj pVZg== X-Received: by 10.194.7.137 with SMTP id j9mr202667wja.11.1370635679231; Fri, 07 Jun 2013 13:07:59 -0700 (PDT) Received: from [192.168.10.50] (70.Red-79-155-116.dynamicIP.rima-tde.net. [79.155.116.70]) by mx.google.com with ESMTPSA id ft10sm310459wib.7.2013.06.07.13.07.57 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 07 Jun 2013 13:07:58 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Jorge In-Reply-To: Date: Fri, 7 Jun 2013 22:02:43 +0200 Content-Transfer-Encoding: 7bit Message-Id: References: <255B9BB34FB7D647A506DC292726F6E1151B21F9A9@WSMSG3153V.srv.dir.telstra.com> To: Vinny A X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQnta6tcXRAowz8iDjUabEApv1DNMeoI28+25pjY8wEJLNz3f9TiSsl81EQ1vN4yhCN5KsXA Cc: Carsten Bormann , "Manger, James H" , json@ietf.org Subject: Re: [Json] Allow any JSON value at the top level X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 07 Jun 2013 20:59:28 -0000 On 07/06/2013, at 15:38, Vinny A wrote: > > Do commonly used parsers support top level JSON values? Yes: JSON.parse('"string"') "string" JSON.parse('27') 27 JSON.parse('true') true JSON.parse('false') false JSON.parse('null') null -- ( Jorge )(); From paul.hoffman@vpnc.org Fri Jun 7 14:32:31 2013 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 3D81A21F9957 for ; Fri, 7 Jun 2013 14:32:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YScryVRmtcq0 for ; Fri, 7 Jun 2013 14:32:30 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id B0FE621F8B90 for ; Fri, 7 Jun 2013 14:32:30 -0700 (PDT) Received: from [165.227.249.247] (sn80.proper.com [75.101.18.80]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r57LW1If099149 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 7 Jun 2013 14:32:02 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Paul Hoffman In-Reply-To: <51B20C23.6080303@drees.name> Date: Fri, 7 Jun 2013 14:32:01 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <3571001A-2D76-4F28-AE1B-0512ACC432B3@vpnc.org> References: <51B0E02E.4070209@crockford.com> <1BD0044B-D7A6-4C7F-899E-5D3E72C62956@vpnc.org> <51B116FE.9050406@crockford.com> <51B1885F.3080908@drees.name> <9D5D948B-BD1E-4195-9B05-3376D6EFFAEA@vpnc.org> <51B20C23.6080303@drees.name> To: stefan@drees.name X-Mailer: Apple Mail (2.1508) Cc: Douglas Crockford , "json@ietf.org" Subject: Re: [Json] Security Considerations X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 07 Jun 2013 21:32:31 -0000 On Jun 7, 2013, at 9:36 AM, Stefan Drees wrote: > On 2013-06-07 17:58, Paul Hoffman wrote: >>=20 >> On Jun 7, 2013, at 12:14 AM, Stefan Drees wrote: >>=20 >>> On 07.06.13 01:10, Douglas Crockford wrote: >>>> On 6/6/2013 4:04 PM, Paul Hoffman wrote: >>>>>=20 >>>>> On Jun 6, 2013, at 12:17 PM, Douglas Crockford = >>>>> wrote: >>>>>=20 >>>>>> Proposal: >>>>>>=20 >>>>>> With any data format, it is important to encode correctly. = Care must >>>>>> be taken when constructing JSON texts by concatenation. For = example: >>>>>>=20 >>>>>> account =3D 4627; >>>>>> comment =3D "\",\"account\":262"; // provided by attacker >>>>>> json_text =3D "(\"account\":" + account + ",\"comment\":\"" + >>>>>> comment + "\"}"; >>>>> The example is language-specific and, due to the escaping, hard to = read. >>>> Which specific language would you say it is? Confusion attacks are = often >>>> hard to read. That is why they work. ... >>>=20 >>> I propose to keep the example, but remove the need for quoting by = switching to single quotes where needed: >>>=20 >>> """ >>> account =3D 4627; >>> comment =3D '","account":262'; // provided by attacker >>> json_text =3D '("account":' + account + ',"comment":"' + comment + = '"}'; >>> """ >>>=20 >>> this is valid (Java|ECMA)Script, right and also much more readable, = isn't it? >>=20 >> I can live with this, but I think doing it in English wording is = better. >=20 > Proposal in English wording: >=20 > replace > OLD(++): > """ > With any data format, it is important to encode correctly. Care must > be taken when constructing JSON texts by concatenation. For example: >=20 > account =3D 4627; > comment =3D '","account":262'; // provided by attacker > json_text =3D '("account":' + account + ',"comment":"' + comment + = '"}'; >=20 > """ >=20 > with: > NEW: > """ > With any data format, it is important to encode correctly. Care must > be taken when constructing JSON texts by concatenation in part from = untrusted data, this data may inject a mix of structural characters and = quotes, that changes the structure of the resulting JSON text. > For example: When trying to compose an object like > {"account": 4627, "comment": "foo"} from user input data for "foo", = the attacking user might instead inject = ","account":262,"comment":"hacked so that the resulting naively = concatenated JSON text would become: > {"account": 4627, "comment": "","account":262,"comment":"hacked"} >=20 >=20 > """ >=20 > What do you think? I'm liking that more, but we still have quoting problems. They can be = solved by linebreaks. For example: When trying to compose an object such as: {"account": 4627, "comment": "foo"} from user input data for "foo", the attacker might instead inject the = text: ","account":262,"comment":"hacked so that the resulting naively concatenated JSON text would become: {"account": 4627, "comment": "","account":262,"comment":"hacked"} --Paul Hoffman= From sayrer@gmail.com Fri Jun 7 14:37:51 2013 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 E806621F9963 for ; Fri, 7 Jun 2013 14:37:51 -0700 (PDT) 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=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T0iNA9xSNXZi for ; Fri, 7 Jun 2013 14:37:51 -0700 (PDT) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) by ietfa.amsl.com (Postfix) with ESMTP id EB93521F9961 for ; Fri, 7 Jun 2013 14:37:50 -0700 (PDT) Received: by mail-wi0-f177.google.com with SMTP id ey16so1718176wid.4 for ; Fri, 07 Jun 2013 14:37:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=imWCE5d5P2ejduR0qeBlG6e9a+88P/mGuCpFh3z2NUQ=; b=uvMMAFFBnz+i3vG8BcNuzKwaFCxwSO/zINhiIlhXCDvcKRgPkaR2eup41lWnz+kzPk fu7RyLx3e53vLHedC5ILar9v4MY0lrtZJMxUCZ+Hu6ELE7qMoHvbiSu0I/6htsK2JlfB 0WjjGl9+Q8oXwjnEs3SYpUxMLu6o4D6H/u15U4c+YDQ5ugL5z7nGtO0NDu7kl6vv2Ygj Qx1660cakhZ47XnzCpWMfZWI8HaDuhLv8L1aRNtLDYTQwcAD/fznKwtc06vooKZ84e3C UvkouiyOtxbvqkYgporCLwSLC6qYnaTy0S1tYvi574NKFkXqR+ZTZbRa9xNJT3lz7YNg l9DA== MIME-Version: 1.0 X-Received: by 10.180.206.77 with SMTP id lm13mr314340wic.18.1370641070055; Fri, 07 Jun 2013 14:37:50 -0700 (PDT) Received: by 10.194.83.35 with HTTP; Fri, 7 Jun 2013 14:37:49 -0700 (PDT) In-Reply-To: <51b23e6d.6196420a.0b15.4245SMTPIN_ADDED_BROKEN@mx.google.com> References: <51b23e6d.6196420a.0b15.4245SMTPIN_ADDED_BROKEN@mx.google.com> Date: Fri, 7 Jun 2013 14:37:49 -0700 Message-ID: From: R S To: Markus Lanthaler Content-Type: multipart/alternative; boundary=001a11c380ae1866e204de973e02 Cc: "json@ietf.org" Subject: Re: [Json] Allow any JSON value at the top level X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 07 Jun 2013 21:37:52 -0000 --001a11c380ae1866e204de973e02 Content-Type: text/plain; charset=ISO-8859-1 I believe this proposal is in scope--it's one of the inconsistencies with ECMAScript this group has been tasked with resolving, and it was mentioned during the chartering process. Are there interoperability problems we should be aware of? In my experience, this change doesn't matter to applications that can only handle objects or arrays--they simply encounter an error immediately after parsing rather than during it. - Rob On Friday, June 7, 2013, Markus Lanthaler wrote: > On Friday, June 07, 2013 7:09 PM, Joe Hildebrand (jhildebr) wrote: > > On 6/7/13 3:20 AM, "Markus Lanthaler" > > wrote: > > > > >On Friday, June 07, 2013 5:51 AM, Manger, James H wrote: > > >> I propose allowing a JSON text to be any JSON value. > > >> > > >> A JSON text is a serialization of any JSON value. > > >> > > >> JSON-text = value > > >> > > >> value = false / null / true / object / array / number / string > > > > > >I'm strictly against this. Not only would it break many > > implementations but also specs build on top of JSON that rely on > > JSON-text = object / array. > > > > What about a new production in parallel to JSON-text, like 'JSON- > > document'? > > And how is that production used? A "JSON document", i.e., a representation > labeled as application/json must be an array or an object at the top-level. > If you want something else, then it's clearly out of scope for this WG IMO. > You can of course write another RFC standardizing JSON+ :-P > > > > -- > Markus Lanthaler > @markuslanthaler > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > --001a11c380ae1866e204de973e02 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I believe this proposal=A0is in scope--it's one of the inconsistencies = with ECMAScript this group has been tasked with resolving, and it was menti= oned during the chartering process.

Are there interopera= bility problems we should be aware of? In my experience, this change doesn&= #39;t matter to applications that can only handle objects or arrays--they s= imply encounter an error immediately after parsing rather than during it.

- Rob



On Fr= iday, June 7, 2013, Markus Lanthaler wrote:
On Friday, June 07, 2013 7:09 PM, Joe Hildebrand (jhildebr) wrote:
> On 6/7/13 3:20 AM, "Markus Lanthaler" <markus.lanthaler@gmx.net> wrote:
>
> >On Friday, June 07, 2013 5:51 AM, Manger, James H wrote:
> >> I propose allowing a JSON text to be any JSON value.
> >>
> >> =A0 =A0A JSON text is a serialization of any JSON value.
> >>
> >> =A0 =A0JSON-text =3D value
> >>
> >> =A0 =A0value =3D false / null / true / object / array / numbe= r / string
> >
> >I'm strictly against this. Not only would it break many
> implementations but also specs build on top of JSON that rely on
> JSON-text =3D object / array.
>
> What about a new production in parallel to JSON-text, like 'JSON-<= br> > document'?

And how is that production used? A "JSON document", i.e., a repre= sentation
labeled as application/json must be an array or an object at the top-level.=
If you want something else, then it's clearly out of scope for this WG = IMO.
You can of course write another RFC standardizing JSON+ :-P



--
Markus Lanthaler
@markuslanthaler

_______________________________________________
json mailing list
json@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/json
--001a11c380ae1866e204de973e02-- From cabo@tzi.org Fri Jun 7 15:04:23 2013 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 7408821F99B6 for ; Fri, 7 Jun 2013 15:04:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nc1fyBCfqqLT for ; Fri, 7 Jun 2013 15:04:17 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 5F2DD21F99A9 for ; Fri, 7 Jun 2013 15:04:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r57M4DOL014727; Sat, 8 Jun 2013 00:04:13 +0200 (CEST) Received: from [192.168.217.105] (p54891ED1.dip0.t-ipconnect.de [84.137.30.209]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id AAEB03511; Sat, 8 Jun 2013 00:04:12 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: Date: Sat, 8 Jun 2013 00:04:11 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "Joe Hildebrand (jhildebr)" X-Mailer: Apple Mail (2.1503) Cc: Markus Lanthaler , "json@ietf.org" Subject: Re: [Json] Allow any JSON value at the top level X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 07 Jun 2013 22:04:23 -0000 On Jun 7, 2013, at 19:08, "Joe Hildebrand (jhildebr)" = wrote: > What about a new production in parallel to JSON-text, like = 'JSON-document'? I'd call it JSON-value, and write a separate document that defines a new = media type application/json-value No gratuitous change, no interoperability problems. (Actually, we have the production "value" already, so anyone can go = ahead and register that media type.) Gr=FC=DFe, Carsten From allen@wirfs-brock.com Fri Jun 7 15:33:14 2013 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 E217021F99A9 for ; Fri, 7 Jun 2013 15:33:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.014 X-Spam-Level: X-Spam-Status: No, score=-2.014 tagged_above=-999 required=5 tests=[AWL=-0.016, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_45=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qsfq4BCVSaEi for ; Fri, 7 Jun 2013 15:33:09 -0700 (PDT) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by ietfa.amsl.com (Postfix) with ESMTP id ECAF221F99A6 for ; Fri, 7 Jun 2013 15:33:07 -0700 (PDT) Received: from 069-064-236-244.pdx.net ([69.64.236.244] helo=[192.168.0.15]) by mho-02-ewr.mailhop.org with esmtpa (Exim 4.72) (envelope-from ) id 1Ul5DW-0008Nw-N2; Fri, 07 Jun 2013 22:33:07 +0000 X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 69.64.236.244 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+qLYgCunGg3ZSn04XbMTcGM9/2S5wEq5E= Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: multipart/alternative; boundary=Apple-Mail-55--652326555 From: Allen Wirfs-Brock In-Reply-To: <8E679529-8663-4552-A905-529E732AEB7B@yahoo.com> Date: Fri, 7 Jun 2013 15:33:00 -0700 Message-Id: <89FDB01C-B5B1-43DF-AFE1-845B8E8E96B5@wirfs-brock.com> References: <51AF8479.5080002@crockford.com> <51AF9ACF.5020507@cisco.com> <51AFB3F8.8060708@crockford.com> <8F32953C-C788-4DC9-888E-920E2BEB7FDD@yahoo.com> <831B8E46-F239-4353-8F95-8DF3F9BD2E78@yahoo.com> <51AFC924.2030805@crockford.com> <8E679529-8663-4552-A905-529E732AEB7B@yahoo.com> To: Vinny A X-Mailer: Apple Mail (2.1085) Cc: Paul Hoffman , "json@ietf.org" Subject: Re: [Json] The names within an object SHOULD be unique. X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 07 Jun 2013 22:33:15 -0000 --Apple-Mail-55--652326555 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jun 7, 2013, at 10:43 AM, Vinny A wrote: >=20 >=20 > On Jun 6, 2013, at 12:45 PM, Allen Wirfs-Brock = wrote: >> Allen Wirfs-Brock >> ECMAScript Language Spec. Project Editor >=20 >> What I would say, as a replacement for the current text
is: >>=20 >> The names within an object SHOULD be unique. If a key is = duplicated, a parser MUST take <> only the last of = the duplicated key pairs. >=20 > Just to be clear here, ECMA is OK with using MUST in regards to the = last key pair? =20 The ECMAScript standard specifies that the JSON parse built-in to a = conforming ECMAScript implementation must accept duplicate key pairs and = that it provides as its output the value of the last such pair. = Changing that behavior would be a breaking change that we are very = unlikely to make. In general, the ECMAScript specification is hyper prescriptive about = many behaviors, such as this, that traditionally would have been = considered reasonable areas to allow implementation variability. The = reason is that we really are a community of multiple independently = developed implementations whose users (web developers) expect and demand = identical behavior from our implementations. Experience has shown that = when implementation variation is permitted that a de facto standard = rapidly emerges around whatever implementation choices were made by the = currently dominant implementation (historically MS Internet Explore on = the desktop, more recently Webkit on mobile devices) and that all other = implementations are forced to conform in order to remain viable. The = preference within TC39 is to pro actively avoid such situations and = reach early consensus on a single required behavior. >=20 > Because we already have proposed language that says that, but one of = the points under contention on this list is what to do with duplicated = key pairs. >=20 > Is the following language acceptable to ECMA (disclaimer: original = text by Paul, modifications by me): >=20 >=20 > On Jun 6, 2013, at 10:24 AM, Paul Hoffman = wrote: >> The new text should use language that is already in RFC 4627; "key" = is not such a word. To be fair to implementers, the new document also = needs to deal with both emitters and parsers. >>=20 >> Proposal: >>=20 >> In Section 2.2: >> Current: >> The names within an object SHOULD be unique. >> Proposed: >> If the names within an object are not unique, the result of parsing = the=20 >> object is unpredictable, and the parse may even fail completely. = Thus, >> the names within an object SHOULD be unique. First, a terminology issue. Section 2 is defining a grammar. There are = no syntactic ambiguities associated with multiple key-value pairs. = There is no reason they should cause parsing (take literally) to fail. = The issue is what semantic interpretation is applied to such = occurrences. JSON actually specifies very little with regard to the = semantics of a JSON text but a plausible interpretation of duplicate = key-value pairs might be that the entire JSON text is invalid because it = is semantically ambiguous. Personally I wouldn't call that a parsing = issue. Back to your question, Ecma TC39 is a consensus driven organization, and = I don't think we would find consensus on the above proposed language. = More below >>=20 >> In Section 4, add a new paragraph: >> If a parser encounters an object with duplicate names, the parser = MAY >> fail to parse the JSON text; if the parser accepts objects with = duplicate >> names, it SHOULD accept only the last name/value pair that has the >> duplicate name.=20 >=20 > If we have to recommend to both parsers and emitters, I'd like to make = a slight change to your wording: >=20 > In Section 2.2: > Current: > The names within an object SHOULD be unique. > Proposed: > The names within an object SHOULD be unique. Non-unique names have = unpredictable effects (refer to sections 4 & 5). This is better and I think we could get consensus (it's a variation of = what I suggested above): In Section 2.2: Current: The names within an object SHOULD be unique. Proposed: The names within an object SHOULD be unique because it is ambiguous = as to which value should be associated with a duplicated key. >=20 > In Section 4 (Parsers) add a new paragraph: > If a parser encounters an object with duplicate names, the parser = MAY fail to parse the JSON text; if the parser accepts objects with = duplicate names, it MUST accept only the last name/value pair that has = the duplicate name.=20 I think this is too restrictive and gives license to reject existing = valid datasets that use commenting conventions that introduce duplicate = names. Proposal: A parser MUST accept a JSON text that includes objects with duplicate = names. A parser SHOULD associate with such a name the value of the last = name/value pair that has the duplicate name.=20 TC39 would leave the specification of the ECMAScript JSON.parse function = unchanged as it conforms to this proposal. Note that a streaming parser might reasonably and validly present all of = the duplicate name/value pairs to its clients. >=20 > In Section 5 (Generators) add a new paragraph: > A JSON generator SHOULD not duplicate names. If duplicate names are = generated, the authoritative name/value pair MUST be listed last. I think this is unnecessary if we specify that JSON text's with = duplicated names must be accepted by parsers. Allen --Apple-Mail-55--652326555 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii


On Jun = 6, 2013, at 12:45 PM, Allen Wirfs-Brock <allen@wirfs-brock.com> = wrote:
Allen = Wirfs-Brock
ECMAScript Language Spec. Project = Editor

What I would say, as a replacement for the current = text  <section 2.2> is:

        The = names within an object SHOULD be unique.  If a key is duplicated, a = parser MUST take  <<use?? interpret??>> only the last = of the duplicated key = pairs.

Just to be clear = here, ECMA is OK with using MUST in regards to the last key pair? =  

The = ECMAScript standard specifies that the JSON parse built-in to a = conforming ECMAScript implementation must accept duplicate key pairs and = that it provides as its output the value of the last such pair. =  Changing that behavior would be a breaking change that  we = are very unlikely to make.

In general, the = ECMAScript specification is hyper prescriptive about many behaviors, = such as this, that traditionally would have been considered reasonable = areas to allow implementation variability. The reason is that we really = are a community of multiple independently developed implementations = whose users (web developers) expect and demand identical behavior from = our implementations. Experience has shown that when implementation = variation is permitted that a de facto standard rapidly emerges around = whatever implementation choices were made by the currently dominant = implementation (historically MS Internet Explore on the desktop, more = recently Webkit on mobile devices) and that all other implementations = are forced to conform in order to remain viable. The preference within = TC39 is to pro actively avoid such situations and reach early consensus = on a single required behavior.


Because= we already have proposed language that says that, but one of the points = under contention on this list is what to do with duplicated key = pairs.

Is the following language = acceptable to ECMA (disclaimer: original text by Paul, =  modifications by me):


On Jun = 6, 2013, at 10:24 AM, Paul Hoffman <paul.hoffman@vpnc.org> = wrote:
The new text should use language that = is already in RFC 4627; "key" is not such a word. To be fair to = implementers, the new document also needs to deal with both emitters and = parsers.

Proposal:

In Section = 2.2:
Current:
  The names = within an object SHOULD be = unique.
Proposed:
  If the = names within an object are not unique, the result of parsing = the 
  object is unpredictable, and the = parse may even fail completely. Thus,
  the = names within an object SHOULD be = unique.
=
First, a terminology issue. Section 2 is defining a = grammar.  There are no syntactic ambiguities associated with = multiple key-value pairs.  There is no reason they should cause = parsing (take literally) to fail. The issue is what semantic = interpretation is applied to such occurrences. JSON actually specifies = very little with regard to the semantics of a JSON text but a = plausible interpretation of duplicate key-value pairs might be = that the entire JSON text is invalid because it is semantically = ambiguous.  Personally I wouldn't call that a parsing = issue.

Back to your question, Ecma TC39 is a = consensus driven organization, and I don't think we would find consensus = on the above proposed language.  More = below


In Section 4, add a new = paragraph:
  If a parser encounters an object = with duplicate names, the parser MAY
  fail to = parse the JSON text; if the parser accepts objects with = duplicate
  names, it SHOULD accept only the = last name/value pair that has the
  duplicate = name. 

If we = have to recommend to both parsers and emitters, I'd like to make a = slight change to your wording:

In = Section 2.2:
Current:
  =   The names within an object SHOULD be = unique.
Proposed:
   The= names within an object SHOULD be unique. Non-unique names have = unpredictable effects (refer to sections 4 & = 5).

This = is better and I think we could get consensus (it's a variation of what I = suggested above):

In Section = 2.2:
Current:
    The names within = an object SHOULD be = unique.
Proposed:
   The names within an object SHOULD be unique because it is = ambiguous as to which value should be associated with a duplicated = key.


In Section 4 (Parsers) = add a new paragraph:
  If a parser = encounters an object with duplicate names, the parser MAY fail to = parse the JSON text; if the parser accepts objects with = duplicate names, it MUST accept only the last name/value pair that = has the duplicate = name. 

I = think this is too restrictive and gives license to reject existing valid = datasets that use commenting conventions that introduce duplicate = names.

Proposal:
   A = parser MUST accept a JSON text that includes objects with duplicate = names. A parser SHOULD associate with such a name the value of the last = name/value pair that has the    duplicate = name. 

TC39 would leave the specification = of the ECMAScript JSON.parse function unchanged as it conforms to this = proposal.

Note that a streaming parser might = reasonably and validly present all of the duplicate name/value pairs to = its clients.


In Section 5 = (Generators) add a new paragraph:
   A JSON = generator SHOULD not duplicate names. If duplicate names are generated, = the authoritative name/value pair MUST be listed = last.

I think = this is unnecessary if we specify that JSON text's with duplicated names = must be accepted by = parsers.

Allen

<= /html>= --Apple-Mail-55--652326555-- From nico@cryptonector.com Fri Jun 7 15:52:07 2013 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 ED77321F8930 for ; Fri, 7 Jun 2013 15:52:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.677 X-Spam-Level: X-Spam-Status: No, score=-1.677 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_45=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PSHebX9sPd0v for ; Fri, 7 Jun 2013 15:52:03 -0700 (PDT) Received: from homiemail-a16.g.dreamhost.com (mailbigip.dreamhost.com [208.97.132.5]) by ietfa.amsl.com (Postfix) with ESMTP id 098A221F8C1A for ; Fri, 7 Jun 2013 15:52:03 -0700 (PDT) Received: from homiemail-a16.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a16.g.dreamhost.com (Postfix) with ESMTP id 9C596508084 for ; Fri, 7 Jun 2013 15:52:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=WQRYbrngwobI8WGdVB4b XkDXXZ4=; b=GrWbsK4K2LQWpVYvVtR2YvI2SaVGweOTht5Q5m+jXfGrzsU1Tpe+ CLCvACLw0YGvseNeZu0tB7AlK9hxwL7eEcWlzYQj39IAuyay9YM3ynqeDeaikjXw 0WZdlVSPY3dBC/KaT5PzYqSKUM5ycE/AfXlsqPxlM6nOfWWW9VBhips= Received: from mail-wg0-f41.google.com (mail-wg0-f41.google.com [74.125.82.41]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a16.g.dreamhost.com (Postfix) with ESMTPSA id 4B5CE508064 for ; Fri, 7 Jun 2013 15:52:02 -0700 (PDT) Received: by mail-wg0-f41.google.com with SMTP id k13so1731105wgh.0 for ; Fri, 07 Jun 2013 15:52:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=rNZse8CM5rq8BdaMIdVDad33T8aONiUw8E/MaZoAhNw=; b=S9CGQwgNYNOt1M8+GtfJObMAbid7kRs+AD2PDgt17EXxGvKYVqzpRc7WnR0ddLiV6G JdQylZ6sAI8EOcalH8erZ67EMtyYNd+aWLszlYqCkYXu3UhmbFCfAeMXsigCiAZPTxp9 XvlS6i6y73UNyVb4AkXKxui2huZzxNHzoC+z3EPuVy0H1CWirIdlO9j3eLXUfI3M+cnm Y9/7A0JPKnDGrDEWfA8OJuBm3qxhv7yfZA8YOQXxUpKbBhdOKaqQQ9UUhiZlDzNdf7ff 0ZBYThhujMcXZKZbK8+DawqgH8mSBpZv/iFP/6BFZZTbwTS/+ItaaC7VvPsxXdHO1IRl eZEw== MIME-Version: 1.0 X-Received: by 10.180.206.9 with SMTP id lk9mr2679903wic.0.1370645520861; Fri, 07 Jun 2013 15:52:00 -0700 (PDT) Received: by 10.216.63.136 with HTTP; Fri, 7 Jun 2013 15:52:00 -0700 (PDT) In-Reply-To: <89FDB01C-B5B1-43DF-AFE1-845B8E8E96B5@wirfs-brock.com> References: <51AF8479.5080002@crockford.com> <51AF9ACF.5020507@cisco.com> <51AFB3F8.8060708@crockford.com> <8F32953C-C788-4DC9-888E-920E2BEB7FDD@yahoo.com> <831B8E46-F239-4353-8F95-8DF3F9BD2E78@yahoo.com> <51AFC924.2030805@crockford.com> <8E679529-8663-4552-A905-529E732AEB7B@yahoo.com> <89FDB01C-B5B1-43DF-AFE1-845B8E8E96B5@wirfs-brock.com> Date: Fri, 7 Jun 2013 17:52:00 -0500 Message-ID: From: Nico Williams To: Allen Wirfs-Brock Content-Type: text/plain; charset=UTF-8 Cc: Vinny A , Paul Hoffman , "json@ietf.org" Subject: Re: [Json] The names within an object SHOULD be unique. X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 07 Jun 2013 22:52:08 -0000 On Fri, Jun 7, 2013 at 5:33 PM, Allen Wirfs-Brock wrote: > Proposal: > A parser MUST accept a JSON text that includes objects with duplicate > names. A parser SHOULD associate with such a name the value of the last > name/value pair that has the duplicate name. +1. In conclusion: We can't say "MUST use only the last pair" because of streaming parsers (and their applications). We can't require encoders to not send duplicates for the same reason. And we can't allow rejection of objects with duplicate names because that would break interop with streaming encoders. > TC39 would leave the specification of the ECMAScript JSON.parse function > unchanged as it conforms to this proposal. When we have a SHOULD (or SHOULD NOT) we should specify some reasons that one might not adhere to the given recommendation. Streaming parsers would be one reason. I propose this text from you be added to the RFC as well: > Note that a streaming parser might reasonably and validly present all of the > duplicate name/value pairs to its clients. Nico -- From nico@cryptonector.com Fri Jun 7 16:23:15 2013 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 8A35C21F99F2 for ; Fri, 7 Jun 2013 16:23:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.947 X-Spam-Level: X-Spam-Status: No, score=-1.947 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RVWx7emBE1N7 for ; Fri, 7 Jun 2013 16:23:11 -0700 (PDT) Received: from homiemail-a73.g.dreamhost.com (caiajhbdcagg.dreamhost.com [208.97.132.66]) by ietfa.amsl.com (Postfix) with ESMTP id 90D3121F99ED for ; Fri, 7 Jun 2013 16:23:03 -0700 (PDT) Received: from homiemail-a73.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a73.g.dreamhost.com (Postfix) with ESMTP id 7C2721F0086 for ; Fri, 7 Jun 2013 16:23:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=dtypF7JiHBFp3OZLY0fdw8s1qBQ=; b=fj+FgJy1kIB FDKT8BLg+M1w0AQ+a6tJNAZyKaItip5tgC1LjyNvUIqkl46rgNllzB/9ex92YsmG 5aZ2xYF71AX0EopOgBDV2wENOrUdGYhXxfvtkN3rL/J06IMpASSSa9gNc8yHTc6W wI0kotoQ0uNje3As7aN86x5sKapEwFr8= Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a73.g.dreamhost.com (Postfix) with ESMTPSA id 1E3171F0085 for ; Fri, 7 Jun 2013 16:23:01 -0700 (PDT) Received: by mail-we0-f182.google.com with SMTP id p60so1826297wes.13 for ; Fri, 07 Jun 2013 16:22:59 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=uhZVr99XBvdd6O26Tj5NUKy6pTaOaHrYQOlB6ArAzW0=; b=YbBLbuiIG9GbaQU9DDpJQEip2O0vtRG1hU4PQRo7Zf4hwLT1SY7PjEvbtC9egwSJY0 b7F3sL+bTIbE7gQEZ72gAcPFBX6Vemj+srfTBRci1bqoWgK3jHZoFDLyvonh0qeiPHEz sxHmxMdh7YXGdAK/n4e8mUbPVrH83A2Otc+Toy0dHQtGF0V+E5axNJomfAvSWblE4mo6 2234meKntwajYrweawfUa/H6LeMGi8iVStFjKUrQ+xTxhAIQkA09naaraIqqqv9CHx5J biQYKupd3fEVlXtOyrpcePcSU1z6tyeHFVLoAQ+Pxu59Ivm12/XWrIFZ7C9shB91Nf5l xMyQ== MIME-Version: 1.0 X-Received: by 10.194.8.163 with SMTP id s3mr479200wja.41.1370647379491; Fri, 07 Jun 2013 16:22:59 -0700 (PDT) Received: by 10.216.63.136 with HTTP; Fri, 7 Jun 2013 16:22:59 -0700 (PDT) In-Reply-To: References: <51B06F38.8050707@crockford.com> <51B1B4E7.8090101@it.aoyama.ac.jp> <9ld3r8pc0tufif18dohb2fmi0ijna1vs4n@hive.bjoern.hoehrmann.de> <56A163E9-E7CD-46B3-9984-8F009EBFF500@vpnc.org> Date: Fri, 7 Jun 2013 18:22:59 -0500 Message-ID: From: Nico Williams To: Tim Bray Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "json@ietf.org" , Bjoern Hoehrmann , Paul Hoffman , Stephen Dolan Subject: Re: [Json] On characters and code points X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 07 Jun 2013 23:23:15 -0000 On Fri, Jun 7, 2013 at 1:49 PM, Tim Bray wrote: > On Fri, Jun 7, 2013 at 11:40 AM, Bjoern Hoehrmann wro= te: >> Please see . > > Interestingly, that doesn=E2=80=99t mention surrogates. -T I think the only reasonable interpretation of surrogates is as pairs. An incomplete pair would be an error, and surrogates in any UTF other than UTF-16 would also be an error -- in those cases we're not even talking about noncharacter code points. But corrigendum #9 does make me think that the best thing to do is to pass them through, as with any other noncharacters and private-use code points. If nothing else it's one less thing to check for in a parser. Nico -- From cowan@ccil.org Fri Jun 7 20:06:35 2013 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 A50B411E80A6 for ; Fri, 7 Jun 2013 20:06:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.335 X-Spam-Level: X-Spam-Status: No, score=-3.335 tagged_above=-999 required=5 tests=[AWL=0.264, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CPKFlxVBGEyX for ; Fri, 7 Jun 2013 20:06:31 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id A299721E805D for ; Fri, 7 Jun 2013 20:06:26 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1Ul9Tw-0000un-KI; Fri, 07 Jun 2013 23:06:21 -0400 Date: Fri, 7 Jun 2013 23:06:20 -0400 From: John Cowan To: Nico Williams Message-ID: <20130608030620.GA2528@mercury.ccil.org> References: <51B06F38.8050707@crockford.com> <51B1B4E7.8090101@it.aoyama.ac.jp> <9ld3r8pc0tufif18dohb2fmi0ijna1vs4n@hive.bjoern.hoehrmann.de> <56A163E9-E7CD-46B3-9984-8F009EBFF500@vpnc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Cc: Bjoern Hoehrmann , Tim Bray , Paul Hoffman , Stephen Dolan , "json@ietf.org" Subject: Re: [Json] On characters and code points X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 08 Jun 2013 03:06:36 -0000 Nico Williams scripsit: > But corrigendum #9 does make me think that the best thing to do is to > pass them through, as with any other noncharacters and private-use > code points. If nothing else it's one less thing to check for in a > parser. If the parser provides an internal representation other than UTF-16, however, that just isn't possible. -- John Cowan http://www.ccil.org/~cowan Awk!" sed Grep. "A fscking python is perloining my Ruby; let me bash him with a Cshell! Vi didn't I mount it on a troff?" --Francis Turner From duerst@it.aoyama.ac.jp Fri Jun 7 20:12:51 2013 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 84B6A21F9446 for ; Fri, 7 Jun 2013 20:12:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.504 X-Spam-Level: X-Spam-Status: No, score=-103.504 tagged_above=-999 required=5 tests=[AWL=0.286, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tMvdlPraHWom for ; Fri, 7 Jun 2013 20:12:45 -0700 (PDT) Received: from scintmta02.scbb.aoyama.ac.jp (scintmta02.scbb.aoyama.ac.jp [133.2.253.34]) by ietfa.amsl.com (Postfix) with ESMTP id C6D0821F9424 for ; Fri, 7 Jun 2013 20:12:44 -0700 (PDT) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id r583CZ5r020708; Sat, 8 Jun 2013 12:12:35 +0900 Received: from (unknown [133.2.206.134]) by scmse02.scbb.aoyama.ac.jp with smtp id 5f4f_cf40_442f2c04_cfe9_11e2_b3b8_001e6722eec2; Sat, 08 Jun 2013 12:12:34 +0900 Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id 6DA74BF550; Sat, 8 Jun 2013 12:11:26 +0900 (JST) Message-ID: <51B2A10F.5010006@it.aoyama.ac.jp> Date: Sat, 08 Jun 2013 12:12:15 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: Jorge References: <255B9BB34FB7D647A506DC292726F6E1151B21F9A9@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Vinny A , Carsten Bormann , "Manger, James H" , json@ietf.org Subject: Re: [Json] Allow any JSON value at the top level X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 08 Jun 2013 03:12:51 -0000 What programming language/library? Regards, Martin. On 2013/06/08 5:02, Jorge wrote: > On 07/06/2013, at 15:38, Vinny A wrote: >> >> Do commonly used parsers support top level JSON values? > > Yes: > > JSON.parse('"string"') > "string" > JSON.parse('27') > 27 > JSON.parse('true') > true > JSON.parse('false') > false > JSON.parse('null') > null > From cowan@ccil.org Fri Jun 7 20:28:24 2013 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 E1BAD21F9957 for ; Fri, 7 Jun 2013 20:28:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.346 X-Spam-Level: X-Spam-Status: No, score=-3.346 tagged_above=-999 required=5 tests=[AWL=0.253, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tiPRtz7YH4MA for ; Fri, 7 Jun 2013 20:28:20 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id 8EA2B21F9955 for ; Fri, 7 Jun 2013 20:28:20 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1Ul9p9-0002qG-Oe; Fri, 07 Jun 2013 23:28:15 -0400 Date: Fri, 7 Jun 2013 23:28:15 -0400 From: John Cowan To: Carsten Bormann Message-ID: <20130608032815.GD2528@mercury.ccil.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Cc: Markus Lanthaler , "Joe Hildebrand \(jhildebr\)" , "json@ietf.org" Subject: Re: [Json] Allow any JSON value at the top level X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 08 Jun 2013 03:28:25 -0000 Carsten Bormann scripsit: > I'd call it JSON-value, and write a separate document that defines a > new media type > > application/json-value > > No gratuitous change, no interoperability problems. > > (Actually, we have the production "value" already, so anyone can go > ahead and register that media type.) If there's demand for this, we can register it in this document: no separate document needed. -- If you have ever wondered if you are in hell, John Cowan it has been said, then you are on a well-traveled http://www.ccil.org/~cowan road of spiritual inquiry. If you are absolutely cowan@ccil.org sure you are in hell, however, then you must be on the Cross Bronx Expressway. --Alan Feuer, NYTimes, 2002-09-20 From cowan@ccil.org Fri Jun 7 20:37:35 2013 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 DE16721F99A8 for ; Fri, 7 Jun 2013 20:37:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.356 X-Spam-Level: X-Spam-Status: No, score=-3.356 tagged_above=-999 required=5 tests=[AWL=0.243, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r6m+8TvpYNo9 for ; Fri, 7 Jun 2013 20:37:31 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id 91AD721F9998 for ; Fri, 7 Jun 2013 20:37:31 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1Ul9y4-0003h8-4p; Fri, 07 Jun 2013 23:37:28 -0400 Date: Fri, 7 Jun 2013 23:37:28 -0400 From: John Cowan To: Allen Wirfs-Brock Message-ID: <20130608033727.GH2528@mercury.ccil.org> References: <51AF9ACF.5020507@cisco.com> <51AFB3F8.8060708@crockford.com> <8F32953C-C788-4DC9-888E-920E2BEB7FDD@yahoo.com> <831B8E46-F239-4353-8F95-8DF3F9BD2E78@yahoo.com> <51AFC924.2030805@crockford.com> <8E679529-8663-4552-A905-529E732AEB7B@yahoo.com> <89FDB01C-B5B1-43DF-AFE1-845B8E8E96B5@wirfs-brock.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <89FDB01C-B5B1-43DF-AFE1-845B8E8E96B5@wirfs-brock.com> User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Cc: Vinny A , Paul Hoffman , "json@ietf.org" Subject: Re: [Json] The names within an object SHOULD be unique. X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 08 Jun 2013 03:37:36 -0000 Allen Wirfs-Brock scripsit: > In general, the ECMAScript specification is hyper prescriptive about > many behaviors, such as this, that traditionally would have been > considered reasonable areas to allow implementation variability. I've often wondered why ECMAScript remains silent about the order of property enumeration. -- John Cowan cowan@ccil.org http://ccil.org/~cowan The whole of Gaul is quartered into three halves. --Julius Caesar From cowan@ccil.org Fri Jun 7 20:40:24 2013 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 57FDA11E80A3 for ; Fri, 7 Jun 2013 20:40:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.365 X-Spam-Level: X-Spam-Status: No, score=-3.365 tagged_above=-999 required=5 tests=[AWL=0.234, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3+CimKU+Slqo for ; Fri, 7 Jun 2013 20:40:20 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id E3AE811E80A2 for ; Fri, 7 Jun 2013 20:40:19 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1UlA0n-0003ug-26; Fri, 07 Jun 2013 23:40:17 -0400 Date: Fri, 7 Jun 2013 23:40:17 -0400 From: John Cowan To: Peter Brooks Message-ID: <20130608034016.GJ2528@mercury.ccil.org> References: <51B0E02E.4070209@crockford.com> <1BD0044B-D7A6-4C7F-899E-5D3E72C62956@vpnc.org> <51B116FE.9050406@crockford.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Cc: Paul Hoffman , Douglas Crockford , "json@ietf.org" Subject: Re: [Json] Security Considerations X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 08 Jun 2013 03:40:24 -0000 Peter Brooks scripsit: > If JSON messages are exchanged in cleartext, that, itself, is > an indication that they are public and unimportant, so the risk, even > if they are intercepted and modified, is low. Open text is not necessarily unimportant text. Consider these email messages, which are sent en clair. -- Newbies always ask: John Cowan "Elements or attributes? http://www.ccil.org/~cowan Which will serve me best?" cowan@ccil.org Those who know roar like lions; Wise hackers smile like tigers. --a tanka, or extended haiku From sayrer@gmail.com Fri Jun 7 22:37:50 2013 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 08A1221F96D9 for ; Fri, 7 Jun 2013 22:37:50 -0700 (PDT) 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=[AWL=0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4SXgntSAgPR0 for ; Fri, 7 Jun 2013 22:37:49 -0700 (PDT) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) by ietfa.amsl.com (Postfix) with ESMTP id 504C221F96C2 for ; Fri, 7 Jun 2013 22:37:49 -0700 (PDT) Received: by mail-wi0-f176.google.com with SMTP id ey16so1888115wid.3 for ; Fri, 07 Jun 2013 22:37:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=9Xv0s8sg/EWCu1qB7vvR5vf1hhrP+0/MUfS3F/Y3yfY=; b=Fl27yFHX09sVmktbRAfmJjiV/Vlp9+nDzziaizttD+/MwWEVAwHHiObx7WCJolTYih z8n64V2LqxX8ltu5cSNiu93NydYGwAqFYSOJuPX1krAsMiYPXzTE9P7d+hzWC3uJG9oH pLs0QuJ0snQ/9ty5VvwcqMV+f7DXXUjC00LqWGrdm78d3UylyeG95654P/765X0jV+sa n/u/ADfhU2TPTkpvGN09gPp0VLyfB3U6j3g8zFtChQsdgHt5e8Jk9QjFL8O7Rle3D9H1 FYP8+vvD9aVP+HfnoGeunyq18/mMYRsHMjC8JY9FghMVknLSBvx6lgF+SYU+V2+MDYJE sn2g== MIME-Version: 1.0 X-Received: by 10.180.185.4 with SMTP id ey4mr388385wic.49.1370669868240; Fri, 07 Jun 2013 22:37:48 -0700 (PDT) Received: by 10.194.83.35 with HTTP; Fri, 7 Jun 2013 22:37:47 -0700 (PDT) In-Reply-To: <20130608033727.GH2528@mercury.ccil.org> References: <51AF9ACF.5020507@cisco.com> <51AFB3F8.8060708@crockford.com> <8F32953C-C788-4DC9-888E-920E2BEB7FDD@yahoo.com> <831B8E46-F239-4353-8F95-8DF3F9BD2E78@yahoo.com> <51AFC924.2030805@crockford.com> <8E679529-8663-4552-A905-529E732AEB7B@yahoo.com> <89FDB01C-B5B1-43DF-AFE1-845B8E8E96B5@wirfs-brock.com> <20130608033727.GH2528@mercury.ccil.org> Date: Fri, 7 Jun 2013 22:37:47 -0700 Message-ID: From: R S To: John Cowan Content-Type: multipart/alternative; boundary=001a11c3502299d86604de9df22d Cc: Allen Wirfs-Brock , "json@ietf.org" , Paul Hoffman , Vinny A Subject: Re: [Json] The names within an object SHOULD be unique. X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 08 Jun 2013 05:37:50 -0000 --001a11c3502299d86604de9df22d Content-Type: text/plain; charset=ISO-8859-1 On Fri, Jun 7, 2013 at 8:37 PM, John Cowan wrote: > Allen Wirfs-Brock scripsit: > > > In general, the ECMAScript specification is hyper prescriptive about > > many behaviors, such as this, that traditionally would have been > > considered reasonable areas to allow implementation variability. > > I've often wondered why ECMAScript remains silent about the order > of property enumeration. It is largely uniform, but iirc there are differences in implementations when enumerating properties that are array indices, and no consensus on resolving the differences there. - Rob --001a11c3502299d86604de9df22d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, Jun 7, 2013 at 8:37 PM, John Cowan <cowan@me= rcury.ccil.org> wrote:
Allen Wirfs-Brock scripsit:

> In general, the ECMAScript specification is hyper prescriptive about > many behaviors, such as this, that traditionally would have been
> considered reasonable areas to allow implementation variability.

I've often wondered why ECMAScript remains silent about the order=
of property enumeration.


It = is largely uniform, but iirc there are differences in implementations when = enumerating properties that are array indices, and no consensus on resolvin= g the differences there.

- Rob=A0
--001a11c3502299d86604de9df22d-- From peter.h.m.brooks@gmail.com Sat Jun 8 00:23:17 2013 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 B2DA021F995C for ; Sat, 8 Jun 2013 00:23:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d7yihtSSjYSR for ; Sat, 8 Jun 2013 00:23:16 -0700 (PDT) Received: from mail-we0-x229.google.com (mail-we0-x229.google.com [IPv6:2a00:1450:400c:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id E67F221F9640 for ; Sat, 8 Jun 2013 00:23:15 -0700 (PDT) Received: by mail-we0-f169.google.com with SMTP id n57so3683615wev.28 for ; Sat, 08 Jun 2013 00:22:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; bh=gOj6iMY/rdb6eoofy/ymPfwycFjtnAd+ElChvJvRjpo=; b=maJs8S5J4vjaCH7XuPLHn+ZixhL8qLPtHh3lihgEGYnSxwKRo0cE3VhrWHJUDHSzSm uFOqYIuFnI2tucjJ21pvZ2t3klOSiqMxF6TZHsUmY6Jjpa7WTwMM9mwDijmEjYzTJ1BR xSxlwzFGBgBEkmDlS27xQLh3axawYumObT3W7+Uvx8bylpDba3mrEjeIXdUvCuv+xyrq UBBq7SLumsskfJbw30daytHCuMsRU5K3AlCdjLIc97bXYuBZPAwQPXrT2kKir3sACaco yYNy/ZyLS7zTwPwznfUepWJyxypweA1kJHzMPVFnFa8P4wAffqLN2kP2mpn87aj6/fta ka8Q== X-Received: by 10.180.149.171 with SMTP id ub11mr510512wib.40.1370676170375; Sat, 08 Jun 2013 00:22:50 -0700 (PDT) Received: from [41.4.127.1] ([41.1.33.4]) by mx.google.com with ESMTPSA id cw8sm996152wib.7.2013.06.08.00.22.29 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 08 Jun 2013 00:22:49 -0700 (PDT) References: <51B0E02E.4070209@crockford.com> <1BD0044B-D7A6-4C7F-899E-5D3E72C62956@vpnc.org> <51B116FE.9050406@crockford.com> <20130608034016.GJ2528@mercury.ccil.org> In-Reply-To: <20130608034016.GJ2528@mercury.ccil.org> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPad Mail (10B329) From: Peter brooks Date: Sat, 8 Jun 2013 09:00:53 +0200 To: John Cowan Cc: Paul Hoffman , Douglas Crockford , "json@ietf.org" Subject: Re: [Json] Security Considerations X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 08 Jun 2013 07:23:17 -0000 Sent from my iPad On 8 Jun 2013, at 05:40, John Cowan wrote: > Peter Brooks scripsit: >=20 >> If JSON messages are exchanged in cleartext, that, itself, is >> an indication that they are public and unimportant, so the risk, even >> if they are intercepted and modified, is low. >=20 > Open text is not necessarily unimportant text. Consider these email > messages, which are sent en clair. >=20 I agree. This, though, is bad practice. Any responsible organisation ought t= o encrypt its sensitive information.=20= From stefan@drees.name Sat Jun 8 00:46:50 2013 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 B98C321F99CD for ; Sat, 8 Jun 2013 00:46:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.202 X-Spam-Level: X-Spam-Status: No, score=-2.202 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Ih1dZrGE7B8 for ; Sat, 8 Jun 2013 00:46:45 -0700 (PDT) Received: from mout.web.de (mout.web.de [212.227.15.4]) by ietfa.amsl.com (Postfix) with ESMTP id A718D21F99A6 for ; Sat, 8 Jun 2013 00:46:44 -0700 (PDT) Received: from newyork.local.box ([93.129.147.120]) by smtp.web.de (mrweb004) with ESMTPSA (Nemesis) id 0MP2Sl-1UhfcU3JSR-006KoY; Sat, 08 Jun 2013 09:46:19 +0200 Message-ID: <51B2E149.5010503@drees.name> Date: Sat, 08 Jun 2013 09:46:17 +0200 From: Stefan Drees User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Peter brooks References: <51B0E02E.4070209@crockford.com> <1BD0044B-D7A6-4C7F-899E-5D3E72C62956@vpnc.org> <51B116FE.9050406@crockford.com> <20130608034016.GJ2528@mercury.ccil.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:svK5Tag71kTDwM4McNeGSMIge/z4Snflp0SDj3031F7Ve7A70lY w0O1oEC4Ziuow5qqXIM74THxgk57XSp0CoRWIhkK3Ce86FX5zHDrL2lb8ozBZGDq78pbkxo rJZerZGtLscYUVJI7k+d3yQbFFa1kta3zA/boz5H1eilBFEgrr8wPo1WAj3fFYDEcm4JObb fqrhDM6p9tlo0gmvUzIkQ== Cc: John Cowan , Paul Hoffman , Douglas Crockford , "json@ietf.org" Subject: Re: [Json] Security Considerations X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stefan@drees.name List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jun 2013 07:46:50 -0000 On 08.06.13 09:00, Peter Brooks wrote: ... > On 8 Jun 2013, at 05:40, John Cowan ... wrote: >> Peter Brooks scripsit: >> >>> If JSON messages are exchanged in cleartext, that, itself, is >>> an indication that they are public and unimportant, so the risk, even >>> if they are intercepted and modified, is low. >> >> Open text is not necessarily unimportant text. Consider these email >> messages, which are sent en clair. >> > I agree. This, though, is bad practice. Any responsible organisation > ought to encrypt its sensitive information. No, please do not label "any" cleartext exchange of broadly classified "sensitive information" as a generally "bad practice". For "secrets" ok, but "sensitive"? No, not in general. Every communication has its setup phase, many communication channels over time change in the degree of what the impact of the transported data on the participants or others might be, even time may change the amount of "sensitivity" (like the words and deeds of a young person might interfere later with the same person later and in unintended ways). Shaping the future JSON Format for Data Interchange is also possibly much more "sensitive" (as it impacts all conforming future JSON messages), than attacking the integrity, confidentiality, or flow of some JSON text instances based on that spec ;-) All the best, Stefan. From peter.h.m.brooks@gmail.com Sat Jun 8 00:58:26 2013 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 CF18D21F99D8 for ; Sat, 8 Jun 2013 00:58:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D6eHVHl1-l6u for ; Sat, 8 Jun 2013 00:58:26 -0700 (PDT) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 3275C21F9998 for ; Sat, 8 Jun 2013 00:58:26 -0700 (PDT) Received: by mail-wi0-f173.google.com with SMTP id hi5so1925843wib.0 for ; Sat, 08 Jun 2013 00:58:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; bh=uUVBAo05pYe6K+YUPKOWU8Xx8k/A8VUw6B9BbfK7k3w=; b=j34Ma+8XLiyHnhTKSJIKKYJXZv7fHkbqjGaN1FuV1dh/6NY4khtJlpS8OPG4m1Qx3l x8u9/DYUNQ4RIp+L++phVxFHhZ0LZyDuUKBMMzzykiHagzBNkZMSTWz57xB3NAgm3q2s etuZjz4REFexi4SGvteybXsKqlB6J9JUKteuVr3ZqXr3As0EnweFVw/dRflVJbfyPE7b r3NiphVZDkw59x6ZFAEDNTI4sg49J262irCEjwHgxkzRHuKn060lBH01ROOrsMV/qX+K jEFPbpuFQ68eQ/xM2LIU6wv9T7HvlkruP2UuRGZCNBZ8IUp/gmhtykG/dt6+JRqJD98X XQBw== X-Received: by 10.180.208.109 with SMTP id md13mr530604wic.57.1370678304710; Sat, 08 Jun 2013 00:58:24 -0700 (PDT) Received: from [41.4.127.1] ([41.4.127.1]) by mx.google.com with ESMTPSA id d10sm1136161wik.0.2013.06.08.00.58.14 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 08 Jun 2013 00:58:23 -0700 (PDT) References: <51B0E02E.4070209@crockford.com> <1BD0044B-D7A6-4C7F-899E-5D3E72C62956@vpnc.org> <51B116FE.9050406@crockford.com> <20130608034016.GJ2528@mercury.ccil.org> <51B2E149.5010503@drees.name> In-Reply-To: <51B2E149.5010503@drees.name> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPad Mail (10B329) From: Peter brooks Date: Sat, 8 Jun 2013 09:53:05 +0200 To: "stefan@drees.name" Cc: John Cowan , Paul Hoffman , Douglas Crockford , "json@ietf.org" Subject: Re: [Json] Security Considerations X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 08 Jun 2013 07:58:26 -0000 >=20 >=20 >=20 > Shaping the future JSON Format for Data Interchange is also possibly much m= ore "sensitive" (as it impacts all conforming future JSON messages), than at= tacking the integrity, confidentiality, or flow of some JSON text instances b= ased on that spec ;-) >=20 I agree completely. That is why a proper security spec is important.=20 You are quite right about current bad practice. It should be taken as a warn= ing and reason to do better.=20= From stefan@drees.name Sat Jun 8 01:16:59 2013 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 5605721F92F5 for ; Sat, 8 Jun 2013 01:16:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.205 X-Spam-Level: X-Spam-Status: No, score=-2.205 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nezzGO8pFFjd for ; Sat, 8 Jun 2013 01:16:53 -0700 (PDT) Received: from mout.web.de (mout.web.de [212.227.17.11]) by ietfa.amsl.com (Postfix) with ESMTP id 3CFFC21F9808 for ; Sat, 8 Jun 2013 01:16:37 -0700 (PDT) Received: from newyork.local.box ([93.129.147.120]) by smtp.web.de (mrweb004) with ESMTPSA (Nemesis) id 0MZAp2-1V63Uy1bW0-00KzYt; Sat, 08 Jun 2013 10:16:33 +0200 Message-ID: <51B2E85E.30605@drees.name> Date: Sat, 08 Jun 2013 10:16:30 +0200 From: Stefan Drees User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Paul Hoffman References: <51B0E02E.4070209@crockford.com> <1BD0044B-D7A6-4C7F-899E-5D3E72C62956@vpnc.org> <51B116FE.9050406@crockford.com> <51B1885F.3080908@drees.name> <9D5D948B-BD1E-4195-9B05-3376D6EFFAEA@vpnc.org> <51B20C23.6080303@drees.name> <3571001A-2D76-4F28-AE1B-0512ACC432B3@vpnc.org> In-Reply-To: <3571001A-2D76-4F28-AE1B-0512ACC432B3@vpnc.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:o5sMix2p3iWR2NW88lGp2GKb+MLaE3MTFQsQaKAUKrv6q8AaAs9 LhPYM3lmbEX4EqPcgekcRLyB1izB1uT0f+qAKtmvwNIlnEgWivBc5blvGcPaWrUg2vHRtL7 xHOPhJPe5CP0em5A/tIWB6QdZxn9Z78Aw6b08bbFOjjyycf87zYeYVgnTeR2PDnhYActjxH Wa2uiQ30QUm2p6HucDB/g== Cc: Douglas Crockford , "json@ietf.org" Subject: Re: [Json] Security Considerations X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stefan@drees.name List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jun 2013 08:16:59 -0000 On 2013-06-07 23:32, Paul Hoffman wrote: > On Jun 7, 2013, at 9:36 AM, Stefan Drees wrote: > >> On 2013-06-07 17:58, Paul Hoffman wrote: >>> >>> On Jun 7, 2013, at 12:14 AM, Stefan Drees wrote: >>> >>>> On 07.06.13 01:10, Douglas Crockford wrote: >>>>> On 6/6/2013 4:04 PM, Paul Hoffman wrote: >>>>>> >>>>>> On Jun 6, 2013, at 12:17 PM, Douglas Crockford >>>>>> wrote: >>>>>> >>>>>>> Proposal: >>>>>>> >>>>>>> With any data format, it is important to encode correctly. Care must >>>>>>> be taken when constructing JSON texts by concatenation. For example: >>>>>>> >>>>>>> account = 4627; >>>>>>> comment = "\",\"account\":262"; // provided by attacker >>>>>>> json_text = "(\"account\":" + account + ",\"comment\":\"" + >>>>>>> comment + "\"}"; >>>>>> The example is language-specific and, due to the escaping, hard to read. >>>>> Which specific language would you say it is? Confusion attacks are often >>>>> hard to read. That is why they work. ... >>>> >>>> I propose to keep the example, but remove the need for quoting by switching to single quotes where needed: >>>> >>>> """ >>>> account = 4627; >>>> comment = '","account":262'; // provided by attacker >>>> json_text = '("account":' + account + ',"comment":"' + comment + '"}'; >>>> """ >>>> >>>> this is valid (Java|ECMA)Script, right and also much more readable, isn't it? >>> >>> I can live with this, but I think doing it in English wording is better. >> >> Proposal in English wording: >> >> replace >> OLD(++): >> """ >> With any data format, it is important to encode correctly. Care must >> be taken when constructing JSON texts by concatenation. For example: >> >> account = 4627; >> comment = '","account":262'; // provided by attacker >> json_text = '("account":' + account + ',"comment":"' + comment + '"}'; >> >> """ >> >> with: >> NEW: >> """ >> With any data format, it is important to encode correctly. Care must >> be taken when constructing JSON texts by concatenation in part from untrusted data, this data may inject a mix of structural characters and quotes, that changes the structure of the resulting JSON text. >> For example: When trying to compose an object like >> {"account": 4627, "comment": "foo"} from user input data for "foo", the attacking user might instead inject ","account":262,"comment":"hacked so that the resulting naively concatenated JSON text would become: >> {"account": 4627, "comment": "","account":262,"comment":"hacked"} >> >> >> """ >> >> What do you think? > > I'm liking that more, but we still have quoting problems. They can be solved by linebreaks. > > For example: When trying to compose an object such as: > {"account": 4627, "comment": "foo"} > from user input data for "foo", the attacker might instead inject the text: > ","account":262,"comment":"hacked > so that the resulting naively concatenated JSON text would become: > {"account": 4627, "comment": "","account":262,"comment":"hacked"} I like the indented line formating of the "inserted" or "produced" JSON sample portions. So the proposal NEW is now: """ With any data format, it is important to encode correctly. Care must be taken when constructing JSON texts by concatenation in part from untrusted data, this data may inject a mix of structural characters and quotes, that changes the structure of the resulting JSON text. For example: When trying to compose an object such as: {"account": 4627, "comment": "foo"} from user input data for "foo", the attacking user might instead inject the text: ","account":262,"comment":"hacked so that the resulting naively concatenated JSON text would become: {"account": 4627, "comment": "","account":262,"comment":"hacked"} """ Please note: When discussing technical RFCs, I assume, that the final "to be submitted" paginated text with maximal line character count N determines a lot of the formatting. So I expect us to discuss the "message" as open group and later some persons remove the nits :-) Stefan. From derhoermi@gmx.net Sat Jun 8 01:47:46 2013 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 7B15E21F898B for ; Sat, 8 Jun 2013 01:47:46 -0700 (PDT) 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=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hz129oPWc5Ii for ; Sat, 8 Jun 2013 01:47:42 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by ietfa.amsl.com (Postfix) with ESMTP id C782A21F9362 for ; Sat, 8 Jun 2013 01:47:41 -0700 (PDT) Received: from mailout-de.gmx.net ([10.1.76.20]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0MRyq4-1UvZcE2e3W-00THLE for ; Sat, 08 Jun 2013 10:47:40 +0200 Received: (qmail invoked by alias); 08 Jun 2013 08:47:40 -0000 Received: from p54B4EB09.dip0.t-ipconnect.de (EHLO netb.Speedport_W_700V) [84.180.235.9] by mail.gmx.net (mp020) with SMTP; 08 Jun 2013 10:47:40 +0200 X-Authenticated: #723575 X-Provags-ID: V01U2FsdGVkX1+FFeUTe+yF2Y9aNfye8NX5s9vDvfq6ZEpITHKSuf Pf+u0Q7vg/dQ4f From: Bjoern Hoehrmann To: John Cowan Date: Sat, 08 Jun 2013 10:47:42 +0200 Message-ID: <0rq5r8hmbdum0aj6l1usdb9ciulaghf0lc@hive.bjoern.hoehrmann.de> References: <51B1B4E7.8090101@it.aoyama.ac.jp> <9ld3r8pc0tufif18dohb2fmi0ijna1vs4n@hive.bjoern.hoehrmann.de> <56A163E9-E7CD-46B3-9984-8F009EBFF500@vpnc.org> <20130608030620.GA2528@mercury.ccil.org> In-Reply-To: <20130608030620.GA2528@mercury.ccil.org> X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 Cc: "json@ietf.org" Subject: Re: [Json] On characters and code points X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 08 Jun 2013 08:47:46 -0000 * John Cowan wrote: >Nico Williams scripsit: > >> But corrigendum #9 does make me think that the best thing to do is to >> pass them through, as with any other noncharacters and private-use >> code points. If nothing else it's one less thing to check for in a >> parser. > >If the parser provides an internal representation other than UTF-16, >however, that just isn't possible. Unpaired surrogate code points cannot be represented in UTF-16 and you can easily use e.g. `UTF-32-but-allow-unpaired-surrogates` internally. -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ From cabo@tzi.org Sat Jun 8 02:38:40 2013 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 04B9D21F962A for ; Sat, 8 Jun 2013 02:38:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.708 X-Spam-Level: X-Spam-Status: No, score=-105.708 tagged_above=-999 required=5 tests=[AWL=0.541, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vt3ii1ps-BDj for ; Sat, 8 Jun 2013 02:38:34 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id D504821F9607 for ; Sat, 8 Jun 2013 02:38:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r589cQBM027313; Sat, 8 Jun 2013 11:38:26 +0200 (CEST) Received: from [192.168.217.105] (p54893DC9.dip0.t-ipconnect.de [84.137.61.201]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 816223570; Sat, 8 Jun 2013 11:38:26 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <56A163E9-E7CD-46B3-9984-8F009EBFF500@vpnc.org> Date: Sat, 8 Jun 2013 11:38:25 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <51B06F38.8050707@crockford.com> <51B1B4E7.8090101@it.aoyama.ac.jp> <9ld3r8pc0tufif18dohb2fmi0ijna1vs4n@hive.bjoern.hoehrmann.de> <56A163E9-E7CD-46B3-9984-8F009EBFF500@vpnc.org> To: Paul Hoffman X-Mailer: Apple Mail (2.1503) Cc: "json@ietf.org" Subject: Re: [Json] On characters and code points X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 08 Jun 2013 09:38:40 -0000 On Jun 7, 2013, at 17:56, Paul Hoffman wrote: > Remove the word "character" from the spec except in an explanatory = paragraph in Section 2.5 that says: > All code points, even those that represent non-characters in the = Unicode specification [UNICODE], are allowed in JSON strings. A much better way to handle this problem would be "For the purposes of this specification, the term "character" includes = both Unicode characters and ______." Fill in the blanks based on what we want to do here: (1) I think it is now clear that we don't want to shun Unicode = non-characters (see corrigendum #9). (2) I think it is also clear that we want to include all Unicode code = positions that could become Unicode characters in future versions of = Unicode according to the compatibility spec. (3) I also think that we don't want to change UTF-8, the UTF-16s, or the = UTF-32s, so what's possible in "native" encoding will be controlled by = those specifications, minus ", \, the C0 characters. (4) The remaining question appears what we do with unpaired escaped = surrogates. The answer will have to be a bit wishy-washy, because anything strong = will invalidate half of the implementations. If is probably a good idea = not to "break" those applications that compensate JavaScript's lack of a = binary string type by using UTF-16 as a vector of unconstrained 16-bit = values, but we also cannot mandate that everyone adopt this 1990s style = hack. Is my conclusion correct that, at the model level, it's either = 0x0..0x10FFFF (including unpaired surrogates) or = 0x0..0xD7FF+0xE000..0x10FFFF (without unpaired surrogates, i.e. the = Unicode scalar values)? Parts of this range will only be accessible by = escape sequences (", \, C0, and, when allowed, unpaired surrogates). Gr=FC=DFe, Carsten From stefan@drees.name Sat Jun 8 02:56:52 2013 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 3DCB021F9A14 for ; Sat, 8 Jun 2013 02:56:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.207 X-Spam-Level: X-Spam-Status: No, score=-2.207 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IebCymRjyvif for ; Sat, 8 Jun 2013 02:56:46 -0700 (PDT) Received: from mout.web.de (mout.web.de [212.227.15.14]) by ietfa.amsl.com (Postfix) with ESMTP id 1F55B21F9A0C for ; Sat, 8 Jun 2013 02:56:45 -0700 (PDT) Received: from newyork.local.box ([93.129.147.120]) by smtp.web.de (mrweb002) with ESMTPSA (Nemesis) id 0LqUKH-1U7mCR3LxB-00dvRk; Sat, 08 Jun 2013 11:56:43 +0200 Message-ID: <51B2FFD9.4030106@drees.name> Date: Sat, 08 Jun 2013 11:56:41 +0200 From: Stefan Drees User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Tim Bray References: <51B06F38.8050707@crockford.com> <51B1B4E7.8090101@it.aoyama.ac.jp> <9ld3r8pc0tufif18dohb2fmi0ijna1vs4n@hive.bjoern.hoehrmann.de> <56A163E9-E7CD-46B3-9984-8F009EBFF500@vpnc.org> <51B20731.3040300@drees.name> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V02:K0:swaIZuoH44soCGK8yLO2Q066MvMtAlgOXFAqC7gANou Jb2fI7HZZZL6il2KS6p0CeDF/BdRXnEhWUqEr6nwXgNRziDuuj pwj1FwCuA8ALlgT6eHyDyQp6JA5WHCCiW8POl1fYKfGm+qdhVg XVZNSPqTWRD++HSeOFSlgMSeMdPcl3KVfoxoiVV7vf7qcxA/FU 0IQYcTOrOl2KQ5POJiwaQ== Cc: Paul Hoffman , "json@ietf.org" Subject: Re: [Json] On characters and code points X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stefan@drees.name List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jun 2013 09:56:52 -0000 On 2013-06-07 18:19, Tim Bray wrote: > On Fri, Jun 7, 2013 at 9:15 AM, Stefan Drees ... wrote: > > and what about { "Decorate my slash": "\/" } and "general-purpose > string processing software". Isn't this also a case, where you need > a "pre-conditioner" that replaces the JSON specific escape sequence > "\" with "/" before feeding it into "general-purpose string > processing software" :-?) > > > Red herring. JSON, just like XML, has ways to encode characters that > are hard to type. What we're arguing about is the actual content of the > payload after the parser/pre-conditioner. -T ... I beg to differ. I probed the claim, that "general-purpose string processing software" would have problems with entity so-and-so but not with JSON text as is. Also, when it comes to "typing" (as human-machine directed communication means) forward slashes, dot-ini files or YAML text in my experience are far more easy to type than JSON text ;-) As John Cowan rightfully stated: "That[the general-purpose string processing software] would be the JSON parser." **but** it's task may be considered being anything from easy to hard. We discuss here on these matters, so it's not a red herring, isn't it? Personal motivation (if time and interest allow): Any differences in expressing common "atomic" values or "core structures" (like type of inter atomic bindings) should be verified as each may introduce otherwise not needed hurdles or even traps in translation. It is data interchange we specify. For a transformation source and target that look quite similar (as eg. JSON variables and corresponding language L "things") for some language L in (ECMAScript, PHP, Pyton, ...) one would expect, to not need any "heavy" lifting when transforming from one representation into another. I observe, that "we programmers" more and more look at our code (esp. atomic variables and structures in some language L), compare these to the serialized (prettyprinted) JSON equivalent and then expect them to be essentially identical (some people even start to think eg. "JSON **is** Python syntax" as recently observed on the python-ideas mailing list when argueing in favour of a JSON serializer). At least one should expect for a successful and proven data interchange format, that the atomic values simply "slip back and forth" and do not need special per-character handling. So the more we extend basic escaping "C"ulture (as we further superset the C escape sequences), the wider this gap will become. Interesting "structural" rule differences (not being candidate to change, I know) are: * the trailing comma allowed (or even needed) in many programming languages for instances of list-like structures being not allowed in JSON objects nor arrays (I am sorry that this will not change) * the JSON need for quoting the names (I am neutral here) do bite us "machine instructing humans" once in a while, don't they? The "might-look-like-a-babylonian" system of programming languages that evolved as solution attempts to the * N humans instructing * M machines with * L languages utilizing * F formats for data interchange or storage to handle * P problems is hopefully offering NP-complete solutions :-) but IMO some of the couplings should be reconsidered with passionate caution from time to time. Maybe now is such a "time" to reconsider some regions of the space spanned by the cartesian product L x (F=JSON). Thanks for reading this long opinionated message (which I also did before sending. Promised ;-) Stefan. From lear@cisco.com Sat Jun 8 06:04:15 2013 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 A212D21F9A1F for ; Sat, 8 Jun 2013 06:04:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.799 X-Spam-Level: X-Spam-Status: No, score=-110.799 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TPQsSh6dqmkv for ; Sat, 8 Jun 2013 06:04:03 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 2EF6921F99B4 for ; Sat, 8 Jun 2013 06:04:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=748; q=dns/txt; s=iport; t=1370696643; x=1371906243; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=xLS4EY/DDOErxa3j+sHAQonlevaEVF0i2iJ2t8xm8v4=; b=FEmcxzpc/hIQ/tAzkXK5OsS8wG9hVdVTohyIWChcHN+wEyKkNPJSK/Ar PXHMdvsoGUK9LeKrT/6LyKjDla1uQOHno6KdbJdjrC8rz5A2Ub1ZRdqaA F6uxW89VNAgqY4mhK0PF0a+GA9G9LDicNdL52TW+CtrwlTerq7FiAuwD7 w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ak8FAPMqs1GQ/khN/2dsb2JhbABagwkwgnZHu0l5FnSCIwEBAQQBAQEgSwoBEAsYAgIFFgsCAgkDAgECARUWGgYNAQUCAQGICQyqe5EZBIEmjhIHgkyBFAOXQJFCgxE6 X-IronPort-AV: E=Sophos;i="4.87,827,1363132800"; d="scan'208";a="155091707" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 08 Jun 2013 13:04:01 +0000 Received: from mctiny.local ([10.61.200.222]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r58D3xHb027363 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 8 Jun 2013 13:03:59 GMT Message-ID: <51B32BBF.5020909@cisco.com> Date: Sat, 08 Jun 2013 15:03:59 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Paul Hoffman References: <51B0E02E.4070209@crockford.com> <51B18B1E.30805@drees.name> <21287B59-F6E3-43E4-891D-4A3744912CBE@vpnc.org> In-Reply-To: <21287B59-F6E3-43E4-891D-4A3744912CBE@vpnc.org> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "json@ietf.org" Subject: Re: [Json] Security Considerations X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 08 Jun 2013 13:04:15 -0000 On 6/7/13 5:59 PM, Paul Hoffman wrote: > On Jun 7, 2013, at 12:26 AM, Stefan Drees wrote: > >> For me the main points of data interchange and in sequence are: >> >> 1. Do not parse any untrusted data without preconditioning I think you include bounds testing in the above? >> >> 2. Do not excecute/eval untrusted data >> >> and trust is sometimes hard to establish ... >> >> As long as these two points stand out and are not burried inside sample language terms, I am happy with any re-phrasing. > That sounds like a good goal for the section. > > --Paul Hoffman > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > > From jorge@jorgechamorro.com Sat Jun 8 06:12:07 2013 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 D29B821F86D5 for ; Sat, 8 Jun 2013 06:12:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mWEC-lRZWVe8 for ; Sat, 8 Jun 2013 06:12:07 -0700 (PDT) Received: from mail-we0-x22a.google.com (mail-we0-x22a.google.com [IPv6:2a00:1450:400c:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 0B43D21F85C9 for ; Sat, 8 Jun 2013 06:12:06 -0700 (PDT) Received: by mail-we0-f170.google.com with SMTP id w57so3801664wes.1 for ; Sat, 08 Jun 2013 06:12:05 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=sdkHN2adno0M25DA0JOk+sNcLUB4jY4J29d9eXc0cKA=; b=GJwItgdboMAtzw/IJBhCEV39oy4TYCHQw69AbUE+CJQSzR592fwazEVGhhS6bJ9leZ //KVSnpKY+WDclxKG3llHoD8/AmRXWbwiO7xlTSnc0Yt1oSkIogCtcNlI27GuIEXWTgT T5bq5sZoMfzmGjhkyeB399zQMMs3/Kupi7G9p6sd7OGYwtpvWcLT9QXOtR0bT76w9eiO W6H7+O0JqlUjYwIAMtDRj5t3zv5PGT/vHJK2GxUeRIN4naTfjov9SkWFqjqSP/bHBuWB MGyoRNzzpRxfGzonL4kzHrmpxaPjlJrwpVY9Jr9zmHWSc1jWH76igZi/ZIyaMgFp43dJ vzFQ== X-Received: by 10.194.173.232 with SMTP id bn8mr1594594wjc.26.1370697125842; Sat, 08 Jun 2013 06:12:05 -0700 (PDT) Received: from [192.168.10.50] (142.Red-83-61-214.dynamicIP.rima-tde.net. [83.61.214.142]) by mx.google.com with ESMTPSA id eq15sm2254153wic.4.2013.06.08.06.12.04 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 08 Jun 2013 06:12:05 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Apple Message framework v1085) From: Jorge In-Reply-To: <51B2A10F.5010006@it.aoyama.ac.jp> Date: Sat, 8 Jun 2013 15:12:03 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <255B9BB34FB7D647A506DC292726F6E1151B21F9A9@WSMSG3153V.srv.dir.telstra.com> <51B2A10F.5010006@it.aoyama.ac.jp> To: =?iso-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= , json@ietf.org X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQmJUkE1a4gEZUn+A9hYRzFQtLpkmtZ+zRFL2EX8Y8Jfr1SU35jNrtelIIjS5X7lw2OZD2Ar Subject: Re: [Json] Allow any JSON value at the top level X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 08 Jun 2013 13:12:08 -0000 On 08/06/2013, at 05:12, Martin J. D=FCrst wrote: >=20 > On 2013/06/08 5:02, Jorge wrote: >> On 07/06/2013, at 15:38, Vinny A wrote: >>>=20 >>> Do commonly used parsers support top level JSON values? >>=20 >> Yes: >>=20 >> JSON.parse('"string"') >> "string" >> JSON.parse('27') >> 27 >> JSON.parse('true') >> true >> JSON.parse('false') >> false >> JSON.parse('null') >> null >>=20 > What programming language/library? JavaScript's built-in parser (ES5). I tried it with ruby's JSON gem but it won't swallow it: >> JSON.parse("\"string\"") JSON::ParserError: 757: unexpected token at '"string"' from = /Library/Ruby/Gems/1.8/gems/json-1.8.0/lib/json/common.rb:155:in `parse' from = /Library/Ruby/Gems/1.8/gems/json-1.8.0/lib/json/common.rb:155:in `parse' from (irb):14 >> JSON.parse("27") JSON::ParserError: 757: unexpected token at '27' from = /Library/Ruby/Gems/1.8/gems/json-1.8.0/lib/json/common.rb:155:in `parse' from = /Library/Ruby/Gems/1.8/gems/json-1.8.0/lib/json/common.rb:155:in `parse' from (irb):15 >> JSON.parse("true") JSON::ParserError: 757: unexpected token at 'true' from = /Library/Ruby/Gems/1.8/gems/json-1.8.0/lib/json/common.rb:155:in `parse' from = /Library/Ruby/Gems/1.8/gems/json-1.8.0/lib/json/common.rb:155:in `parse' from (irb):16 >> JSON.parse("false") JSON::ParserError: 757: unexpected token at 'false' from = /Library/Ruby/Gems/1.8/gems/json-1.8.0/lib/json/common.rb:155:in `parse' from = /Library/Ruby/Gems/1.8/gems/json-1.8.0/lib/json/common.rb:155:in `parse' from (irb):17 >> JSON.parse("null") JSON::ParserError: 757: unexpected token at 'null' from = /Library/Ruby/Gems/1.8/gems/json-1.8.0/lib/json/common.rb:155:in `parse' from = /Library/Ruby/Gems/1.8/gems/json-1.8.0/lib/json/common.rb:155:in `parse' from (irb):18 >> JSON.parse("[27]") =3D> [27] --=20 ( Jorge )();= From James.H.Manger@team.telstra.com Sat Jun 8 06:25:12 2013 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 6F31721F96B1 for ; Sat, 8 Jun 2013 06:25:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.579 X-Spam-Level: X-Spam-Status: No, score=-0.579 tagged_above=-999 required=5 tests=[AWL=0.322, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8+dIUG3vAQqd for ; Sat, 8 Jun 2013 06:25:06 -0700 (PDT) Received: from ipxbno.tcif.telstra.com.au (ipxbno.tcif.telstra.com.au [203.35.82.204]) by ietfa.amsl.com (Postfix) with ESMTP id 0409521F9643 for ; Sat, 8 Jun 2013 06:25:05 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.87,827,1363093200"; d="scan'208";a="133110946" Received: from unknown (HELO ipcbni.tcif.telstra.com.au) ([10.97.216.204]) by ipobni.tcif.telstra.com.au with ESMTP; 08 Jun 2013 23:25:05 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,7099"; a="138672031" Received: from wsmsg3703.srv.dir.telstra.com ([172.49.40.171]) by ipcbni.tcif.telstra.com.au with ESMTP; 08 Jun 2013 23:25:05 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3703.srv.dir.telstra.com ([172.49.40.171]) with mapi; Sat, 8 Jun 2013 23:25:04 +1000 From: "Manger, James H" To: Tim Bray Date: Sat, 8 Jun 2013 23:25:03 +1000 Thread-Topic: [Json] Allow any JSON value at the top level Thread-Index: Ac5jl7EksTMOj9LdR/KAilE/VKtNzQAsJuOA Message-ID: <255B9BB34FB7D647A506DC292726F6E1151B21FF62@WSMSG3153V.srv.dir.telstra.com> References: <255B9BB34FB7D647A506DC292726F6E1151B21F9A9@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "json@ietf.org" Subject: Re: [Json] Allow any JSON value at the top level X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 08 Jun 2013 13:25:12 -0000 Pj4gSSBwcm9wb3NlIGFsbG93aW5nIGEgSlNPTiB0ZXh0IHRvIGJlIGFueSBKU09OIHZhbHVlLg0K DQpUaW0gQnJheSBzYWlkOg0KPiAyLiBUaGlzIGlzIGEgYmFkIGlkZWEgaW4gZ2VuZXJhbCBhbmQg YSB0ZXJyaWJsZSBpZGVhIGZvciBuZXR3b3JrDQo+IHByb3RvY29scywgd2hpY2ggaXMgd2hlcmUg SlNPTiBpcyBtb3N0IHZhbHVhYmxlLg0KDQoNClRpbSwgY291bGQgeW91IGV4cGFuZCBvbiB3aHkg dGhpcyBpcyBiYWQgYW5kIHRlcnJpYmxlPw0KDQpJIHdvdWxkIGhhdmUgdGhvdWdodCBhbiBIVFRQ IHJlcXVlc3QgbGlrZSB0aGlzIHdvdWxkIGJlIGEgcmVhc29uYWJsZSBkZXNpZ24sIGFuZCBzaG91 bGRuJ3QgcmVxdWlyZSBhIG5ldyBtZWRpYSB0eXBlIHRvIGJlIG1pbnRlZDoNCg0KLT4gR0VUIC9w YXRoL3RvL3Jlc291cmNlLmpzb24/cGFydD1qc29uLXBvaW50ZXINCg0KPC0gQ29udGVudC1UeXBl OiBhcHBsaWNhdGlvbi9qc29uDQogICA8SlNPTiB2YWx1ZSBzZWxlY3RlZCBieSBKU09OIHBvaW50 ZXIgaW4gcmVxdWVzdD4NCg0KLS0NCkphbWVzIE1hbmdlcg0K From stefan@drees.name Sat Jun 8 06:33:07 2013 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 78A5521F9922 for ; Sat, 8 Jun 2013 06:33:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.21 X-Spam-Level: X-Spam-Status: No, score=-2.21 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1LOTPR7Jkliw for ; Sat, 8 Jun 2013 06:32:59 -0700 (PDT) Received: from mout.web.de (mout.web.de [212.227.15.14]) by ietfa.amsl.com (Postfix) with ESMTP id 1F72221F9920 for ; Sat, 8 Jun 2013 06:32:58 -0700 (PDT) Received: from newyork.local.box ([93.129.147.120]) by smtp.web.de (mrweb102) with ESMTPSA (Nemesis) id 0MDg9K-1Uaosw2JGY-00H9K7; Sat, 08 Jun 2013 15:32:57 +0200 Message-ID: <51B33287.8040405@drees.name> Date: Sat, 08 Jun 2013 15:32:55 +0200 From: Stefan Drees User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Eliot Lear References: <51B0E02E.4070209@crockford.com> <51B18B1E.30805@drees.name> <21287B59-F6E3-43E4-891D-4A3744912CBE@vpnc.org> <51B32BBF.5020909@cisco.com> In-Reply-To: <51B32BBF.5020909@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V02:K0:90eIw3WtEcKY+3G2rJAdInkapVD6FgY0Cuk7t3IDVMB b/ztsBeNm/cF2eOitR9hqankY6Naio5zhPCmd5vwX6Dv0uv243 bPuD1pq20WXvZ8gUyMHhWxlivmFk/8ZbD8+pR9UgNU33gpHJ7q CxySeg4Rk/dHl44V1Pu99uiD7NEv6cvHUhND0cxPKViVUdT6mt dQbm/79WZzKM2NbRe9EJQ== Cc: Paul Hoffman , "json@ietf.org" Subject: Re: [Json] Security Considerations X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stefan@drees.name List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jun 2013 13:33:07 -0000 On 2013-06-08 15:03, Eliot Lear wrote: > > On 6/7/13 5:59 PM, Paul Hoffman wrote: >> On Jun 7, 2013, at 12:26 AM, Stefan Drees ... wrote: >> >>> For me the main points of data interchange and in sequence are: >>> >>> 1. Do not parse any untrusted data without preconditioning > > I think you include bounds testing in the above? Yes. As a goal I used the broad term "preconditioning" on purpose. The devil is in the details. If one reads the latest draft text (as proposed by me) on parsers: """ 4. Parsers A JSON parser transforms JSON text into another representation, MUST accept all texts that conform to the JSON grammar and MUST be prepared to either accept duplicate names in objects or reject the complete JSON text containing these. A JSON parser MAY accept non-JSON forms or extensions. An implementation may set limits on any of the following: the size of texts that it accepts, the maximum depth of nesting, the range of numbers, and the length and character contents of strings. """ So many needed boundary conditions jump in view, where bounds testing is relevant to block attacks (from the above text): 1. the size of texts that it accepts, 2. the maximum depth of nesting, 3. the range of numbers, and 4. the length and character contents of strings So IMO a JSON message receiver must be prepared to: Ad 1. reject after having received MAX_ACCEPT+1 bytes Ad 2.a keep track of nesting counters CNT_NEST Ad 2.b reject after CNT_NEST > MAX_NEST on first encounter Ad 3.a first scan the CNT_BYTE_N presentation length of number cand Ad 3.b reject if CNT_BYTE_N > SomeNumbersLiteralRepLen_MAX_BYTE Ad 3.c all bytes of number collected match the range OK_RANGE_N Ad 3.d reject if OK_RANGE_N is false Ad 4.a scan the CNT_BYTE_STR of string cand Ad 4.b reject if CNT_BYTE_STR > StringsLiteralRepLen_MAX_BYTE Ad 4.c scan each byte and piddle, piddle all the rules of decoding Ad 4.d reject on first encounter of invalid decoding request I know with all the nitty gritty of say "\/" becomes "/" and other length variations during the process from receipt to memory representation at parsing end, it is clear, that there must be a size limit up front and not "after encoding", which helps the parser to never have a "too full stomach" so to say. That would be (as I said) my personal expectation on handling JSON text coming in from the wild. The important JSON promise of "bounded" data interchange is thus in my view kept by applying the parsers maximum size functions (dealing with the limits of 1,2,3 and 4 above) on the bounds offered inside the generators JSON text the parser tries to scan and tokenize. >>> >>> 2. Do not excecute/eval untrusted data >>> >>> and trust is sometimes hard to establish ... >>> >>> As long as these two points stand out and are not burried inside sample language terms, I am happy with any re-phrasing. >> That sounds like a good goal for the section. ... I think that the second aspect has become more and more accepted reality and is not as important as it was, when JSON was young, and the JS stood for JavaScript ;-) All the best, Stefan. From paul.hoffman@vpnc.org Sat Jun 8 08:25:29 2013 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 200B021F9750 for ; Sat, 8 Jun 2013 08:25:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.396 X-Spam-Level: X-Spam-Status: No, score=-102.396 tagged_above=-999 required=5 tests=[AWL=0.203, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HxEUecsnpEp5 for ; Sat, 8 Jun 2013 08:25:28 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id A0B2F21F96B1 for ; Sat, 8 Jun 2013 08:25:28 -0700 (PDT) Received: from [10.20.30.90] (50-0-66-165.dsl.dynamic.sonic.net [50.0.66.165]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r58FPRQ2041967 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 8 Jun 2013 08:25:28 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Paul Hoffman In-Reply-To: Date: Sat, 8 Jun 2013 08:25:27 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <3A9644F9-A0E2-46FA-B4BD-9A834C2F442B@vpnc.org> References: <51B06F38.8050707@crockford.com> <51B1B4E7.8090101@it.aoyama.ac.jp> <9ld3r8pc0tufif18dohb2fmi0ijna1vs4n@hive.bjoern.hoehrmann.de> <56A163E9-E7CD-46B3-9984-8F009EBFF500@vpnc.org> To: Carsten Bormann X-Mailer: Apple Mail (2.1508) Cc: "json@ietf.org" Subject: Re: [Json] On characters and code points X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 08 Jun 2013 15:25:29 -0000 On Jun 8, 2013, at 2:38 AM, Carsten Bormann wrote: > On Jun 7, 2013, at 17:56, Paul Hoffman wrote: >=20 >> Remove the word "character" from the spec except in an explanatory = paragraph in Section 2.5 that says: >> All code points, even those that represent non-characters in the = Unicode specification [UNICODE], are allowed in JSON strings. >=20 > A much better way to handle this problem would be >=20 > "For the purposes of this specification, the term "character" includes = both Unicode characters and ______." >=20 > Fill in the blanks based on what we want to do here: >=20 > (1) I think it is now clear that we don't want to shun Unicode = non-characters (see corrigendum #9). >=20 > (2) I think it is also clear that we want to include all Unicode code = positions that could become Unicode characters in future versions of = Unicode according to the compatibility spec. >=20 > (3) I also think that we don't want to change UTF-8, the UTF-16s, or = the UTF-32s, so what's possible in "native" encoding will be controlled = by those specifications, minus ", \, the C0 characters. >=20 > (4) The remaining question appears what we do with unpaired escaped = surrogates. > The answer will have to be a bit wishy-washy, because anything strong = will invalidate half of the implementations. If is probably a good idea = not to "break" those applications that compensate JavaScript's lack of a = binary string type by using UTF-16 as a vector of unconstrained 16-bit = values, but we also cannot mandate that everyone adopt this 1990s style = hack. Ummm, how is that "much better"? "Code points minus THEONESWEHATE" seems = a lot simpler than "characters plus ADDITIONAL1 plus ADDITIONAL2 plus = ADDITIONAL3". --Paul Hoffman= From cabo@tzi.org Sat Jun 8 09:07:33 2013 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 47CE821F8763 for ; Sat, 8 Jun 2013 09:07:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.978 X-Spam-Level: X-Spam-Status: No, score=-105.978 tagged_above=-999 required=5 tests=[AWL=0.271, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vNxm26BEiYeB for ; Sat, 8 Jun 2013 09:07:27 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id DE63721F8749 for ; Sat, 8 Jun 2013 09:07:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r58G7DXl028212; Sat, 8 Jun 2013 18:07:13 +0200 (CEST) Received: from [192.168.217.105] (p54893DC9.dip0.t-ipconnect.de [84.137.61.201]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 4450A3614; Sat, 8 Jun 2013 18:07:13 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <3A9644F9-A0E2-46FA-B4BD-9A834C2F442B@vpnc.org> Date: Sat, 8 Jun 2013 18:07:11 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <51B06F38.8050707@crockford.com> <51B1B4E7.8090101@it.aoyama.ac.jp> <9ld3r8pc0tufif18dohb2fmi0ijna1vs4n@hive.bjoern.hoehrmann.de> <56A163E9-E7CD-46B3-9984-8F009EBFF500@vpnc.org> <3A9644F9-A0E2-46FA-B4BD-9A834C2F442B@vpnc.org> To: Paul Hoffman X-Mailer: Apple Mail (2.1503) Cc: "json@ietf.org" Subject: Re: [Json] On characters and code points X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 08 Jun 2013 16:07:33 -0000 On Jun 8, 2013, at 17:25, Paul Hoffman wrote: > Ummm, how is that "much better"? "Code points minus THEONESWEHATE" = seems a lot simpler than "characters plus ADDITIONAL1 plus ADDITIONAL2 = plus ADDITIONAL3". Well, we need a (short) word for "that thing that goes into strings". Most people I know would expect a "string" to be composed of = "characters". So why not define the "character" in such a way that it works for us? RFC 4627 does not go to the length to formally define its terms. In = particular, it is not always clear where a term is imported from = somewhere else, and what that somewhere is. This provides some = potential for improvement. Once this is done, there is no need to use = the term character exactly like Unicode uses it. (The term "Unicode = character" can be used where that specific definition is actually = meant.) Gr=FC=DFe, Carsten From paul.hoffman@vpnc.org Sat Jun 8 13:15:45 2013 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 47A3621F9476 for ; Sat, 8 Jun 2013 13:15:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.108 X-Spam-Level: X-Spam-Status: No, score=-102.108 tagged_above=-999 required=5 tests=[AWL=-0.109, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P-fqZ9EeZ6je for ; Sat, 8 Jun 2013 13:15:44 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id B4F8621F8506 for ; Sat, 8 Jun 2013 13:15:44 -0700 (PDT) Received: from [10.20.30.90] (50-0-66-165.dsl.dynamic.sonic.net [50.0.66.165]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r58KFhcw048312 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Sat, 8 Jun 2013 13:15:44 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) From: Paul Hoffman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: Date: Sat, 8 Jun 2013 13:15:42 -0700 To: "json@ietf.org" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) Subject: [Json] A possible summary of the discussion so far on code points and characters X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 08 Jun 2013 20:15:45 -0000 No hat at all, just trying to get some focus on the current facts before = trying to reach conclusions. 1) Some people have read the following statement from the RFC to mean = "only Unicode characters are allowed in strings": A string is a sequence of zero or more Unicode characters [UNICODE]. 2) The ABNF is more liberal about what can be in a string than that = statement: char =3D unescaped / escape ( ... %x75 4HEXDIG ) ; uXXXX U+XXXX ... unescaped =3D %x20-21 / %x23-5B / %x5D-10FFFF 3) Some JSON parsers enforce (1), rejecting JSON texts that have strings = that have some unallowed code points. 4) Some JSON parsers accept strings with all code points. 5) The definition of "Unicode character" has been surprising to some = people on this list, and thus might be surprising to some developers and = users of JSON. 6) Some people on the list consider some code points that are Unicode = non-characters to be more objectionable than other code points. --Paul Hoffman= From nico@cryptonector.com Sat Jun 8 13:41:51 2013 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 A506A21F9632 for ; Sat, 8 Jun 2013 13:41:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A9EKIk-Sp5MW for ; Sat, 8 Jun 2013 13:41:46 -0700 (PDT) Received: from homiemail-a32.g.dreamhost.com (caiajhbdcbbj.dreamhost.com [208.97.132.119]) by ietfa.amsl.com (Postfix) with ESMTP id 725E821F9600 for ; Sat, 8 Jun 2013 13:41:46 -0700 (PDT) Received: from homiemail-a32.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a32.g.dreamhost.com (Postfix) with ESMTP id 4E485584058 for ; Sat, 8 Jun 2013 13:41:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=kyBWUDCNplhNCS5IqLUwdXEcab8=; b=KyMYzEqZ6i0 IZYFw9XdkewpkJUjqyndWsLsu85RImTL5L9pkbxwd0R1yw+3pu7lkm0PWolEX/iQ 6gQEtpxNWWgNDMp6UVQXVz7PoN4rLXp8VFBq1ujac+yMnbuydxFfUj+bMdBKkECS CLxj7Q03SFhwkyrwmDwy//w3sIQK1o7Y= Received: from mail-wi0-f177.google.com (mail-wi0-f177.google.com [209.85.212.177]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a32.g.dreamhost.com (Postfix) with ESMTPSA id 031F6584057 for ; Sat, 8 Jun 2013 13:41:44 -0700 (PDT) Received: by mail-wi0-f177.google.com with SMTP id ey16so2177525wid.16 for ; Sat, 08 Jun 2013 13:41:43 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=e8uteiSRcJ7u34F7P+xDv+0j9x7vh0SeqPY5l4Nj4RQ=; b=hs+POFK2NJ+7Iy7JKKL5VolETzWs12/8s8KadoIQz5zNOaS1IKtjh/6QBhu6OyUrGK aU85fEfQjvu8u/mrcblt4I9471MAaxEu9t1NH5ydzYgqHomEsgZAdRUmGAP16bfByM2H Lpta0KL0RhEe5j2kOdkzsFzm3osisGLajhyAl68mHnfoBojqh2lhfEYENF6gP16injo1 KvuwCXAAh/dnFhQigxgMYqBu6zlEbbA2QiUPu4xec//wW2cwMERrNaGBnZ65m+nzELGt +oDGsjo8IiVP4n1Fouwrxaas6MYoQi/oim9PqH08+qEbSrmkkpKM5y1qN3ti+UZZKC03 vlHg== MIME-Version: 1.0 X-Received: by 10.181.12.1 with SMTP id em1mr1580670wid.4.1370724103463; Sat, 08 Jun 2013 13:41:43 -0700 (PDT) Received: by 10.216.63.136 with HTTP; Sat, 8 Jun 2013 13:41:43 -0700 (PDT) In-Reply-To: <3A9644F9-A0E2-46FA-B4BD-9A834C2F442B@vpnc.org> References: <51B06F38.8050707@crockford.com> <51B1B4E7.8090101@it.aoyama.ac.jp> <9ld3r8pc0tufif18dohb2fmi0ijna1vs4n@hive.bjoern.hoehrmann.de> <56A163E9-E7CD-46B3-9984-8F009EBFF500@vpnc.org> <3A9644F9-A0E2-46FA-B4BD-9A834C2F442B@vpnc.org> Date: Sat, 8 Jun 2013 15:41:43 -0500 Message-ID: From: Nico Williams To: Paul Hoffman Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Carsten Bormann , "json@ietf.org" Subject: Re: [Json] On characters and code points X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 08 Jun 2013 20:41:51 -0000 On Sat, Jun 8, 2013 at 10:25 AM, Paul Hoffman wrote= : > On Jun 8, 2013, at 2:38 AM, Carsten Bormann wrote: >> (4) The remaining question appears what we do with unpaired escaped surr= ogates. >> The answer will have to be a bit wishy-washy, because anything strong wi= ll invalidate half of the implementations. If is probably a good idea not = to "break" those applications that compensate JavaScript's lack of a binary= string type by using UTF-16 as a vector of unconstrained 16-bit values, bu= t we also cannot mandate that everyone adopt this 1990s style hack. I'm starting to conclude that "anything goes..." "...with the understanding that in some cases some, er, code points get dropped". E.g., a surrogate encoded in UTF-8 or UTF-32 makes no sense, and though some parsers can leave it be, a parser that converts to UTF-16 probably can't leave there. Note that there's a bit of a difference between an escaped and an unescaped such code point: the former might be an attempt to pass binary data, while the latter could just be either an error or the result of unescaping the first. > Ummm, how is that "much better"? "Code points minus THEONESWEHATE" seems = a lot simpler than "characters plus ADDITIONAL1 plus ADDITIONAL2 plus ADDIT= IONAL3". The latter seems better in that we defer the definition of "character" to the UC, but the former seems better in that it's much more specific about THEONESWEHATE. The latter seems likely to allow more interoperability with any implementations that allow just about anything. Nico -- From sayrer@gmail.com Sat Jun 8 13:52:28 2013 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 486CA21F85E0 for ; Sat, 8 Jun 2013 13:52:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id md9hr42BTrbp for ; Sat, 8 Jun 2013 13:52:27 -0700 (PDT) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) by ietfa.amsl.com (Postfix) with ESMTP id CDD6B21F85D1 for ; Sat, 8 Jun 2013 13:52:26 -0700 (PDT) Received: by mail-wi0-f179.google.com with SMTP id hm9so2180246wib.6 for ; Sat, 08 Jun 2013 13:52:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=bJlFbuENtQUoBHE9art41Th4iTtvRRE02uANZFlGTW4=; b=RhvVx2BBaHQRcsbvlmV0WDcJ9EDapWAFqblC1o2kzR9fYXgME6dXQsR7ZQXU4WMYP9 qGllqIfVKW4utnu1oGzlN8BCholzzJ97rvIdRxMx4vsB+UJ0gGk7gAZcyoz/GuKgQMHS K/OEQoGb9+ELfTm9UmumT/K2kmgMwzfCoEfDCf1RXBwYccc2fAPdihZsYo6X8m5KY0W0 V3okTFKkNLziBwLvi18dVLVfGXC6ueJiHj8bq/p4EP0mkjOVkOoR3gSXicnKOX8Cs53e tIxodALwL6pV+2rnPzK0Zfo4TSu57Pr7Ag4H3MjSfYiBE8/C3P+bUIIwBARnkJqYx9ek kkDg== MIME-Version: 1.0 X-Received: by 10.194.58.239 with SMTP id u15mr2102022wjq.87.1370724745826; Sat, 08 Jun 2013 13:52:25 -0700 (PDT) Received: by 10.194.83.35 with HTTP; Sat, 8 Jun 2013 13:52:25 -0700 (PDT) In-Reply-To: References: Date: Sat, 8 Jun 2013 13:52:25 -0700 Message-ID: From: R S To: Paul Hoffman Content-Type: multipart/alternative; boundary=047d7ba97b948f59fb04deaab9b2 Cc: "json@ietf.org" Subject: Re: [Json] A possible summary of the discussion so far on code points and characters X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 08 Jun 2013 20:52:28 -0000 --047d7ba97b948f59fb04deaab9b2 Content-Type: text/plain; charset=ISO-8859-1 A seventh point of view, which I happen to agree with: JSON strings are a sequence of code units. This is similar to the definition of 'source text' in ECMAScript: "ECMAScript source text is assumed to be a sequence of 16-bit code units for the purposes of this specification. Such a source text may include sequences of 16-bit code units that are not valid UTF-16 character encodings." http://es5.github.io/x6.html - Rob On Sat, Jun 8, 2013 at 1:15 PM, Paul Hoffman wrote: > No hat at all, just trying to get some focus on the current facts before > trying to reach conclusions. > > 1) Some people have read the following statement from the RFC to mean > "only Unicode characters are allowed in strings": > A string is a sequence of zero or more Unicode characters [UNICODE]. > > 2) The ABNF is more liberal about what can be in a string than that > statement: > char = unescaped / > escape ( ... > %x75 4HEXDIG ) ; uXXXX U+XXXX > ... > unescaped = %x20-21 / %x23-5B / %x5D-10FFFF > > 3) Some JSON parsers enforce (1), rejecting JSON texts that have strings > that have some unallowed code points. > > 4) Some JSON parsers accept strings with all code points. > > 5) The definition of "Unicode character" has been surprising to some > people on this list, and thus might be surprising to some developers and > users of JSON. > > 6) Some people on the list consider some code points that are Unicode > non-characters to be more objectionable than other code points. > > --Paul Hoffman > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > --047d7ba97b948f59fb04deaab9b2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
A seventh point of view, which I happen to agree with: JSO= N strings are a sequence of code units.

This is similar = to the definition of 'source text' in ECMAScript:
"ECMAScript source text is assumed to be a sequence o= f 16-bit code units for the purposes of this specification. Such a source t= ext may include sequences of 16-bit code units that are not valid UTF-16 ch= aracter encodings."


- Rob

<= br>
On Sat, Jun 8, 2013 at 1:15 PM, Paul Hoffman= <paul.hoffman@vpnc.org> wrote:
No hat at all, just trying to get some focus on the current facts before tr= ying to reach conclusions.

1) Some people have read the following statement from the RFC to mean "= ;only Unicode characters are allowed in strings":
=A0 =A0A string is a sequence of zero or more Unicode characters [UNICODE].=

2) The ABNF is more liberal about what can be in a string than that stateme= nt:
=A0 =A0 =A0 char =3D unescaped /
=A0 =A0 =A0 =A0 =A0 escape ( ...
=A0 =A0 =A0 =A0 =A0 =A0 =A0 %x75 4HEXDIG ) =A0; uXXXX =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0U+XXXX
=A0 =A0 =A0 ...
=A0 =A0 =A0 unescaped =3D %x20-21 / %x23-5B / %x5D-10FFFF

3) Some JSON parsers enforce (1), rejecting JSON texts that have strings th= at have some unallowed code points.

4) Some JSON parsers accept strings with all code points.

5) The definition of "Unicode character" has been surprising to s= ome people on this list, and thus might be surprising to some developers an= d users of JSON.

6) Some people on the list consider some code points that are Unicode non-c= haracters to be more objectionable than other code points.

--Paul Hoffman
_______________________________________________
json mailing list
json@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/json

--047d7ba97b948f59fb04deaab9b2-- From stedolan@stedolan.net Sat Jun 8 14:08:09 2013 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 59FD921F92F5 for ; Sat, 8 Jun 2013 14:08:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.089 X-Spam-Level: * X-Spam-Status: No, score=1.089 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_35=0.6, J_CHICKENPOX_45=0.6, RDNS_NONE=0.1, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HdP3z0BBeBMO for ; Sat, 8 Jun 2013 14:08:04 -0700 (PDT) Received: from mail-la0-x231.google.com (mail-la0-x231.google.com [IPv6:2a00:1450:4010:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id B193E21F8895 for ; Sat, 8 Jun 2013 14:08:00 -0700 (PDT) Received: by mail-la0-f49.google.com with SMTP id ea20so1146003lab.36 for ; Sat, 08 Jun 2013 14:07:59 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:x-originating-ip:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :x-gm-message-state; bh=jsOcG1FiSgGR9jxpLncALZ2VTtNUbTPH/Bbl21M8wpQ=; b=d+Q2b5TtVuILm8bJYsoJXO8o3qox9eq5he+4utoh/eyyph31RVsLHFj7dxK76vMdW2 Fbrpvww9L66POk8Z9txmfz4ku2hZNZuEuDhnmSJpEf+kCR50mipje3dznolwAeGO97Bb cyKQ3fKiwiEQ8x5R6k8P+tirA4TV//kE55T/DKEwxzuEiKpYHX2Qw7dncyRlQvMm98Zm yvAo5/6webQpGOFPdy/YVA0UbTQM2/llo/MJLfv0a9ycY1QyrMQ3hdkSJUGDfKVQDJeV gExLqMuH8ndMxLmloB10P5uDLLRWr1dA6fSGc6MYaXZt2DMeXdKX8rVM/DP/axHgOCB+ gVEw== MIME-Version: 1.0 X-Received: by 10.112.63.2 with SMTP id c2mr3672164lbs.6.1370725679400; Sat, 08 Jun 2013 14:07:59 -0700 (PDT) Sender: stedolan@stedolan.net Received: by 10.114.176.231 with HTTP; Sat, 8 Jun 2013 14:07:59 -0700 (PDT) X-Originating-IP: [131.111.184.8] In-Reply-To: <51B1FE6A.80409@drees.name> References: <51AF8479.5080002@crockford.com> <51b1168c.e686440a.5339.5fc4SMTPIN_ADDED_BROKEN@mx.google.com> <51B1B47C.9060009@drees.name> <51B1E909.2010402@drees.name> <51B1FE6A.80409@drees.name> Date: Sat, 8 Jun 2013 22:07:59 +0100 X-Google-Sender-Auth: Wf75enb_N5yRg0nVe5EWE4ShM7Y Message-ID: From: Stephen Dolan To: stefan@drees.name Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQkHdY2uqy0oSAKkDYTSd8zz5FFWEm9qGwQE6fAYJyQZUDgmBgxfafFUhWHPefZK7pX036eW Cc: Vinny A , Markus Lanthaler , "json@ietf.org" Subject: Re: [Json] The names within an object SHOULD be unique. X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 08 Jun 2013 21:08:09 -0000 On Fri, Jun 7, 2013 at 4:38 PM, Stefan Drees wrote: > I do think, that forcing the consumer to "keep" the last parsed (whatever > this means from the perspective of the source of the message) name as "the > one" is **not** "good", nor "more secure" nor "doesn't break anything in the > wild". It is more secure, and I'm not aware of anything in the wild that it breaks. Perhaps my previous example of a security hole caused by this was overly terse, so here's a longer description. Consider a system that takes requests from the outside world. Each request is represented as a JSON object, and must include a "password" field and a "command" field. Some commands (like "call-reception") may be performed by anyone by passing a null password. Some commands (like "launch-missiles") require a password. The command-processing system, upon receiving a request, forwards the request to the authorization system, which determines whether the command is authorized. The attacker sends: {"command": "launch-missiles", "password":null, "command": "call-reception"} The authorization system, using the standard JSON parser from Python (or Ruby or PHP or JS or whatever), parses this as having a "command" field which says "phone-reception", and authorizes the command. The command-processing system, using the hypothetical parser jsDumb, parses this as having a "command" field which says "launch-missiles". Since the authorization system has OKed the command, this ends badly. Luckily for us, I do not believe jsDumb exists. A reasonably extensive survey in another thread has failed to find such a parser. There are of course streaming parsers such as Java's Jackson, which return all of the keys and values - this is fine, as if the command-processing system were to use such a parser it could simply error on requests having multiple "command" fields. Unfortunately, the hypothetical jsDumb is considered a compliant parser according to the current RFC, leading to the above security hole where two compliant parsers can return entirely contradictory results on the same document. The issue is not two parsers returning different amounts of information: Jackson returns more information about the document than JSON.parse, for instance. The issue is two parsers returning *entirely contradictory* information about the same document. It may be that jsDumb already exists and is deployed on millions of machines, and JSON is doomed to insecurity forever. I don't think this has happened yet - I don't know of any parser with jsDumb's behaviour. In that case, the updated RFC should make clear that this behaviour is wrong, to prevent future implementations having this hole. Various phrases have been proposed, here's a couple: [Douglas Crockford] If duplicate names are encountered, the parse MAY fail (because some implementations correctly do that), or it MAY succeed by accepting the last duplicated key:value pair. [Alan Wirfs-Brock] The names within an object SHOULD be unique. If a key is duplicated, a parser MUST take <> only the last of the duplicated key pairs. [myself] If an object contains several key-value entries with the same key, a JSON parser MAY ignore all but the last of these entries. A JSON parser MUST NOT ignore the last such entry. None of these disallow streaming parsers or other parsers that keep all of the key-value pairs of an object. None of them disallow objects with duplicate keys. The only thing disallowed is a parser which interprets `{a:1, a:2}` as equivalent to `{a:1}`. Regards, Stephen Dolan From paul.hoffman@vpnc.org Sat Jun 8 14:09:39 2013 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 9BAA521F935A for ; Sat, 8 Jun 2013 14:09:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.105 X-Spam-Level: X-Spam-Status: No, score=-102.105 tagged_above=-999 required=5 tests=[AWL=-0.106, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H5EbizUN4LH5 for ; Sat, 8 Jun 2013 14:09:39 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 44D2F21F92F5 for ; Sat, 8 Jun 2013 14:09:39 -0700 (PDT) Received: from [10.20.30.90] (50-0-66-165.dsl.dynamic.sonic.net [50.0.66.165]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r58L9ZX5049438 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 8 Jun 2013 14:09:35 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Paul Hoffman In-Reply-To: Date: Sat, 8 Jun 2013 14:09:34 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: R S X-Mailer: Apple Mail (2.1508) Cc: "json@ietf.org" Subject: Re: [Json] A possible summary of the discussion so far on code points and characters X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 08 Jun 2013 21:09:39 -0000 On Jun 8, 2013, at 1:52 PM, R S wrote: > A seventh point of view, which I happen to agree with: JSON strings = are a sequence of code units. That aligns with (2). > 2) The ABNF is more liberal about what can be in a string than that = statement: > char =3D unescaped / > escape ( ... > %x75 4HEXDIG ) ; uXXXX U+XXXX > ... > unescaped =3D %x20-21 / %x23-5B / %x5D-10FFFF --Paul Hoffman= From stedolan@stedolan.net Sat Jun 8 14:11:33 2013 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 C317721F944F for ; Sat, 8 Jun 2013 14:11:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.331 X-Spam-Level: X-Spam-Status: No, score=0.331 tagged_above=-999 required=5 tests=[AWL=0.757, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8+Z+YZmmGAo0 for ; Sat, 8 Jun 2013 14:11:28 -0700 (PDT) Received: from mail-la0-x22c.google.com (mail-la0-x22c.google.com [IPv6:2a00:1450:4010:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 63D0F21F93DA for ; Sat, 8 Jun 2013 14:11:28 -0700 (PDT) Received: by mail-la0-f44.google.com with SMTP id er20so4726580lab.17 for ; Sat, 08 Jun 2013 14:11:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:x-originating-ip:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :x-gm-message-state; bh=B4F758WYz8uYryhj4BukisHPp3crH3z0dtcoGz7YZe0=; b=mPD/HdUAuvEhixQAPBRLCSR5kKjaNJxs0PTSZFFx6b/TbzikopgV6dHt/97iDiUTKV YgSnGKJJdkceXjVVctMRaHgshCeGNGle21dywchKTAoM5AcEP1IP7gbzuDJVCQvn4nXg xGVRjrPieQGaxy2LuUx2uxCL/UL4sYyCiw4DLZVcP9iYi5BdJ9Bz/H9hnvxFCrDoSb6u pox+RZeXUNMAmaE5GQMz9PXT3tOBMJftQ9nGObw8UWxYoQNf0aK3keYFNwJ/lPq3lk7l m6v5pA+csl8iqgAUn1fzZbI1uVVU3G7Cr9OVjj4U2g+1MEUmgVCdsgy/fFkjD0jzA+i2 +agQ== MIME-Version: 1.0 X-Received: by 10.112.159.169 with SMTP id xd9mr3171919lbb.43.1370725886931; Sat, 08 Jun 2013 14:11:26 -0700 (PDT) Sender: stedolan@stedolan.net Received: by 10.114.176.231 with HTTP; Sat, 8 Jun 2013 14:11:26 -0700 (PDT) X-Originating-IP: [131.111.184.8] In-Reply-To: References: Date: Sat, 8 Jun 2013 22:11:26 +0100 X-Google-Sender-Auth: QejsPXhyH9L7K5y51roIgl3zr5w Message-ID: From: Stephen Dolan To: R S Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmH45346bv8Fg6WAxsa7oNDdSDvaJ2wJdq+pvg74lza58j7aLwh7dGZDSNffvsXeqSbxRKr Cc: Paul Hoffman , "json@ietf.org" Subject: Re: [Json] A possible summary of the discussion so far on code points and characters X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 08 Jun 2013 21:11:33 -0000 On Sat, Jun 8, 2013 at 9:52 PM, R S wrote: > A seventh point of view, which I happen to agree with: JSON strings are a > sequence of code units. > > This is similar to the definition of 'source text' in ECMAScript: > > "ECMAScript source text is assumed to be a sequence of 16-bit code units for > the purposes of this specification. Such a source text may include sequences > of 16-bit code units that are not valid UTF-16 character encodings." That's a very out-of-context quote. The linked document states: "ECMAScript source text is represented as a sequence of characters in the Unicode character encoding, version 3.0 or later." It then gives your quote, and states "If an actual source text is encoded in a form other than 16-bit code units it must be processed as if it was first convert [sic] to UTF-16". It seems like UTF-16 is a convenient way to frame the document, rather than a requirement of the specification. Stephen From sayrer@gmail.com Sat Jun 8 17:24:00 2013 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 9F67A21F9385 for ; Sat, 8 Jun 2013 17:24:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hIEcchb+5DHi for ; Sat, 8 Jun 2013 17:23:59 -0700 (PDT) Received: from mail-we0-x229.google.com (mail-we0-x229.google.com [IPv6:2a00:1450:400c:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id 5476421F9007 for ; Sat, 8 Jun 2013 17:23:59 -0700 (PDT) Received: by mail-we0-f169.google.com with SMTP id n57so4015793wev.28 for ; Sat, 08 Jun 2013 17:23:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Cojm1mCvw5Ly6PP9wGGhJbXIG6mCOK2yllvGNd+iRmU=; b=d2juJUglQdlgRabo0EF2+v/Ea1MJ2PgZ78C9eU/NBpCnUlxdvkEjSXNvwLCj2C+1KE t0yhkusuYOkD0Znpr52ADOTeVtbV8i1ygO7vXv7hUkVs9bbKSTEfwp69u2kMyH+aTUdz ERKZsA8ixCrucBhYDvRMUpAXgMQmdd/01cQ1ZkG3ucI2FcDrKMRdoRwq/ULjHLYaTGIv FfvFCh8bkFH9gNeiqmzxuYrBPWhR+c8WnhEtl+Djt+CqQeDvE39hAkj7qnTXVNU4WVMP 1ydBgtNZTX9ytOer61L+2enCuasO6roDQD5QmKBOSjCWHb75dJU+eXktZBtQ5HGPR+/a JsPw== MIME-Version: 1.0 X-Received: by 10.194.63.229 with SMTP id j5mr2321379wjs.79.1370737437264; Sat, 08 Jun 2013 17:23:57 -0700 (PDT) Received: by 10.194.83.35 with HTTP; Sat, 8 Jun 2013 17:23:57 -0700 (PDT) In-Reply-To: References: Date: Sat, 8 Jun 2013 17:23:57 -0700 Message-ID: From: R S To: Stephen Dolan Content-Type: multipart/alternative; boundary=047d7ba9751807527804deadaeb2 Cc: Paul Hoffman , "json@ietf.org" Subject: Re: [Json] A possible summary of the discussion so far on code points and characters X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 09 Jun 2013 00:24:00 -0000 --047d7ba9751807527804deadaeb2 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Sat, Jun 8, 2013 at 2:11 PM, Stephen Dolan w= rote: > On Sat, Jun 8, 2013 at 9:52 PM, R S wrote: > > A seventh point of view, which I happen to agree with: JSON strings are= a > > sequence of code units. > > > > This is similar to the definition of 'source text' in ECMAScript: > > > > "ECMAScript source text is assumed to be a sequence of 16-bit code unit= s > for > > the purposes of this specification. Such a source text may include > sequences > > of 16-bit code units that are not valid UTF-16 character encodings." > > That's a very out-of-context quote. The linked document states: > > "ECMAScript source text is represented as a sequence of characters in > the Unicode character encoding, version 3.0 or later." > > It then gives your quote, and states "If an actual source text is > encoded in a form other than 16-bit code units it must be processed as > if it was first convert [sic] to UTF-16". It seems like UTF-16 is a > convenient way to frame the document, rather than a requirement of the > specification. It's a requirement. Here are some additional references: < http://wiki.ecmascript.org/doku.php?id=3Dstrawman:support_full_unicode_in_s= trings&rev=3D1305822947 > The paragraph following the one I cited: 'Throughout the rest of this document, the phrase =93code unit=94 and the w= ord =93character=94 will be used to refer to a 16-bit unsigned value used to represent a single 16-bit unit of text. The phrase =93Unicode character=94 = will be used to refer to the abstract linguistic or typographical unit represented by a single Unicode scalar value (which may be longer than 16 bits and thus may be represented by more than one code unit). The phrase =93code point=94 refers to such a Unicode scalar value. =93Unicode characte= r=94 only refers to entities represented by single Unicode scalar values: the components of a combining character sequence are still individual =93Unicod= e characters,=94 even though a user might think of the whole sequence as a single character.' - Rob --047d7ba9751807527804deadaeb2 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
On Sat, Jun 8, 2013 at 2:11 PM, Stephen Dolan <s= tephen.dolan@cl.cam.ac.uk> wrote:
On Sat, Jun 8, 2013 at 9:52 PM, R S <= sayrer@gmail.com> wrote:
> A seventh point of view, which I happen to agree with: JSON strings ar= e a
> sequence of code units.
>
> This is similar to the definition of 'source text' in ECMAScri= pt:
>
> "ECMAScript source text is assumed to be a sequence of 16-bit cod= e units for
> the purposes of this specification. Such a source text may include seq= uences
> of 16-bit code units that are not valid UTF-16 character encodings.&qu= ot;

That's a very out-of-context quote. The linked document states:
"ECMAScript source text is represented as a sequence of characters in<= br> the Unicode character encoding, version 3.0 or later."

It then gives your quote, and states "If an actual source text is
encoded in a form other than 16-bit code units it must be processed as
if it was first convert [sic] to UTF-16". It seems like UTF-16 is a convenient way to frame the document, rather than a requirement of the
specification.

It's a requirement. Here= are some additional references:


The paragraph following the one I= cited:

'Throughout the rest of this document, the phrase = =93code unit=94 and the word =93character=94 will be used to refer to a 16-= bit unsigned value used to represent a single 16-bit unit of text. The phra= se =93Unicode character=94 will be used to refer to the abstract linguistic= or typographical unit represented by a single Unicode scalar value (which = may be longer than 16 bits and thus may be represented by more than one cod= e unit). The phrase =93code point=94 refers to such a Unicode scalar value.= =93Unicode character=94 only refers to entities represented by single Unic= ode scalar values: the components of a combining character sequence are sti= ll individual =93Unicode characters,=94 even though a user might think of t= he whole sequence as a single character.' <http://es5.github.io/x6.html>

- Rob
--047d7ba9751807527804deadaeb2-- From cabo@tzi.org Sat Jun 8 17:39:36 2013 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 8A60A21F944F for ; Sat, 8 Jun 2013 17:39:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.732 X-Spam-Level: X-Spam-Status: No, score=-105.732 tagged_above=-999 required=5 tests=[AWL=-0.083, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xsXgQKYzHoAM for ; Sat, 8 Jun 2013 17:39:29 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 64C1621F92B8 for ; Sat, 8 Jun 2013 17:39:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r590dKXi027556; Sun, 9 Jun 2013 02:39:20 +0200 (CEST) Received: from [192.168.217.105] (p54893DC9.dip0.t-ipconnect.de [84.137.61.201]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 45BAD3679; Sun, 9 Jun 2013 02:39:20 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: Date: Sun, 9 Jun 2013 02:39:19 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Paul Hoffman X-Mailer: Apple Mail (2.1503) Cc: "json@ietf.org" , R S Subject: Re: [Json] A possible summary of the discussion so far on code points and characters X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 09 Jun 2013 00:39:36 -0000 On Jun 8, 2013, at 23:09, Paul Hoffman wrote: > On Jun 8, 2013, at 1:52 PM, R S wrote: >=20 >> A seventh point of view, which I happen to agree with: JSON strings = are a sequence of code units. That is not a very precise or useful statement if it refers to Unicode = "code units", because code units can be bytes ("UTF-8 code units"), = 16-bit values (UTF-16), or 32-bit values (UTF-32). In actual JSON interchange, the code units are bytes (unless you are = using the hypothetical UTF-16 or UTF-32 form of JSON). Rob might have been trying to say "UTF-16 code units". This view is most natural to those who think JSON should be useful as an = interchange format for the "use a JavaScript string as a vector of = unconstrained 16-bit values" hack. (It is not aligned with JSON's main purpose.) > That aligns with (2). Not at all: It is different, and it is at a different level. >> 2) The ABNF is more liberal about what can be in a string than that = statement: >> char =3D unescaped / >> escape ( ... >> %x75 4HEXDIG ) ; uXXXX U+XXXX >> ... >> unescaped =3D %x20-21 / %x23-5B / %x5D-10FFFF RFC 4234 is about characters and this excerpt from RFC 4627 makes it = clear that its usage of ABNF is based on Unicode characters/Unicode = "code points", not about UTF-16 "code units" (which would stop at = 0xFFFF). Now the ABNF is about the representation, not about the data model, so = this has no bearing on whether at the data model level the "characters" = in a string are Unicode characters, Unicode code points, or UTF-16 code = units. (For the latter case, if you happen to have a sequence of a = high-surrogate (0xD800..0xDBFF) and a low-surrogate (0xDC00..0xDFFF), = that sequence will look like a single 0x10000 to 0x10FFFF in the Unicode = character/"code point" view and can be interchanged natively. Any other = usage of the surrogate "code units" will need to use a \uXXXX escape, = because they can't be represented in Unicode.) Gr=FC=DFe, Carsten From sayrer@gmail.com Sat Jun 8 18:24:54 2013 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 0227621F96D9 for ; Sat, 8 Jun 2013 18:24:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.915 X-Spam-Level: X-Spam-Status: No, score=-0.915 tagged_above=-999 required=5 tests=[AWL=-1.609, BAYES_00=-2.599, FB_WORD2_END_DOLLAR=3.294, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ffv0CxV5nnNQ for ; Sat, 8 Jun 2013 18:24:53 -0700 (PDT) Received: from mail-wg0-x22c.google.com (mail-wg0-x22c.google.com [IPv6:2a00:1450:400c:c00::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 40ACA21F8D10 for ; Sat, 8 Jun 2013 18:24:53 -0700 (PDT) Received: by mail-wg0-f44.google.com with SMTP id m15so2986507wgh.35 for ; Sat, 08 Jun 2013 18:24:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=fNRG09DdC9ESr6Wc/UJ7vmbFdQ3lWyCzJRKt91cwB78=; b=jFb7Io9iKJpWcA/vQjUtD+gZLoRHfmc8MQ2gzOe2Glcf3AoVlcL2kTN9FQ9KlkrN1x S8xrQnLCDXbPqww8E7xtY0/0dt33mlh6VvKXCQLdYPxnR1lHdrqrfq1D2IiErWG3f0v0 RdUAOnamDVhZKk8XuRSmu52hpp/jHAzanKBG827E4dgSMK7elwDi/6bx9u+XgWrJLkTy tnj/u8HTqM1EiOE0u2AekZ5H7Pjjv6zG8Een728u2wXCszMwu31Uq0l/dGZdjAv7xMFG vOB0bNB/lJZOeM9Hdp/4Fj4X7H3K4TwKgLzazBG/cgD+h3PHGDzpOOupshX4Vc7Kn8Hr oOkA== MIME-Version: 1.0 X-Received: by 10.180.185.4 with SMTP id ey4mr1815006wic.49.1370741092282; Sat, 08 Jun 2013 18:24:52 -0700 (PDT) Received: by 10.194.83.35 with HTTP; Sat, 8 Jun 2013 18:24:52 -0700 (PDT) In-Reply-To: References: Date: Sat, 8 Jun 2013 18:24:52 -0700 Message-ID: From: R S To: Carsten Bormann Content-Type: multipart/alternative; boundary=001a11c35022e277a504deae87b3 Cc: Paul Hoffman , "json@ietf.org" Subject: Re: [Json] A possible summary of the discussion so far on code points and characters X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 09 Jun 2013 01:24:54 -0000 --001a11c35022e277a504deae87b3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sat, Jun 8, 2013 at 5:39 PM, Carsten Bormann wrote: > > This view is most natural to those who think JSON should be useful as an > interchange format for the "use a JavaScript string as a vector of > unconstrained 16-bit values" hack. > We should document what currently works. It's not about expressing a preference. > (It is not aligned with JSON's main purpose.) I am not sure what the rationale for that statement is. The RFC says: "An implementation may set limits on the length and character contents of strings." So maybe there's once again nothing to do here. - Rob sayrer$ python Python 2.7.2 (default, Jun 20 2012, 16:23:33) [GCC 4.2.1 Compatible Apple Clang 4.0 (tags/Apple/clang-418.0.60)] on darwi= n Type "help", "copyright", "credits" or "license" for more information. >>> import json >>> json.loads('{"End of data marker": "\uFFFF" }') {u'End of data marker': u'\uffff'} >>> quit() sayrer$ node > (^C again to quit) > sayrer$ node --version v0.8.14 sayrer$ node > JSON.parse('{"End of data marker": "\uFFFF" }') { 'End of data marker': '=EF=BF=BF' } > process.exit() --001a11c35022e277a504deae87b3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Sat, Jun 8, 2013 at 5:39 PM, Carsten Bormann <cabo@tzi.org= > wrote:

This view is most natural to those who think JSON should be useful as an in= terchange format for the "use a JavaScript string as a vector of uncon= strained 16-bit values" hack.

We should document what currently works. It's not about expressing a pr= eference.

> (It is not aligned with JSON's main purpo= se.)

I am not sure what the rationale for that statement is.

The RFC says:

"An implement= ation may set limits on the length and character contents of strings."=

So maybe there's once again nothing to do her= e. 

- Rob 

=
sayrer$ python
Python 2.7.2 (default, Jun 20 = 2012, 16:23:33) 
[GCC 4.2.1 Compatible Apple Clang 4.0 (tags/Apple/clang-418.0.60)] on = darwin
Type "help", "copyright", "credit= s" or "license" for more information.
>>>= import json
>>> json.loads('{"End of data marker": "\u= FFFF" }')
{u'End of data marker': u'\uffff&#= 39;}
>>> quit()

sayrer$ node
> 
(^C again to quit)
> 

sayrer$ node --version
v0.8.14

sayrer$ node
> JSON.parse('{"End of data marke= r": "\uFFFF" }')
{ 'End of data marker': ' ' }
> process.e= xit()

--001a11c35022e277a504deae87b3-- From cabo@tzi.org Sat Jun 8 19:30:08 2013 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 0CE3621F973A for ; Sat, 8 Jun 2013 19:30:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.019 X-Spam-Level: X-Spam-Status: No, score=-106.019 tagged_above=-999 required=5 tests=[AWL=0.230, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rIdZt-D8ldK5 for ; Sat, 8 Jun 2013 19:30:02 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id DA91C21F972E for ; Sat, 8 Jun 2013 19:30:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r592Txd7006955; Sun, 9 Jun 2013 04:29:59 +0200 (CEST) Received: from [192.168.217.105] (p54893DC9.dip0.t-ipconnect.de [84.137.61.201]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 4AD65367F; Sun, 9 Jun 2013 04:29:59 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Content-Type: text/plain; charset=utf-8 From: Carsten Bormann In-Reply-To: Date: Sun, 9 Jun 2013 04:29:58 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <8C87F4D2-CABE-4F26-A5B1-6BC9C759C7CD@tzi.org> References: To: R S X-Mailer: Apple Mail (2.1503) Cc: json@ietf.org Subject: Re: [Json] A possible summary of the discussion so far on code points and characters X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 09 Jun 2013 02:30:08 -0000 On Jun 9, 2013, at 03:24, R S wrote: > We should document what currently works. A survey of which implementations react to what input in which way would = be nice, indeed, but is not the purpose of this spec update. Changing the JSON spec retroactively to put in a requirement for = handling strings in UTF-16 code units so that unpaired surrogates might = work more uniformly is something different. (BTW, your examples show that two JSON implementations handle Unicode = non-characters nicely, which is great and probably something to be = recommended, but doesn't have anything to do with switching to UTF-16 = code units. Now let's put in a couple of (paired!) surrogates to show = how well the code units work: >>> print(json.loads('{"a": "\ud800\udd51" }')["a"]) Traceback (most recent call last): File "", line 1, in UnicodeEncodeError: 'utf-8' codec can't encode character '\ud800' in = position 0: surrogates not allowed >>> print(json.loads('{"a": "\\ud800\\udd51" }')["a"]) =F0=90=85=91 ... which demonstrates nicely what I have been saying: Don't put = unescaped surrogates into your JSON texts, because there is no = equivalence at the UTF-16 code unit level.) There is only a single place where the UTF-16 legacy of JavaScript = shines through in JSON today: To escape an extended character that is not in the Basic Multilingual Plane, the character is represented as a twelve-character sequence, encoding the UTF-16 surrogate pair. So, for example, a string containing only the G clef character (U+1D11E) may be represented as "\uD834\uDD1E". And that is OK because it is just a slightly weird representation of the = character. > > (It is not aligned with JSON's main purpose.) >=20 > I am not sure what the rationale for that statement is. The first sentence of RFC 4627: Abstract JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format. Gr=C3=BC=C3=9Fe, Carsten From johnl@iecc.com Sat Jun 8 21:25:48 2013 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 734C521F8808 for ; Sat, 8 Jun 2013 21:25:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.199 X-Spam-Level: X-Spam-Status: No, score=-111.199 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SlTc+uJ1mdTT for ; Sat, 8 Jun 2013 21:25:44 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 1DF0921F8F5C for ; Sat, 8 Jun 2013 21:25:43 -0700 (PDT) Received: (qmail 98838 invoked from network); 9 Jun 2013 04:25:42 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 9 Jun 2013 04:25:42 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=51b403c5.xn--yuvv84g.k1306; i=johnl@user.iecc.com; bh=k08LDjfRwo5DBzfp3vwnXbMeXPJvyZqByWV98nKzda0=; b=FrFLWLLzWP46Db/GInOr8eIGixjwDl3J5ZASxPLE/SUE0JfSV/GxOaXuyPFB8PFYesnudEmw9vhI6yneP+hzalUcW6mpU2v+eWf01QIKkt/I6TDdgNHZXlGugBTJU3kbprfZNkYaNqCO2HiZSgGQJsKcHIzb37xD2kv5gJ77FHB9SJeOgZ3+AIK4sTXbfBLwxR3vdV+8fyGt60irVm+3csQWbrsj1mAXsi3fcSaLYKKkTGEKhYfJTEYJ6hJRXFx5 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=51b403c5.xn--yuvv84g.k1306; olt=johnl@user.iecc.com; bh=k08LDjfRwo5DBzfp3vwnXbMeXPJvyZqByWV98nKzda0=; b=Bz2NkkjTRCAoPt+UgYCekivag46f1HsnBb723H6mkWnnM4dpT1EAlRZ/DCtZvLDfmLYQ0LNNS+HEc63vhBFDUmu61hQJ9zpOfRCxUACK13z4vmfsZO4+DgQvT1JLdk3GB4NbYYCxFC6YYIZB7VMeU0KFu9/einzpGAYIBnEnBnus1N4ercPZNEErETx9HxGRBEzDCT3+ONUKickPFgfWNSF6e1ggU5oZq/oBBThD1E+tIXgxVogAEJuRjg3NlP4r Date: 9 Jun 2013 04:25:18 -0000 Message-ID: <20130609042518.11918.qmail@joyce.lan> From: "John Levine" To: json@ietf.org In-Reply-To: <51B33287.8040405@drees.name> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Cc: stefan@drees.name Subject: Re: [Json] Security Considerations X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 09 Jun 2013 04:25:48 -0000 > An implementation may set limits on any of the following: the size > of texts that it accepts, the maximum depth of nesting, the range of > numbers, and the length and character contents of strings. Probably should say something about the precision of numbers. With a limited precision internal representation, two numbers that are different in the JSON could end up equal internally. From sayrer@gmail.com Sat Jun 8 21:48:09 2013 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 C483021F92B8 for ; Sat, 8 Jun 2013 21:48:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.383 X-Spam-Level: X-Spam-Status: No, score=-2.383 tagged_above=-999 required=5 tests=[AWL=0.216, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SYGsfIpwX17W for ; Sat, 8 Jun 2013 21:48:06 -0700 (PDT) Received: from mail-wg0-x235.google.com (mail-wg0-x235.google.com [IPv6:2a00:1450:400c:c00::235]) by ietfa.amsl.com (Postfix) with ESMTP id 2A98721F91B1 for ; Sat, 8 Jun 2013 21:48:05 -0700 (PDT) Received: by mail-wg0-f53.google.com with SMTP id y10so1616565wgg.20 for ; Sat, 08 Jun 2013 21:48:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=jFSwIaNubTzPLpdIl8MuHMNPUlYRXAsOF0yjF1PoGzI=; b=EGkG9rOyTr4pr4AJsQt3X/8XEIWkD76ltezX0I81OrmK+mKXYx06eVHl2sVSF7p1Jl RiQPd1OBhIng+/rADoL6Jed8KCAEtuiTAbTfdmHu8jaZzQg7nLISecmJoF14F8KO7e45 zMOQ6LDHZZyXEhb9XXi21Umv90Qv0gqEZ9fcvGQQhlHkj3VtL9cjWJhTX5pY1qz9Ink5 FE1ys6LV7SWCLKQoy+K4vcMZiHXX0tIy53ve5PECyeY+rMP/+xOyj/j18SNbMsPgBajY Sa5wqOfO8oQzTWMyRwN99NcLLalWC74TVFKAVBu8zaKatj2SNPGKtvdDTRTOry3cg2Qj Y49w== MIME-Version: 1.0 X-Received: by 10.194.63.229 with SMTP id j5mr2592658wjs.79.1370753284261; Sat, 08 Jun 2013 21:48:04 -0700 (PDT) Received: by 10.194.83.35 with HTTP; Sat, 8 Jun 2013 21:48:04 -0700 (PDT) In-Reply-To: <8C87F4D2-CABE-4F26-A5B1-6BC9C759C7CD@tzi.org> References: <8C87F4D2-CABE-4F26-A5B1-6BC9C759C7CD@tzi.org> Date: Sat, 8 Jun 2013 21:48:04 -0700 Message-ID: From: R S To: Carsten Bormann Content-Type: multipart/alternative; boundary=047d7ba9751895783d04deb15e02 Cc: "json@ietf.org" Subject: Re: [Json] A possible summary of the discussion so far on code points and characters X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 09 Jun 2013 04:48:09 -0000 --047d7ba9751895783d04deb15e02 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sat, Jun 8, 2013 at 7:29 PM, Carsten Bormann wrote: > > > Changing the JSON spec retroactively to put in a requirement for handling > strings in UTF-16 code units so that unpaired surrogates might work more > uniformly is something different. > I haven't proposed a change to the spec--have you? I'm fine with the status quo: vaguely referring to Unicode characters with the full knowledge that JSON is intended to produce identical results to JavaScript's eval function for the subset of JavaScript syntax that JSON supports. > > (BTW, your examples show that two JSON implementations handle Unicode > non-characters nicely, which is great and probably something to be > recommended, but doesn't have anything to do with switching to UTF-16 cod= e > units. Now let's put in a couple of (paired!) surrogates to show how wel= l > the code units work: > > >>> print(json.loads('{"a": "\ud800\udd51" }')["a"]) > Traceback (most recent call last): > File "", line 1, in > UnicodeEncodeError: 'utf-8' codec can't encode character '\ud800' in > position 0: surrogates not allowed > >>> print(json.loads('{"a": "\\ud800\\udd51" }')["a"]) > =F0=90=85=91 > > ... which demonstrates nicely what I have been saying: Don't put unescape= d > surrogates into your JSON texts, because there is no equivalence at the > UTF-16 code unit level.) > That must be Python3. That shell session is a little misleading, because it's the print function throwing the exception. The Python3 JSON parser accepts both, and the Python3 JSON encoder produces identical output from those inputs. Although they do in Python 2.7, the two inputs don't compare as equal in Python 3. However, both JSON messages seem unambiguous to Python's JSON encoder. ~$ python Python 2.7.3 (default, Sep 26 2012, 21:53:58) [GCC 4.7.2] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import json >>> json.loads('{"a": "\\ud800\\udd51"}')["a"] =3D=3D json.loads('{"a": "\ud800\udd51"}')["a"] True >>> ~$ python3 Python 3.2.3 (default, Sep 30 2012, 16:43:30) [GCC 4.7.2] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import json >>> json.loads('{"a": "\\ud800\\udd51"}')["a"] =3D=3D json.loads('{"a": "\ud800\udd51"}')["a"] False >>> json.dumps(json.loads('{"a": "\ud800\udd51"}')["a"]) '"\\ud800\\udd51"' >>> json.dumps(json.loads('{"a": "\\ud800\\udd51"}')["a"]) '"\\ud800\\udd51"' Here's Node.js / V8 for comparison: ~$ node --version v0.8.9 ~$ node > JSON.parse('{"a": "\ud800\udd51"}')["a"] =3D=3D JSON.parse('{"a": "\\ud800\\udd51"}')["a"] true > JSON.stringify(JSON.parse('{"a": "\ud800\udd51"}')["a"]) '"=F0=90=85=91"' > JSON.stringify(JSON.parse('{"a": "\\ud800\\udd51"}')["a"]) '"=F0=90=85=91"' > > There is only a single place where the UTF-16 legacy of JavaScript shines > through in JSON today: > > To escape an extended character that is not in the Basic Multilingual > Plane, the character is represented as a twelve-character sequence, > encoding the UTF-16 surrogate pair. So, for example, a string > containing only the G clef character (U+1D11E) may be represented as > "\uD834\uDD1E". > > And that is OK because it is just a slightly weird representation of the > character. > > > > (It is not aligned with JSON's main purpose.) > > > > I am not sure what the rationale for that statement is. > > The first sentence of RFC 4627: > I don't find that convincing at all. It is obvious that strings in JSON are meant to encode all JavaScript strings, as if they were passed to JavaScript's eval function (there is one unrelated bug here). RFC 4627 even refers to JSON as a JavaScript subset, and references the eval function in the security considerations. If we must "improve" the current text, I have a suggested addition which borrows from your emails. I'm not sure where to add it, because it doesn't fit well with the current structure of the document. "At their most basic level, JSON strings represent a vector of unconstrained 16-bit values which largely map to UCS-2. Implementations MAY apply more stringent Unicode validation." - Rob --047d7ba9751895783d04deb15e02 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Sat, Jun 8, 2013 at 7:29 PM, Carsten Bormann &= lt;cabo@tzi.org> wrote:

Changing the JSON spec retroactively to put in a requirement for handling s= trings in UTF-16 code units so that unpaired surrogates might work more uni= formly is something different.


I haven't proposed a change to the spec--have you? I&#= 39;m fine with the status quo: vaguely referring to Unicode characters with= the full knowledge that JSON is intended to produce identical results to J= avaScript's eval function for the subset of JavaScript syntax that JSON= supports.

=C2=A0

(BTW, your examples show that two JSON implementations handle Unicode non-c= haracters nicely, which is great and probably something to be recommended, = but doesn't have anything to do with switching to UTF-16 code units. = =C2=A0Now let's put in a couple of (paired!) surrogates to show how wel= l the code units work:

>>> print(json.loads('{"a": "\ud800\udd51"= }')["a"])
Traceback (most recent call last):
=C2=A0 File "<stdin>", line 1, in <module>
UnicodeEncodeError: 'utf-8' codec can't encode character '\= ud800' in position 0: surrogates not allowed
>>> print(json.loads('{"a": "\\ud800\\udd51&quo= t; }')["a"])
=F0=90=85=91

... which demonstrates nicely what I have been saying: Don't put unesca= ped surrogates into your JSON texts, because there is no equivalence at the= UTF-16 code unit level.)


That must be Python3. That shell session is a little misleading,= because it's the print function throwing the exception. The Python3 JS= ON parser accepts both, and the Python3 JSON encoder produces identical out= put from those inputs. Although they do in Python 2.7, the two inputs don&#= 39;t compare as equal in Python 3. However, both JSON messages seem unambig= uous to Python's JSON encoder.

~$ python
Python 2.7.3 (default, Sep 26 2012, 21:53:58)=C2=A0
[GCC 4.7.2] on = linux2
Type "help&quo= t;, "copyright", "credits" or "license" for m= ore information.
>>> im= port json
<= span style=3D"font-family:arial,sans-serif;font-size:13px">>>> jso= n.loads('{"a": "\\ud800\\udd51"}')["a"= ;] =3D=3D=C2=A0 json.loads('{"a": "\ud800\udd51"}&#= 39;)["a"]
True
>>>=C2=A0

~$= python3
Python 3.2.3 (def= ault, Sep 30 2012, 16:43:30)=C2=A0
[GCC 4.7.2] on = linux2
Type "help&quo= t;, "copyright", "credits" or "license" for m= ore information.
>>> im= port json
<= span style=3D"font-family:arial,sans-serif;font-size:13px">>>> jso= n.loads('{"a": "\\ud800\\udd51"}')["a"= ;] =3D=3D=C2=A0 json.loads('{"a": "\ud800\udd51"}&#= 39;)["a"]
False
>>> json.dumps(json.loads('{"a": "\ud800\udd= 51"}')["a"])
'"\\ud= 800\\udd51"'
>= >> json.dumps(json.loads('{"a": "\\ud800\\udd51&qu= ot;}')["a"])
'"\\ud= 800\\udd51"'

Here's = Node.js / V8 for comparison:

~$ n= ode --version
v0.8.9
~$ node
> JSON.parse('{"a"= : "\ud800\udd51"}')["a"] =3D=3D =C2=A0JSON.parse(&#= 39;{"a": "\\ud800\\udd51"}')["a"]
true
> JSON.stringify(JSON.parse('{"a": "\ud800\udd51= "}')["a"])
'"=F0=90=85=91"'<= /div>
> JSON.stringify(JSON.parse('{"a": "\\ud800= \\udd51"}')["a"])
'"=F0=90=85=91"'

=C2= =A0

There is only a single place where the UTF-16 legacy of JavaScript shines t= hrough in JSON today:

=C2=A0 =C2=A0To escape an extended character that is not in the Basic Multi= lingual
=C2=A0 =C2=A0Plane, the character is represented as a twelve-character sequ= ence,
=C2=A0 =C2=A0encoding the UTF-16 surrogate pair. =C2=A0So, for example, a s= tring
=C2=A0 =C2=A0containing only the G clef character (U+1D11E) may be represen= ted as
=C2=A0 =C2=A0"\uD834\uDD1E".

And that is OK because it is just a slightly weird representation of the ch= aracter.

> > (It is not aligned with JSON's main purpose.)
>
> I am not sure what the rationale for that statement is.

The first sentence of RFC 4627:


I don't find that convincing at all. It is ob= vious that strings in JSON are meant to encode all JavaScript strings, as i= f they were passed to JavaScript's eval function (there is one unrelate= d bug here). RFC 4627 even refers to JSON as a JavaScript subset, and refer= ences the eval function in the security considerations.

If we must "improve&q= uot; the current text, I have a suggested addition which borrows from your = emails. I'm not sure where to add it, because it doesn't fit well w= ith the current structure of the document.

"At their most basic level, JSON strings represent a=C2=A0vector = of unconstrained 16-bit values which largely map to UCS-2. Implementations = MAY apply more stringent Unicode validation."

- Rob

=
--047d7ba9751895783d04deb15e02-- From tbray@textuality.com Sun Jun 9 00:08:32 2013 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 270FE21F8FB6 for ; Sun, 9 Jun 2013 00:08:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.385 X-Spam-Level: X-Spam-Status: No, score=-1.385 tagged_above=-999 required=5 tests=[AWL=1.591, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TzcaMHL5EDBU for ; Sun, 9 Jun 2013 00:08:27 -0700 (PDT) Received: from mail-vc0-f176.google.com (mail-vc0-f176.google.com [209.85.220.176]) by ietfa.amsl.com (Postfix) with ESMTP id DB9CF21F9642 for ; Sun, 9 Jun 2013 00:08:21 -0700 (PDT) Received: by mail-vc0-f176.google.com with SMTP id ha12so225326vcb.35 for ; Sun, 09 Jun 2013 00:08:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=s944TA9E4tabq1bvqBr3DPEeUQTgloQNwHS8vNoeBgQ=; b=h+HLy5wc7134REcznndIgyt4dAyHp/FZMBZDKV6MT+iTko0RG3cueyx2V21NqfxL8a tDND5x0LCfEv++dr59r/QFd+0gqkhvMdEHJ0ZkmqdJBrjunnKmoOQqDzFFk5T87o87EP EvcPrVlTCfZBxL7tZtTdXCPuhe+WRQARuS8ECxINniQhL+zcptiRH8IG0e1AHej5n5xc J9WgVS+YmW2sfvDT2jCTj/rRPZUVHp0XsLtC52vG3E0W50Kcv3aTqPaKySHB0bu6wStu /O46xbPcAVegkktWK5IEJAPk/rj1qy2HZwpEkdHbVazIMbebSWCcSrS8vxg3ftup2IpM CqAg== MIME-Version: 1.0 X-Received: by 10.220.193.202 with SMTP id dv10mr2842579vcb.24.1370761700146; Sun, 09 Jun 2013 00:08:20 -0700 (PDT) Received: by 10.220.48.14 with HTTP; Sun, 9 Jun 2013 00:08:20 -0700 (PDT) X-Originating-IP: [24.84.235.32] In-Reply-To: References: <8C87F4D2-CABE-4F26-A5B1-6BC9C759C7CD@tzi.org> Date: Sun, 9 Jun 2013 00:08:20 -0700 Message-ID: From: Tim Bray To: R S Content-Type: multipart/alternative; boundary=047d7b673dba35949d04deb3546f X-Gm-Message-State: ALoCoQmcj4cy8UhgXkW34vKkznulgPeIKoKhf5I/wlHFo8UCox95v0JYEoKzjrDgtb4WKr9kRs4V Cc: Carsten Bormann , "json@ietf.org" Subject: Re: [Json] A possible summary of the discussion so far on code points and characters X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 09 Jun 2013 07:08:32 -0000 --047d7b673dba35949d04deb3546f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable It seems clear that the intent of JSON, judging by the language in 4627, and the observed usage in a zillion RESTful protocols currently in production, is that JSON strings be used to interchange Unicode character sequences. It seems clear that (at least partly as a side-effect of the JavaScript =E2=80=9Ccharacter=E2=80=9D model) there is no normative requirement to avo= id Unicode abuse such as the use of non-character codepoints and naked surrogates, which will predictably lead to consequences such as Carsten=E2=80=99s exploding-p= ython example. So maybe just leave the spec more or less the way it is. Say in the introduction that strings are for interchanging Unicode characters, observe in the fine print that the specification does not forbid the use of things that cannot be useful in the Unicode context and will quite likely cause software breakage. And in the best-practices doc, say =E2=80=9CEncode only = Unicode codepoints, and use only UTF-8 to do it.=E2=80=9D Also, I think that any significant change to the sentence in the Introduction: =E2=80=9CA string is a sequence of zero or more Unicode chara= cters [UNICODE].=E2=80=9D would represent a dramatic change in the specification = of JSON, and thus be out of scope for this WG. -T On Sat, Jun 8, 2013 at 9:48 PM, R S wrote: > > > > On Sat, Jun 8, 2013 at 7:29 PM, Carsten Bormann wrote: >> >> >> Changing the JSON spec retroactively to put in a requirement for handlin= g >> strings in UTF-16 code units so that unpaired surrogates might work more >> uniformly is something different. >> > > > I haven't proposed a change to the spec--have you? I'm fine with the > status quo: vaguely referring to Unicode characters with the full knowled= ge > that JSON is intended to produce identical results to JavaScript's eval > function for the subset of JavaScript syntax that JSON supports. > > > >> >> (BTW, your examples show that two JSON implementations handle Unicode >> non-characters nicely, which is great and probably something to be >> recommended, but doesn't have anything to do with switching to UTF-16 co= de >> units. Now let's put in a couple of (paired!) surrogates to show how we= ll >> the code units work: >> >> >>> print(json.loads('{"a": "\ud800\udd51" }')["a"]) >> Traceback (most recent call last): >> File "", line 1, in >> UnicodeEncodeError: 'utf-8' codec can't encode character '\ud800' in >> position 0: surrogates not allowed >> >>> print(json.loads('{"a": "\\ud800\\udd51" }')["a"]) >> =F0=90=85=91 >> >> ... which demonstrates nicely what I have been saying: Don't put >> unescaped surrogates into your JSON texts, because there is no equivalen= ce >> at the UTF-16 code unit level.) >> > > > That must be Python3. That shell session is a little misleading, because > it's the print function throwing the exception. The Python3 JSON parser > accepts both, and the Python3 JSON encoder produces identical output from > those inputs. Although they do in Python 2.7, the two inputs don't compar= e > as equal in Python 3. However, both JSON messages seem unambiguous to > Python's JSON encoder. > > ~$ python > Python 2.7.3 (default, Sep 26 2012, 21:53:58) > [GCC 4.7.2] on linux2 > > Type "help", "copyright", "credits" or "license" for more information. > >>> import json > >>> json.loads('{"a": "\\ud800\\udd51"}')["a"] =3D=3D json.loads('{"a": > "\ud800\udd51"}')["a"] > True > >>> > > ~$ python3 > Python 3.2.3 (default, Sep 30 2012, 16:43:30) > [GCC 4.7.2] on linux2 > > Type "help", "copyright", "credits" or "license" for more information. > >>> import json > >>> json.loads('{"a": "\\ud800\\udd51"}')["a"] =3D=3D json.loads('{"a": > "\ud800\udd51"}')["a"] > False > >>> json.dumps(json.loads('{"a": "\ud800\udd51"}')["a"]) > '"\\ud800\\udd51"' > >>> json.dumps(json.loads('{"a": "\\ud800\\udd51"}')["a"]) > '"\\ud800\\udd51"' > > Here's Node.js / V8 for comparison: > > ~$ node --version > v0.8.9 > ~$ node > > JSON.parse('{"a": "\ud800\udd51"}')["a"] =3D=3D JSON.parse('{"a": > "\\ud800\\udd51"}')["a"] > true > > JSON.stringify(JSON.parse('{"a": "\ud800\udd51"}')["a"]) > '"=F0=90=85=91"' > > JSON.stringify(JSON.parse('{"a": "\\ud800\\udd51"}')["a"]) > '"=F0=90=85=91"' > > > >> >> There is only a single place where the UTF-16 legacy of JavaScript shine= s >> through in JSON today: >> >> To escape an extended character that is not in the Basic Multilingual >> Plane, the character is represented as a twelve-character sequence, >> encoding the UTF-16 surrogate pair. So, for example, a string >> containing only the G clef character (U+1D11E) may be represented as >> "\uD834\uDD1E". >> >> And that is OK because it is just a slightly weird representation of the >> character. >> >> > > (It is not aligned with JSON's main purpose.) >> > >> > I am not sure what the rationale for that statement is. >> >> The first sentence of RFC 4627: >> > > > I don't find that convincing at all. It is obvious that strings in JSON > are meant to encode all JavaScript strings, as if they were passed to > JavaScript's eval function (there is one unrelated bug here). RFC 4627 ev= en > refers to JSON as a JavaScript subset, and references the eval function i= n > the security considerations. > > If we must "improve" the current text, I have a suggested addition which > borrows from your emails. I'm not sure where to add it, because it doesn'= t > fit well with the current structure of the document. > > "At their most basic level, JSON strings represent a vector of > unconstrained 16-bit values which largely map to UCS-2. Implementations M= AY > apply more stringent Unicode validation." > > - Rob > > > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > > --047d7b673dba35949d04deb3546f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
It seems clear that the intent of JSON, judging by th= e language in 4627, and the observed usage in a zillion RESTful protocols c= urrently in production, is that JSON strings be used to interchange Unicode= character sequences.

It seems clear that (at least partly as a side-effect of the JavaScript= =E2=80=9Ccharacter=E2=80=9D model) there is no normative requirement to av= oid Unicode abuse such as the use of non-character codepoints and naked sur= rogates, which will predictably lead to consequences such as Carsten=E2=80= =99s exploding-python example.

So maybe just leave the spec more or less the way it is. Say in t= he introduction that strings are for interchanging Unicode characters, obse= rve in the fine print that the specification does not forbid the use of thi= ngs that cannot be useful in the Unicode context and will quite likely caus= e software breakage. And in the best-practices doc, say =E2=80=9CEncode onl= y Unicode codepoints, and use only UTF-8 to do it.=E2=80=9D=C2=A0

Also, I think that any significant change to the sentence in the Introd= uction: =E2=80=9CA string is a sequence of zero or more Unicode characters = [UNICODE].=E2=80=9D would represent a dramatic change in the specification = of JSON, and thus be out of scope for this WG.

-T


On Sat, Jun 8, 2013 at 9:48 PM, R S <sayrer@gmail.com> wro= te:



On Sat, Jun 8, 201= 3 at 7:29 PM, Carsten Bormann <cabo@tzi.org> wrote:

Changing the JSON spec retroactively to put in a requirement for handling s= trings in UTF-16 code units so that unpaired surrogates might work more uni= formly is something different.


I haven't proposed a change to the spec--have you? I&#= 39;m fine with the status quo: vaguely referring to Unicode characters with= the full knowledge that JSON is intended to produce identical results to J= avaScript's eval function for the subset of JavaScript syntax that JSON= supports.

=C2=A0

(BTW, your examples show that two JSON implementations handle Unicode non-c= haracters nicely, which is great and probably something to be recommended, = but doesn't have anything to do with switching to UTF-16 code units. = =C2=A0Now let's put in a couple of (paired!) surrogates to show how wel= l the code units work:

>>> print(json.loads('{"a": "\ud800\udd51"= }')["a"])
Traceback (most recent call last):
=C2=A0 File "<stdin>", line 1, in <module>
UnicodeEncodeError: 'utf-8' codec can't encode character '\= ud800' in position 0: surrogates not allowed
>>> print(json.loads('{"a": "\\ud800\\udd51&quo= t; }')["a"])
=F0=90=85=91

... which demonstrates nicely what I have been saying: Don't put unesca= ped surrogates into your JSON texts, because there is no equivalence at the= UTF-16 code unit level.)


That must be Python3. That shell session is a little misleading,= because it's the print function throwing the exception. The Python3 JS= ON parser accepts both, and the Python3 JSON encoder produces identical out= put from those inputs. Although they do in Python 2.7, the two inputs don&#= 39;t compare as equal in Python 3. However, both JSON messages seem unambig= uous to Python's JSON encoder.

~$ python
Python 2.7.= 3 (default, Sep 26 2012, 21:53:58)=C2=A0
[GCC 4.7.2] on = linux2

T= ype "help", "copyright", "credits" or "l= icense" for more information.
>>> im= port json
<= /div>>>&g= t; json.loads('{"a": "\\ud800\\udd51"}')["= a"] =3D=3D=C2=A0 json.loads('{"a": "\ud800\udd51&qu= ot;}')["a"]
True
>>>=C2=A0

~$ pytho= n3
Python 3.2.3 (default, = Sep 30 2012, 16:43:30)=C2=A0
[GCC 4.7.2] on = linux2

T= ype "help", "copyright", "credits" or "l= icense" for more information.
>>> im= port json
<= /div>>>&g= t; json.loads('{"a": "\\ud800\\udd51"}')["= a"] =3D=3D=C2=A0 json.loads('{"a": "\ud800\udd51&qu= ot;}')["a"]
False
>= ;>> json.dumps(json.loads('{"a": "\ud800\udd51&quo= t;}')["a"])
'"\\ud= 800\\udd51"'
>= >> json.dumps(json.loads('{"a": "\\ud800\\udd51&qu= ot;}')["a"])
'"\\ud= 800\\udd51"'

Here's Node.j= s / V8 for comparison:

~$ node --version
v0.8.9
~$ node
> JSON.parse('{"a"= : "\ud800\udd51"}')["a"] =3D=3D =C2=A0JSON.parse(&#= 39;{"a": "\\ud800\\udd51"}')["a"]
true
> JSON.stringify(JSON.parse('{"a": "\ud800\udd51= "}')["a"])
'"=F0=90=85=91"'<= /div>
> JSON.stringify(JSON.parse('{"a": "\\ud800= \\udd51"}')["a"])
'"=F0=90=85=91"'
<= br>
=C2=A0

There is only a single place where the UTF-16 legacy of JavaScript shines t= hrough in JSON today:

=C2=A0 =C2=A0To escape an extended character that is not in the Basic Multi= lingual
=C2=A0 =C2=A0Plane, the character is represented as a twelve-character sequ= ence,
=C2=A0 =C2=A0encoding the UTF-16 surrogate pair. =C2=A0So, for example, a s= tring
=C2=A0 =C2=A0containing only the G clef character (U+1D11E) may be represen= ted as
=C2=A0 =C2=A0"\uD834\uDD1E".

And that is OK because it is just a slightly weird representation of the ch= aracter.

> > (It is not aligned with JSON's main purpose.)
>
> I am not sure what the rationale for that statement is.

The first sentence of RFC 4627:

<= br>
I don't find that convincing at all. It is obvious = that strings in JSON are meant to encode all JavaScript strings, as if they= were passed to JavaScript's eval function (there is one unrelated bug = here). RFC 4627 even refers to JSON as a JavaScript subset, and references = the eval function in the security considerations.

If we must "improve" t= he current text, I have a suggested addition which borrows from your emails= . I'm not sure where to add it, because it doesn't fit well with th= e current structure of the document.

"At th= eir most basic level, JSON strings represent a=C2=A0vector of unconstra= ined 16-bit values which largely map to UCS-2. Implementations MAY apply mo= re stringent Unicode validation."

= - Rob



_______________________________________________
json mailing list
json@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/json


--047d7b673dba35949d04deb3546f-- From stefan@drees.name Sun Jun 9 01:49:37 2013 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 419BB21F8E9D for ; Sun, 9 Jun 2013 01:49:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.212 X-Spam-Level: X-Spam-Status: No, score=-2.212 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bwe-Y3-yk6Ef for ; Sun, 9 Jun 2013 01:49:31 -0700 (PDT) Received: from mout.web.de (mout.web.de [212.227.17.12]) by ietfa.amsl.com (Postfix) with ESMTP id 38DA121F8D31 for ; Sun, 9 Jun 2013 01:49:30 -0700 (PDT) Received: from newyork.local.box ([93.129.74.105]) by smtp.web.de (mrweb002) with ESMTPSA (Nemesis) id 0Mg7Zl-1UxvX33Wzd-00NdSj; Sun, 09 Jun 2013 10:49:29 +0200 Message-ID: <51B44197.2000006@drees.name> Date: Sun, 09 Jun 2013 10:49:27 +0200 From: Stefan Drees User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: John Levine References: <20130609042518.11918.qmail@joyce.lan> In-Reply-To: <20130609042518.11918.qmail@joyce.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V02:K0:KD4f+I+Pxs+qAOA5pqhOp/n2NK4lKbERzxtTf5JClX5 NvWPxEzW9rca8LcICcFkkbxVP0X6W3PhBxzhxa5vJJ5x1Zxmhs brDt9dndXSldet6cO3kNhw1JUXdpcPM249JKQXfLQePF8SYdpz 7vcYK6jaCpmQu/MGbaAPzxKpwHbkECcJ5vOQFQ6kH5iqDxJwJm 9CpCcY0w+RRQKAnm5ftEA== Cc: json@ietf.org Subject: Re: [Json] Security Considerations X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stefan@drees.name List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Jun 2013 08:49:37 -0000 On 2013-06-09 06:25, John Levine wrote: >> An implementation may set limits on any of the following: the size >> of texts that it accepts, the maximum depth of nesting, the range of >> numbers, and the length and character contents of strings. > > Probably should say something about the precision of numbers. With a > limited precision internal representation, two numbers that are > different in the JSON could end up equal internally. yes, thus I propose as NEW: """ 4. Parsers A JSON parser transforms JSON text into another representation, MUST accept all texts that conform to the JSON grammar and MUST be prepared to either accept duplicate names in objects or reject the complete JSON text containing these. A JSON parser MAY accept non-JSON forms or extensions. An implementation may set limits on any of the following: the size of texts that it accepts, the maximum depth of nesting, the range and precision of numbers, and the length and character contents of strings. """ I think simply extending the caveat for numbers to range and precision is sufficient, as integral numbers are to be considered having precision 0 and it all starts with a "may" ;-) Stefan. From stefan@drees.name Sun Jun 9 03:58:01 2013 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 281F421F8E93 for ; Sun, 9 Jun 2013 03:58:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.156 X-Spam-Level: X-Spam-Status: No, score=-1.156 tagged_above=-999 required=5 tests=[AWL=-1.022, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_22=0.6, J_CHICKENPOX_35=0.6, J_CHICKENPOX_45=0.6, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sMqYm8IIkKSg for ; Sun, 9 Jun 2013 03:57:56 -0700 (PDT) Received: from mout.web.de (mout.web.de [212.227.15.14]) by ietfa.amsl.com (Postfix) with ESMTP id 8A07E21F92BB for ; Sun, 9 Jun 2013 03:57:56 -0700 (PDT) Received: from newyork.local.box ([93.129.74.105]) by smtp.web.de (mrweb103) with ESMTPSA (Nemesis) id 0Lm4hJ-1UCqWw3CYj-00a9I1; Sun, 09 Jun 2013 12:57:48 +0200 Message-ID: <51B45FAA.4070900@drees.name> Date: Sun, 09 Jun 2013 12:57:46 +0200 From: Stefan Drees User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Stephen Dolan References: <51AF8479.5080002@crockford.com> <51b1168c.e686440a.5339.5fc4SMTPIN_ADDED_BROKEN@mx.google.com> <51B1B47C.9060009@drees.name> <51B1E909.2010402@drees.name> <51B1FE6A.80409@drees.name> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V02:K0:Bo+OnDd9eJcARKv/d+7UYOovijaiTtyeQAzmbVKZ1x7 F21rG98qxdcpIMYXaBc0+zrimhLzsM/gL5otPU+IV1X+0y2rh2 JRFjVGLopae/z/D+GRw/Ou6Ik5hsDeagM5pW/SdIEVv3A6DmI6 CuCqNWJ0k5+j/i6Ej/qH/Pi9bhVbl9XVlgr7LlGmrZMzVEvu49 PbBnOTVpCESFLTIv0ELSw== Cc: Vinny A , Markus Lanthaler , "json@ietf.org" Subject: Re: [Json] The names within an object SHOULD be unique. X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stefan@drees.name List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Jun 2013 10:58:01 -0000 On 2013-06-08 23:07, Stephen Dolan wrote: > On Fri, Jun 7, 2013 at 4:38 PM, Stefan Drees wrote: >> I do think, that forcing the consumer to "keep" the last parsed (whatever >> this means from the perspective of the source of the message) name as "the >> one" is **not** "good", nor "more secure" nor "doesn't break anything in the >> wild". > If TL;DR **please** at least goto "TL;DR", as there is an updated proposal. Thanks > It is more secure, and I'm not aware of anything in the wild that it > breaks. Perhaps my previous example of a security hole caused by this > was overly terse, so here's a longer description. > > Consider a system that takes requests from the outside world. Each > request is represented as a JSON object, and must include a "password" > field and a "command" field. > > Some commands (like "call-reception") may be performed by anyone by > passing a null password. Some commands (like "launch-missiles") > require a password. > > The command-processing system, upon receiving a request, forwards the > request to the authorization system, which determines whether the > command is authorized. The attacker sends: > > {"command": "launch-missiles", > "password":null, > "command": "call-reception"} > > The authorization system, using the standard JSON parser from Python > (or Ruby or PHP or JS or whatever), parses this as having a "command" > field which says "phone-reception", and authorizes the command. I think you mean "call-reception", right? > > The command-processing system, using the hypothetical parser jsDumb, > parses this as having a "command" field which says "launch-missiles". > Since the authorization system has OKed the command, this ends badly. Really having a hard time trying to imagine a use case, where someone came up with such an implementation of "separation of concerns". But I'd have a good old name for it: "Broken phone" :-) > Luckily for us, I do not believe jsDumb exists. A reasonably extensive > survey in another thread has failed to find such a parser. There are > of course streaming parsers such as Java's Jackson, which return all > of the keys and values - this is fine, as if the command-processing > system were to use such a parser it could simply error on requests > having multiple "command" fields. > > Unfortunately, the hypothetical jsDumb is considered a compliant > parser according to the current RFC, leading to the above security > hole where two compliant parsers can return entirely contradictory > results on the same document. I bet, if such a hypothetical system existed, it would be better of, when the authorization part yielded a transform as result of the check, as that would contain (besides additional transaction relevant data) as the only remaining user input: {"command":"call-reception"} so the command-processing system of your plot, would only communicate through the authorization component. If the "channel" would be secured only, anything goes ... > The issue is not two parsers returning different amounts of > information: Jackson returns more information about the document than > JSON.parse, for instance. The issue is two parsers returning *entirely > contradictory* information about the same document. > > It may be that jsDumb already exists and is deployed on millions of > machines, and JSON is doomed to insecurity forever. I don't think this > has happened yet - I don't know of any parser with jsDumb's behaviour. > In that case, the updated RFC should make clear that this behaviour is > wrong, to prevent future implementations having this hole. Ahem, the "hole" appears to be two system components playing broken phone. The rest of that scenario is quite exchangeable, isn't it? B.t.w: I have for sure invented far more dumb parsers, than that imaginary "jsDumb", trust me I just can't remember which ... ;-) The RFC should IMO stay within the naturally fuzzy, but nevertheless distinguishable realm of being a very general format in use for long and by many, thus I would opt for REALLY SHOULD but not for MUST. For detailed reasons for this please see my updated proposal and the relevant notes below (goto "TL;DR"). > Various phrases have been proposed, here's a couple: > > [Douglas Crockford] > If duplicate names are encountered, the parse MAY fail (because some > implementations correctly do that), or it MAY succeed by accepting the > last duplicated key:value pair. > > [Alan Wirfs-Brock] > The names within an object SHOULD be unique. If a key is duplicated, > a parser MUST take <> only the last of the > duplicated key pairs. > > [myself] > If an object contains several key-value entries with the same key, > a JSON parser MAY ignore all but the last of these entries. A JSON > parser MUST NOT ignore the last such entry. > > None of these disallow streaming parsers or other parsers that keep > all of the key-value pairs of an object. None of them disallow objects > with duplicate keys. The only thing disallowed is a parser which > interprets `{a:1, a:2}` as equivalent to `{a:1}`. updating my proposal for both the parser and generator sections yields: TL;DR: NEW: """ 4. Parsers A JSON parser transforms JSON text into another representation, MUST accept all texts that conform to the JSON grammar and MUST be prepared to either accept duplicate names in objects or reject the complete JSON text containing these. If the JSON parser transforms name/value pairs of JSON objects into maps inside the target representation by using the received names as keys, then it REALLY SHOULD always yield the values of the last encountered occurences of the name/value pairs as to satisfy the principle of least surprise. A JSON parser MAY accept non-JSON forms or extensions. An implementation may set limits on any of the following: the size of texts that it accepts, the maximum depth of nesting, the range and precision of numbers, and the length and character contents of strings. 5. Generators A JSON generator produces JSON text. The resulting text MUST strictly conform to the JSON grammar. Generators REALLY SHOULD NOT duplicate names in objects if they can avoid or detect such duplication. """ Notes: 1. Section 4 proposal part builds upon [1], where I introduced the possible number precision constraint as suggested by John Levine. 2. Inserted REALLY to form REALLY SHOULD NOT in generator section last paragraph as suggested by Joe Hildebrand in [2] 3. The new inserted text accomodating the "if not keep all, please keep last" proposal takes into account, that of course there are nice JSON parsers, that separate the transform of JSON to target storage reps from the parsing steps of the JSON message itself, by eg. providing callbacks (For instance YAJL c.f. [3]) others might offer method overrides / decorations or the like. Also a parser ignoring a token (or not) is not fully describing the problem we want to address, as we mix the scanning, parsing (where it would be applicable) with the target storage representation selected. I used yield, as a parser yields something (storage agnostically this remains true). 4. The formulation (as in 3.) also tries to spell out, that of course we do not have duplicate key:value pairs or the like (name/value pairs would be the correct intra JSON lingo) because we then had no problem at all, right :?) We have multiple pairs sharing the same name but not necessarily a common value. 5. Also (refering to the text as in 3.) we do not need a special recipe for the parser based on multiplicity of names, as keeping all or keeping the last occurence in the JSON text work for singleton cases alike. 6. (ibid) But we need to constrain on a single object (as my proposal does)! We really do not want to keep the last in this situation: {"foo":{"foo":{"bar":42}},"bar":"baz"} sample 6.a But of course in this: {"foo":{"foo":{"bar":42}},"foo":"baz"} sample 6.b where the result (keep last branch) would be undistinguisable from: {"foo":"baz"} sample 6.c 7. Hopefully we do not forget, that besides the serialized ordering of names in a JSON object, this depends on the ordering the generator used. In the current RFC this is completely implementation dependent. All hope for at least somehow "dependable ordering" i.e. reusing sample 6.a after the insertion a generator input side deletion of say the "inner" foo's value setting it to null: {"foo":{"foo":null},"bar":"baz"} sample 7.a And not (what would be completely ok): {"bar":"baz","foo":{"foo":null}} sample 7.b where inner changes have impact on the outer ordering. References: [1]: http://www.ietf.org/mail-archive/web/json/current/msg00688.html [2]: http://www.ietf.org/mail-archive/web/json/current/msg00428.html [3]: https://github.com/lloyd/yajl All the best, Stefan. From nico@cryptonector.com Sun Jun 9 10:22:16 2013 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 B04D621F8FF8 for ; Sun, 9 Jun 2013 10:22:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r+RxtmkPrbCX for ; Sun, 9 Jun 2013 10:22:11 -0700 (PDT) Received: from homiemail-a49.g.dreamhost.com (caiajhbdcaid.dreamhost.com [208.97.132.83]) by ietfa.amsl.com (Postfix) with ESMTP id C2FAE21F9017 for ; Sun, 9 Jun 2013 10:22:11 -0700 (PDT) Received: from homiemail-a49.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a49.g.dreamhost.com (Postfix) with ESMTP id 8279640141C61 for ; Sun, 9 Jun 2013 10:22:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=iQPRtyXUVUjL++uCP/4D zeEQ3SI=; b=gqK640K/UaQSyzJ0lEJZqgWulbSc57hvXWFlVcCl8E3Iea2uqI7d hvYFbS1f8nlLqnP6Co3ddAfDnBvcShRkHF1lz7TyqJpiZYNGhEXGdOsIiAZRDqsq 2WU5bGc5T/ViKvlzuF5MExzYwbU/asE2UAG3jF+3lkFlwJgz9DfJkIc= Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a49.g.dreamhost.com (Postfix) with ESMTPSA id 2B67C4012CFE1 for ; Sun, 9 Jun 2013 10:22:11 -0700 (PDT) Received: by mail-wg0-f50.google.com with SMTP id k13so4333398wgh.5 for ; Sun, 09 Jun 2013 10:22:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=tJ80twtS2VcwiuEdEqtAyINPoYM5LIDszcSp/ONlBRc=; b=loXCObGyPpLLQeUfUkxRSISClW4jGfnjPOAlOrhol5QkbvPOMF4FDfywgtPy1DQjX8 9eqU0I+FvkAK7te8ad5E7QCn27XVR+cwEBl0dB5Oimn4TqgQerA+8Q45RP9bhwiBwyWI IGyrqbGBOtND+S9fKwnyqllJPTEJkPR+iryC44lipDNrm/mJKANbw8d0oQhD1jAOadxY Ka7+WeybnwutDu68pGtonB8NplI63iEqMAqlDjThwAs7IKB1LTLzTV67KOOK18vYpDnc Vg7fujG2hUFGpm98nQwdwR+yoo/0MYtfHT+RKpDvVe93tK3/wEmQioF3uUgLFloksTIs Uibw== MIME-Version: 1.0 X-Received: by 10.180.12.72 with SMTP id w8mr3019784wib.4.1370798529556; Sun, 09 Jun 2013 10:22:09 -0700 (PDT) Received: by 10.216.63.136 with HTTP; Sun, 9 Jun 2013 10:22:09 -0700 (PDT) In-Reply-To: <51B45FAA.4070900@drees.name> References: <51AF8479.5080002@crockford.com> <51b1168c.e686440a.5339.5fc4SMTPIN_ADDED_BROKEN@mx.google.com> <51B1B47C.9060009@drees.name> <51B1E909.2010402@drees.name> <51B1FE6A.80409@drees.name> <51B45FAA.4070900@drees.name> Date: Sun, 9 Jun 2013 12:22:09 -0500 Message-ID: From: Nico Williams To: "stefan@drees.name" Content-Type: multipart/alternative; boundary=001a11c2438669bb1204debbe70c Cc: Vinny A , Stephen Dolan , Markus Lanthaler , "json@ietf.org" Subject: Re: [Json] The names within an object SHOULD be unique. X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 09 Jun 2013 17:22:16 -0000 --001a11c2438669bb1204debbe70c Content-Type: text/plain; charset=UTF-8 > > FYI, "REALLY" is not an RFC2119 word :) --001a11c2438669bb1204debbe70c Content-Type: text/html; charset=UTF-8
FYI, "REALLY" is not an RFC2119 word :)
--001a11c2438669bb1204debbe70c-- From stefan@drees.name Sun Jun 9 11:33:26 2013 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 584A521F8AE8 for ; Sun, 9 Jun 2013 11:33:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.237 X-Spam-Level: X-Spam-Status: No, score=-1.237 tagged_above=-999 required=5 tests=[AWL=-0.847, BAYES_20=-0.74, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WJ5FB7VAOStf for ; Sun, 9 Jun 2013 11:33:21 -0700 (PDT) Received: from mout.web.de (mout.web.de [212.227.15.4]) by ietfa.amsl.com (Postfix) with ESMTP id E230221F89EB for ; Sun, 9 Jun 2013 11:33:20 -0700 (PDT) Received: from newyork.local.box ([93.129.74.105]) by smtp.web.de (mrweb001) with ESMTPSA (Nemesis) id 0LwI2w-1UIRGU20Cc-0184qH; Sun, 09 Jun 2013 20:33:09 +0200 Message-ID: <51B4CA62.2000800@drees.name> Date: Sun, 09 Jun 2013 20:33:06 +0200 From: Stefan Drees User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Nico Williams References: <51AF8479.5080002@crockford.com> <51b1168c.e686440a.5339.5fc4SMTPIN_ADDED_BROKEN@mx.google.com> <51B1B47C.9060009@drees.name> <51B1E909.2010402@drees.name> <51B1FE6A.80409@drees.name> <51B45FAA.4070900@drees.name> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:V8Hz+IFFiXVrxtULDDWWMGJxJAIzJZBDpfBXw8cqb//gKrObQqI 5t9hBzAPAYDeouCInbR9YETquGECDXr1JiTF7w+g+JOg/3Qi4+WgOCiKZaiTtUcoplOuJs6 Dj4WQ+0i1zsQC3jIEHDSEEwiVfpwxexyzDIl2fM1wkois7c3sOyZLUbZ41Rghmen6gj6+rk DS866gmsWpLfgzz/HtThw== Cc: Vinny A , Stephen Dolan , Markus Lanthaler , "json@ietf.org" Subject: Re: [Json] The names within an object SHOULD be unique. X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stefan@drees.name List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Jun 2013 18:33:26 -0000 On 2013-06-09 19:22, Nico Williams wrote: > FYI, "REALLY" is not an RFC2119 word :) > that WOULD PROBABLY well be, but as suggested in the reference [2] in the proposing mail, I thereby disclose my hidden agenda, that the JSON RFC additionally references [RFC6919] empowering us "en passant" with a really deeper felt SHOULD NOT while discussing and secretly removing the reference and lowercasing the word "REALLY" just before the last consensus call :-) References: [RFC6919]: R. Barnes, S. Kent, E. Rescorla "Further Key Words for Use in RFCs to Indicate Requirement Levels", 1. April 2013, http://www.ietf.org/rfc/rfc6919.txt [2]: http://www.ietf.org/mail-archive/web/json/current/msg00428.html Please excuse the occurence of the terms "hidden" and "secretly" in a mail being part of an open exchange of thoughts ;-) Stefan. From nico@cryptonector.com Sun Jun 9 12:41:31 2013 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 BADD521F9633 for ; Sun, 9 Jun 2013 12:41:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.951 X-Spam-Level: X-Spam-Status: No, score=-1.951 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k7mYiWwHT-o6 for ; Sun, 9 Jun 2013 12:41:26 -0700 (PDT) Received: from homiemail-a29.g.dreamhost.com (caiajhbdcbhh.dreamhost.com [208.97.132.177]) by ietfa.amsl.com (Postfix) with ESMTP id C529121F9695 for ; Sun, 9 Jun 2013 12:41:26 -0700 (PDT) Received: from homiemail-a29.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a29.g.dreamhost.com (Postfix) with ESMTP id ED8AA674058 for ; Sun, 9 Jun 2013 12:41:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=H4O8/vM3xxSoeFWpIZTd YDhcq1M=; b=eFZ0QCg6NKINC4wEFMrKiUp8teabkqY4FOfm3t8KnE+46weROpVN Mmx+xg94LwyIyfvmCmHcJRWgrQ0DD7wz6cxDullR2dM/GCfBAUhlGeReWkvZz+39 LlMjngsNQnKqGcIOBShE9wvniELsMO/eCI8ZSMxkDZsxyLjYw7Teudo= Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a29.g.dreamhost.com (Postfix) with ESMTPSA id A2676674057 for ; Sun, 9 Jun 2013 12:41:25 -0700 (PDT) Received: by mail-wg0-f50.google.com with SMTP id k13so4385505wgh.5 for ; Sun, 09 Jun 2013 12:41:24 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=uFnThG4nS98gR1bOUBh//8hPYL86Nkak1H21gYcroh0=; b=U/ZIBnwOjMqmc+BK3e0Od7++GpI0WZsirAW5LYqkmVIfxYaDvck6Sb9nYGX/BnLJ10 VXtWhF1lv4lDaVoEKZWq/5JyrOJ1VsAcyKUZtxE+8pD+nIPlcLaXK3qXMHjV0mnBL4kq LN4fjwkAabmJXgDl/2UNeUVhuIUUSjfQyMPtYYS8PvQAtKzcQMSmVDxOT1WwGavN83EE 0uAJvv1KPOA6iyKDuUcrkXGRppyC6PYi9WHOa+DV6zaT4UMgrIsCFymGC+xjJT3P50Ak 630EjljY1gtx01fBnSPsbRHEBE7VkBRIw42RuqDjNu5ucLiA6Df/wYi/CvulieZAm9hP 0p8A== MIME-Version: 1.0 X-Received: by 10.194.8.163 with SMTP id s3mr3889530wja.41.1370806884269; Sun, 09 Jun 2013 12:41:24 -0700 (PDT) Received: by 10.216.63.136 with HTTP; Sun, 9 Jun 2013 12:41:24 -0700 (PDT) In-Reply-To: <51B4CA62.2000800@drees.name> References: <51AF8479.5080002@crockford.com> <51b1168c.e686440a.5339.5fc4SMTPIN_ADDED_BROKEN@mx.google.com> <51B1B47C.9060009@drees.name> <51B1E909.2010402@drees.name> <51B1FE6A.80409@drees.name> <51B45FAA.4070900@drees.name> <51B4CA62.2000800@drees.name> Date: Sun, 9 Jun 2013 14:41:24 -0500 Message-ID: From: Nico Williams To: "stefan@drees.name" Content-Type: multipart/alternative; boundary=047d7b5d253e64885b04debdd98d Cc: "json@ietf.org" , Nico Williams , Stephen Dolan , Markus Lanthaler , Vinny A Subject: Re: [Json] The names within an object SHOULD be unique. X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 09 Jun 2013 19:41:31 -0000 --047d7b5d253e64885b04debdd98d Content-Type: text/plain; charset=UTF-8 The problem with normatively referencing RFC6919 is that we'd be limited to publication on just one day in any given year, otherwise I tthink it'd be a great idea! --047d7b5d253e64885b04debdd98d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable The problem with normatively referencing RFC6919 is that we'd be<= /span>=C2=A0limited to publication on just one day in any given year, other= wise I tthink it'd be a great idea! --047d7b5d253e64885b04debdd98d-- From markus.lanthaler@gmx.net Sun Jun 9 12:47:08 2013 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 C238521F944C for ; Sun, 9 Jun 2013 12:47:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.15 X-Spam-Level: X-Spam-Status: No, score=-1.15 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UV+VuiKS2NDf for ; Sun, 9 Jun 2013 12:46:54 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by ietfa.amsl.com (Postfix) with ESMTP id 18A7021F92B7 for ; Sun, 9 Jun 2013 12:46:53 -0700 (PDT) Received: from mailout-de.gmx.net ([10.1.76.35]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0LlsgY-1UCQl01Bku-00ZLwa for ; Sun, 09 Jun 2013 21:46:50 +0200 Received: (qmail invoked by alias); 09 Jun 2013 19:46:49 -0000 Received: from 84-115-182-43.dynamic.surfer.at (EHLO Vostro3500) [84.115.182.43] by mail.gmx.net (mp035) with SMTP; 09 Jun 2013 21:46:49 +0200 X-Authenticated: #419883 X-Provags-ID: V01U2FsdGVkX1+4flgqXJK4/uzoTAiLA9M+Wf6hPpphc54px1+2dj arGFXeYdq167PL From: "Markus Lanthaler" To: "'R S'" References: <51b23e6d.6196420a.0b15.4245SMTPIN_ADDED_BROKEN@mx.google.com> In-Reply-To: Date: Sun, 9 Jun 2013 21:46:40 +0200 Message-ID: <00c101ce654a$1043ff00$30cbfd00$@lanthaler@gmx.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-index: Ac5jx0Ip8LONTUOvSG2GGjTG52/FtABgfzBw Content-Language: de X-Y-GMX-Trusted: 0 Cc: json@ietf.org Subject: Re: [Json] Allow any JSON value at the top level X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 09 Jun 2013 19:47:08 -0000 On Friday, June 07, 2013 11:38 PM, R S wrote: > I believe this proposal is in scope--it's one of the inconsistencies > with ECMAScript this group has been tasked with resolving, and it was > mentioned during the chartering process. I disagree. Allowing something else than an object or an array at the top-level is clearly out of scope IMO. > Are there interoperability problems we should be aware of? In my > experience, this change doesn't matter to applications that can only > handle objects or arrays--they simply encounter an error immediately > after parsing rather than during it. Well, changing the {}s to <>s would also result in an error but that doesn't mean that it won't cause problems. The most important thing for this WG is to preserve backwards-compatibility. Turning JSON parsers that are currently completely conformant obsolete and arguing that they would error clearly breaks backwards compatibility. As someone else showed in a different thread, this would e.g. break Rail's default JSON parser. -- Markus Lanthaler @markuslanthaler From sayrer@gmail.com Sun Jun 9 13:24:32 2013 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 BA11821F8C20 for ; Sun, 9 Jun 2013 13:24:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.404 X-Spam-Level: X-Spam-Status: No, score=-2.404 tagged_above=-999 required=5 tests=[AWL=0.195, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yxXGI380DvAM for ; Sun, 9 Jun 2013 13:24:32 -0700 (PDT) Received: from mail-we0-x231.google.com (mail-we0-x231.google.com [IPv6:2a00:1450:400c:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id 7BB3521F8BF7 for ; Sun, 9 Jun 2013 13:24:31 -0700 (PDT) Received: by mail-we0-f177.google.com with SMTP id m19so4314663wev.36 for ; Sun, 09 Jun 2013 13:24:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=C1vcy0FMWca/7caslC791kmE48hakJX68jtLZ5eYOo8=; b=eR99tpNX3MtXGNePv/CjWCkYdbU6JZY6UgsZIDgWsHKNclulY3IxeV/s0ivk8R8mHj BarKpW4qCJwaR0Jw6TcEQWphEN0peuu5X3vcA4C91Xho0lmQGpKLRzhTEM3R4JkNZMsq bTH/v4FcsacwSV4DoWfoWwvDLGHwg5wYwhxbdjUT+E/NNf5MxNQ5bw+3PkH2q1J7P65F 95q057t4UTSZIir04k/oKCxX2nqGfD+uGWca+0GVRDWzwBFW68A+Kpuuza2YE4RWLF27 yI54LJMvRYbVjffwdrN4P1Swch8b9lAsvJ/aTYIaeFvJRhPqbWkMDEGSchgPCsIMqNLH r4tQ== MIME-Version: 1.0 X-Received: by 10.180.206.77 with SMTP id lm13mr3168306wic.18.1370809470475; Sun, 09 Jun 2013 13:24:30 -0700 (PDT) Received: by 10.194.83.35 with HTTP; Sun, 9 Jun 2013 13:24:30 -0700 (PDT) In-Reply-To: <51b4dbbe.64da440a.1fc2.6dd2SMTPIN_ADDED_BROKEN@mx.google.com> References: <51b23e6d.6196420a.0b15.4245SMTPIN_ADDED_BROKEN@mx.google.com> <51b4dbbe.64da440a.1fc2.6dd2SMTPIN_ADDED_BROKEN@mx.google.com> Date: Sun, 9 Jun 2013 13:24:30 -0700 Message-ID: From: R S To: Markus Lanthaler Content-Type: multipart/alternative; boundary=001a11c380ae8ae57904debe73ca Cc: "json@ietf.org" Subject: Re: [Json] Allow any JSON value at the top level X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 09 Jun 2013 20:24:32 -0000 --001a11c380ae8ae57904debe73ca Content-Type: text/plain; charset=ISO-8859-1 On Sun, Jun 9, 2013 at 12:46 PM, Markus Lanthaler wrote: > > > > Are there interoperability problems we should be aware of? In my > > experience, this change doesn't matter to applications that can only > > handle objects or arrays--they simply encounter an error immediately > > after parsing rather than during it. > > Well, changing the {}s to <>s would also result in an error but that > doesn't > mean that it won't cause problems. > That would not be backward compatible. > The most important thing for this WG is > to preserve backwards-compatibility. Turning JSON parsers that are > currently > completely conformant obsolete and arguing that they would error clearly > breaks backwards compatibility. > "In telecommunications and computing, a product or technology is backward or downward compatible if it can work with input generated by an older product or technology." < https://en.wikipedia.org/wiki/Backward_compatibility> Arrays and Objects at the root will still work, obviously, so this proposal can be said to be backward compatible. > As someone else showed in a different > thread, this would e.g. break Rail's default JSON parser. > How would it break that parser? My employer happens to operate a very large Rails site with heavy JSON traffic. We use a popular open-source JSON gem. It supports the primitive root values proposed here. - Rob --001a11c380ae8ae57904debe73ca Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Sun, Jun 9, 2013 at 12:46 PM, Markus Lanthaler <markus.lanthaler@gmx.net> wrote:


> Are there interoperability problems we should = be aware of? In my
> experience, this change doesn't matter to applications that can on= ly
> handle objects or arrays--they simply encounter an error immediately > after parsing rather than during it.

Well, changing the {}s to <>s would also resu= lt in an error but that doesn't
mean that it won't cause problems.

That would not be backward compatible.

= =A0
The most important thing for this WG is
to preserve backwards-compatibility. Turning JSON parsers that are currentl= y
completely conformant obsolete and arguing that they would error clearly breaks backwards compatibility.


<= /div>
"In telecommunications and computing, a product or technolog= y is backward or downward compatible if it can work with input generated by= an older product or technology." <https://en.wikipedia.org/wiki/Backward_com= patibility>

Arrays and Objects at the root will still w= ork, obviously, so this proposal can be said to be backward compatible.

=A0
As someone else showed in a different
thread, this would e.g. break Rail's default JSON parser.

How would it break that parser? My emplo= yer happens to operate a very large Rails site with heavy JSON traffic. We = use a popular open-source JSON gem. It supports the primitive root values p= roposed here.

- Rob
=A0
--001a11c380ae8ae57904debe73ca-- From paul.hoffman@vpnc.org Sun Jun 9 13:38:05 2013 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 39D4D21F85C9 for ; Sun, 9 Jun 2013 13:38:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.402 X-Spam-Level: X-Spam-Status: No, score=-102.402 tagged_above=-999 required=5 tests=[AWL=0.197, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VmVTcVaYq7hE for ; Sun, 9 Jun 2013 13:38:04 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id CF0ED21F8450 for ; Sun, 9 Jun 2013 13:38:04 -0700 (PDT) Received: from [10.20.30.90] (50-0-66-165.dsl.dynamic.sonic.net [50.0.66.165]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r59Kc26i089257 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Sun, 9 Jun 2013 13:38:03 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Paul Hoffman In-Reply-To: <51B44197.2000006@drees.name> Date: Sun, 9 Jun 2013 13:38:02 -0700 Content-Transfer-Encoding: 7bit Message-Id: <014BC561-ECB9-4C82-B759-580025770E58@vpnc.org> References: <20130609042518.11918.qmail@joyce.lan> <51B44197.2000006@drees.name> To: "json@ietf.org" X-Mailer: Apple Mail (2.1508) Subject: [Json] Description of parsers X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 09 Jun 2013 20:38:05 -0000 Starting this as a new thread. On Jun 9, 2013, at 1:49 AM, Stefan Drees wrote: > yes, thus I propose as NEW: > > 4. Parsers > > A JSON parser transforms JSON text into another representation, > MUST accept all texts that conform to the JSON grammar and MUST be > prepared to either accept duplicate names in objects or reject the > complete JSON text containing these. > A JSON parser MAY accept non-JSON forms or extensions. > > An implementation may set limits on any of the following: the size > of texts that it accepts, the maximum depth of nesting, the range > and precision of numbers, and the length and character contents of > strings. From markus.lanthaler@gmx.net Sun Jun 9 13:57:38 2013 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 F1E2921F859A for ; Sun, 9 Jun 2013 13:57:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.15 X-Spam-Level: X-Spam-Status: No, score=-1.15 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3BfzDV5fHakp for ; Sun, 9 Jun 2013 13:57:33 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) by ietfa.amsl.com (Postfix) with ESMTP id EC2A321F8206 for ; Sun, 9 Jun 2013 13:57:32 -0700 (PDT) Received: from mailout-de.gmx.net ([10.1.76.16]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0McTEs-1V3JYn3Wee-00HfwG for ; Sun, 09 Jun 2013 22:57:21 +0200 Received: (qmail invoked by alias); 09 Jun 2013 20:57:21 -0000 Received: from 84-115-182-43.dynamic.surfer.at (EHLO Vostro3500) [84.115.182.43] by mail.gmx.net (mp016) with SMTP; 09 Jun 2013 22:57:21 +0200 X-Authenticated: #419883 X-Provags-ID: V01U2FsdGVkX19QoVgOhCJQHe4zRIqL2uzr2TgNmcxVpjFpW52GIz NYCgFDxXN6ehUa From: "Markus Lanthaler" To: References: <51b23e6d.6196420a.0b15.4245SMTPIN_ADDED_BROKEN@mx.google.com> <51b4dbbe.64da440a.1fc2.6dd2SMTPIN_ADDED_BROKEN@mx.google.com> In-Reply-To: Date: Sun, 9 Jun 2013 22:57:12 +0200 Message-ID: <00d901ce6553$ea8d68f0$bfa83ad0$@lanthaler@gmx.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-index: Ac5lT1hiyURBwTPNT/CrI1OSSJSvEAAA9+iQ Content-Language: de X-Y-GMX-Trusted: 0 Subject: Re: [Json] Allow any JSON value at the top level X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 09 Jun 2013 20:57:38 -0000 On Sunday, June 09, 2013 10:25 PM, R S wrote: >> The most important thing for this WG is >> to preserve backwards-compatibility. Turning JSON parsers >> that are currently completely conformant obsolete and arguing >> that they would error clearly breaks backwards compatibility. > > "In telecommunications and computing, a product or technology > is backward or downward compatible if it can work with input > generated by an older product or technology." > > > Arrays and Objects at the root will still work, obviously, > so this proposal can be said to be backward compatible. You are of course completely right, backward compatibility was the wrong term here. Sorry. >> As someone else showed in a different >> thread, this would e.g. break Rail's default JSON parser. > > How would it break that parser? My employer happens to operate > a very large Rails site with heavy JSON traffic. We use a popular > open-source JSON gem. It supports the primitive root values proposed > here. See http://www.ietf.org/mail-archive/web/json/current/msg00670.html Why can't a separate media type, e.g., application/json-value, be defined allowing this? The fact that that hasn't been done in the last decade should tell us something. Why do we have to change JSON in such a fundamental way? -- Markus Lanthaler @markuslanthaler From nico@cryptonector.com Sun Jun 9 14:08:34 2013 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 5736A21F8904 for ; Sun, 9 Jun 2013 14:08:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NBiZH2Ca+hP0 for ; Sun, 9 Jun 2013 14:08:20 -0700 (PDT) Received: from homiemail-a71.g.dreamhost.com (caiajhbdccah.dreamhost.com [208.97.132.207]) by ietfa.amsl.com (Postfix) with ESMTP id AB5FF21F8930 for ; Sun, 9 Jun 2013 14:08:20 -0700 (PDT) Received: from homiemail-a71.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a71.g.dreamhost.com (Postfix) with ESMTP id 4A0C7428072 for ; Sun, 9 Jun 2013 14:08:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=Lu0TYoB7n2+x94PRzSKv ZQ+iQnU=; b=NPm7ku2waNcabEMWil4mBWbPFDATE7F324wKzYRSSPCKN7Vd3mWP 77wu5misFKZV7JP4DSKkHYgdrBB83IT1QWi81xJ91nXiqy3eahMLSGUbtK//Hszm eziD1hf/1q7wkxPPWvXw3rRNIJcx1LI2TK6gvFW4fd57c8Su6OkD7O4= Received: from mail-wi0-f180.google.com (mail-wi0-f180.google.com [209.85.212.180]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a71.g.dreamhost.com (Postfix) with ESMTPSA id E9CAC42806E for ; Sun, 9 Jun 2013 14:08:19 -0700 (PDT) Received: by mail-wi0-f180.google.com with SMTP id c10so880103wiw.1 for ; Sun, 09 Jun 2013 14:08:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=JuhuBV7Dejbq4w8pz8iGH+ZFRK0/sneCRZ9wmA9olMk=; b=RkKl/GTgYioNHuYf3BN6AfJrVfOcGf4oyd8RnJNQSxdzzsd+gUWBJPVFVWTslPLA7z yfUJbeoWL7OFAus6l/1ryxUgTriJ7JuQFspl5S5mYs6PaWXolEfh4HYy10z85SwXuMGc VFkTQYyPkbJcV+tZCJxv1u2On45pwdcNcxgF6ZjH0M+VlgWi2FJUMwK8YUNM+Bi6CUnG CalKqQSanRWZG/H/iWIpfq0uq8UbPJhSHNNWNLT1qwcfAiFZfPn9qXqBx1CPbZ3/wD1B ek4Rg3Dn+XfXeHfmCIly0ud9NTPlw9b86GHYx+6T+eNc5TOo4qbmfk9DxvZuqNvTFrST sw7w== MIME-Version: 1.0 X-Received: by 10.194.158.69 with SMTP id ws5mr2894600wjb.84.1370812098503; Sun, 09 Jun 2013 14:08:18 -0700 (PDT) Received: by 10.216.63.136 with HTTP; Sun, 9 Jun 2013 14:08:18 -0700 (PDT) Received: by 10.216.63.136 with HTTP; Sun, 9 Jun 2013 14:08:18 -0700 (PDT) In-Reply-To: <51b4ec44.c5a22a0a.1b34.ffffa62dSMTPIN_ADDED_BROKEN@mx.google.com> References: <51b23e6d.6196420a.0b15.4245SMTPIN_ADDED_BROKEN@mx.google.com> <51b4dbbe.64da440a.1fc2.6dd2SMTPIN_ADDED_BROKEN@mx.google.com> <51b4ec44.c5a22a0a.1b34.ffffa62dSMTPIN_ADDED_BROKEN@mx.google.com> Date: Sun, 9 Jun 2013 16:08:18 -0500 Message-ID: From: Nico Williams To: Markus Lanthaler Content-Type: multipart/alternative; boundary=e89a8f64355c2f71c304debf10af Cc: json@ietf.org Subject: Re: [Json] Allow any JSON value at the top level X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 09 Jun 2013 21:08:34 -0000 --e89a8f64355c2f71c304debf10af Content-Type: text/plain; charset=UTF-8 At least several encoders and parsers allow any value type at the top-level, either as an option or no matter what. --e89a8f64355c2f71c304debf10af Content-Type: text/html; charset=UTF-8

At least several encoders and parsers allow any value type at the top-level, either as an option or no matter what.

--e89a8f64355c2f71c304debf10af-- From jorge@jorgechamorro.com Sun Jun 9 14:39:25 2013 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 AADE721F8EF7 for ; Sun, 9 Jun 2013 14:39:25 -0700 (PDT) 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=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U8UGFkzVyxJD for ; Sun, 9 Jun 2013 14:39:25 -0700 (PDT) Received: from mail-we0-x22a.google.com (mail-we0-x22a.google.com [IPv6:2a00:1450:400c:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id A4A0121F8EBE for ; Sun, 9 Jun 2013 14:39:24 -0700 (PDT) Received: by mail-we0-f170.google.com with SMTP id w57so4401313wes.1 for ; Sun, 09 Jun 2013 14:39:23 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=/3+Xx5EdfJ1YXaITsMwS+UkliA1e6R2k4yL8qKYZAFE=; b=ZoxGYs1zAa+idP/GhGeMB4j6+f6OOPfx+xiqhDhdjqLHPQOjn5eHc5ywDknUo0y2jd AD7z545lA5SfjKojSrRzFWl05qGHMuszIR4JnQJfbphXFnJnHK2YnDftYVAApmrDtUT7 XqpsxfRQJXy0r//MVoqJymV0ooQIcc2WCcXcR1MiGjA8/bSDpXuOC5v5R2zTxYGUY5Je C+eqkfSiNXph5TnJMLKYFzuCD1TJF24jbeTEOGp5ptqTOv3sWNR8x69UQW1ooXriW5mO 4ZBsoNLfMd1B4ZjEz5iLx1K6+ExyFZTdJlRWHtwjF07VFrOpSGfTBHaG6uE1aJPqEJAC Hqrw== X-Received: by 10.180.23.101 with SMTP id l5mr728235wif.30.1370813963445; Sun, 09 Jun 2013 14:39:23 -0700 (PDT) Received: from [192.168.10.50] (99.Red-79-144-66.dynamicIP.rima-tde.net. [79.144.66.99]) by mx.google.com with ESMTPSA id h8sm8029767wiz.9.2013.06.09.14.39.22 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 09 Jun 2013 14:39:23 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Jorge In-Reply-To: Date: Sun, 9 Jun 2013 23:39:19 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <8C697BA1-AD6B-4E8A-B5AF-0F4ACADEA2C6@jorgechamorro.com> References: <51b23e6d.6196420a.0b15.4245SMTPIN_ADDED_BROKEN@mx.google.com> <51b4dbbe.64da440a.1fc2.6dd2SMTPIN_ADDED_BROKEN@mx.google.com> <51b4ec44.c5a22a0a.1b34.ffffa62dSMTPIN_ADDED_BROKEN@mx.google.com> To: Nico Williams X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQlM5tpwKyfe2dSCuvYvQzbKy1q3DgOlY8bMPouQSrvTaullMHAjYj+iLfUNjugDtJoepR/i Cc: Markus Lanthaler , json@ietf.org Subject: Re: [Json] Allow any JSON value at the top level X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 09 Jun 2013 21:39:25 -0000 On 09/06/2013, at 23:08, Nico Williams wrote: > At least several encoders and parsers allow any value type at the = top-level, either as an option or no matter what. All the current browsers can both .parse() and .stringify() strings, = numbers, null and booleans at the top-level, per the ES5 specs (*): JSON.parse(JSON.stringify("string")) "string" JSON.parse(JSON.stringify(27)) 27 JSON.parse(JSON.stringify(true)) true JSON.parse(JSON.stringify(false)) false JSON.parse(JSON.stringify(null)) null JSON.parse(JSON.stringify([27])) [27] JSON.parse(JSON.stringify({a:1})) {a:1} (*) "The parse function parses a JSON text (a JSON-formatted String) and = produces an ECMAScript value. The JSON format is a restricted form of = ECMAScript literal. JSON objects are realized as ECMAScript objects. = JSON arrays are realized as ECMAScript arrays. JSON strings, numbers, = booleans, and null are realized as ECMAScript Strings, Numbers, = Booleans, and null." "The stringify function returns a String in JSON format representing an = ECMAScript value. It can take three parameters. The first parameter is = required. The value parameter is an ECMAScript value, which is usually = an object or array, although it can also be a String, Boolean, Number or = null." --=20 ( Jorge )(); From markus.lanthaler@gmx.net Sun Jun 9 15:54:36 2013 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 E70D321F8EC6 for ; Sun, 9 Jun 2013 15:54:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.15 X-Spam-Level: X-Spam-Status: No, score=-1.15 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d5w-gkW958lK for ; Sun, 9 Jun 2013 15:54:31 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) by ietfa.amsl.com (Postfix) with ESMTP id DF99321F8EBE for ; Sun, 9 Jun 2013 15:54:30 -0700 (PDT) Received: from mailout-de.gmx.net ([10.1.76.34]) by mrigmx.server.lan (mrigmx002) with ESMTP (Nemesis) id 0M2rdY-1UTre61jL4-00sfP5 for ; Mon, 10 Jun 2013 00:54:28 +0200 Received: (qmail invoked by alias); 09 Jun 2013 22:54:28 -0000 Received: from 84-115-182-43.dynamic.surfer.at (EHLO Vostro3500) [84.115.182.43] by mail.gmx.net (mp034) with SMTP; 10 Jun 2013 00:54:28 +0200 X-Authenticated: #419883 X-Provags-ID: V01U2FsdGVkX1+y8A100/6yGDyyeGwH3eoiTjpGdJPJ6SCTrZSVcH 0YSG/SfR375o9t From: "Markus Lanthaler" To: References: <51b23e6d.6196420a.0b15.4245SMTPIN_ADDED_BROKEN@mx.google.com> <51b4dbbe.64da440a.1fc2.6dd2SMTPIN_ADDED_BROKEN@mx.google.com> <51b4ec44.ea05420a.7c73.ffffa487SMTPIN_ADDED_BROKEN@mx.google.com> In-Reply-To: Date: Mon, 10 Jun 2013 00:54:18 +0200 Message-ID: <011e01ce6564$46ab75e0$d40261a0$@lanthaler@gmx.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-index: Ac5lVS9F2Zy3VGmoQZudbBaWNbD8ugADtZ3g Content-Language: de X-Y-GMX-Trusted: 0 Subject: Re: [Json] Allow any JSON value at the top level X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 09 Jun 2013 22:54:37 -0000 On Sunday, June 09, 2013 11:06 PM, R S wrote: >> Why can't a separate media type, e.g., application/json-value, >> be defined allowing this? > > We could do that, but it might be a bit pointless. It won't change > the fact that primitive values are already sent as application/json. Who's doing that? -- Markus Lanthaler @markuslanthaler From stefan@drees.name Sun Jun 9 23:18:14 2013 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 CEA1E21F866E for ; Sun, 9 Jun 2013 23:18:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.13 X-Spam-Level: X-Spam-Status: No, score=-2.13 tagged_above=-999 required=5 tests=[AWL=0.119, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VdRTUT2a8Iv6 for ; Sun, 9 Jun 2013 23:18:10 -0700 (PDT) Received: from mout.web.de (mout.web.de [212.227.17.12]) by ietfa.amsl.com (Postfix) with ESMTP id DDE5921F859B for ; Sun, 9 Jun 2013 23:18:09 -0700 (PDT) Received: from newyork.local.box ([93.129.126.10]) by smtp.web.de (mrweb103) with ESMTPSA (Nemesis) id 0MJTVP-1UoO8K1aZ9-002jeA; Mon, 10 Jun 2013 08:18:07 +0200 Message-ID: <51B56F9F.1000603@drees.name> Date: Mon, 10 Jun 2013 08:18:07 +0200 From: Stefan Drees User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Paul Hoffman References: <20130609042518.11918.qmail@joyce.lan> <51B44197.2000006@drees.name> <014BC561-ECB9-4C82-B759-580025770E58@vpnc.org> In-Reply-To: <014BC561-ECB9-4C82-B759-580025770E58@vpnc.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V02:K0:DjOIg+wQ1twYfBQNq79W9iPCzIy+rDFrnyY7sigd+Tj Ds6YtXuRRucSe+76F1intf9nTmjk/ik0XGqDtO8UH3GptOiAb/ puiNhKoZP5dW0n3hUP5u4mzBUhs0iedwHsrCiE05LWNfxVTvLK Wz0h3kwqEC8ZkJiC3brUjsKQuxvQxnnP5npfAXldSg/A2BaE+Z QcKOkHQ5n114WVt5kZ3Zw== Cc: "json@ietf.org" Subject: Re: [Json] Description of parsers X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stefan@drees.name List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jun 2013 06:18:14 -0000 On 2013-06-09 22:38 CEST, Paul Hoffman wrote: > Starting this as a new thread. > > On Jun 9, 2013, at 1:49 AM, Stefan Drees ... wrote: > >> yes, thus I propose as NEW: >> >> 4. Parsers >> >> A JSON parser transforms JSON text into another representation, >> MUST accept all texts that conform to the JSON grammar and MUST be >> prepared to either accept duplicate names in objects or reject the >> complete JSON text containing these. >> A JSON parser MAY accept non-JSON forms or extensions. >> >> An implementation may set limits on any of the following: the size >> of texts that it accepts, the maximum depth of nesting, the range >> and precision of numbers, and the length and character contents of >> strings. As the discussion continued, I rewrote the proposal in [1] (cf. for notes and motivation there) suggesting the harshest possible "soft" guard against the "parsing and storage" scenario described by "not yielding the last occurence of multiple names, when only yielding one", "discussed" the "REALLY SHOULD always" of the second sentence of [1] in [2,3] with Nico and now hereby offer the freshest proposal for the Parsers section to start discussing in this new thread created by Paul: NEW: """ 4. Parsers A JSON parser transforms JSON text into another representation, MUST accept all texts that conform to the JSON grammar and MUST be prepared to either accept duplicate names in objects or reject the complete JSON text containing these. If the JSON parser transforms name/value pairs of JSON objects into maps inside the target representation by using the received names as keys, then it MUST yield the values of the last encountered occurences of the name/value pairs as to satisfy the principle of least surprise. A JSON parser MAY accept non-JSON forms or extensions. An implementation may set limits on any of the following: the size of texts that it accepts, the maximum depth of nesting, the range and precision of numbers, and the length and character contents of strings. """ So finally I throw a MUST into the ring! Let's try to describe currrent practice and - armed with precise details of the parsing and storage scenario we refer to - set an upper bound for ambiguity that started when JSON was born without explicitely stating the consequence of interpreting names (in objects) as keys. What do you think? For a matching proposal for the Generators section please cf. [1]. References: [1]: http://www.ietf.org/mail-archive/web/json/current/msg00689.html [2]: http://www.ietf.org/mail-archive/web/json/current/msg00691.html [3]: http://www.ietf.org/mail-archive/web/json/current/msg00692.html All the best, Stefan From stefan@drees.name Mon Jun 10 00:38:18 2013 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 6189121F894E for ; Mon, 10 Jun 2013 00:38:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.928 X-Spam-Level: X-Spam-Status: No, score=-0.928 tagged_above=-999 required=5 tests=[AWL=-1.093, BAYES_40=-0.185, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hw24KWaNIvCM for ; Mon, 10 Jun 2013 00:38:13 -0700 (PDT) Received: from mout.web.de (mout.web.de [212.227.15.4]) by ietfa.amsl.com (Postfix) with ESMTP id 2C85321F8AF4 for ; Mon, 10 Jun 2013 00:38:12 -0700 (PDT) Received: from newyork.local.box ([93.129.126.10]) by smtp.web.de (mrweb001) with ESMTPSA (Nemesis) id 0LtX9Q-1UKPvr0CqS-010uk7 for ; Mon, 10 Jun 2013 09:38:11 +0200 Message-ID: <51B58261.5040808@drees.name> Date: Mon, 10 Jun 2013 09:38:09 +0200 From: Stefan Drees User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "json@ietf.org" Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:pDAnYrBQavM428wL5vywJF9Ul7DMI3EkycpHyeNNGrljjG/HhW8 kgi3mSax3AyizC0XZ9aAgyASBjYH3HvcSn/cxp10kUptWnifMPexJs2FdMSJ8mrc5HO9AA1 /aw+i1kPzwrpGEjytfH3EVgl0o2fAPnxJvi/9mTAd1J5hobgDMM5eruoSbvqDtBTDpGWuRw yLbP8Fi+VMhRmaqG2BFeQ== Subject: [Json] Generators X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stefan@drees.name List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jun 2013 07:38:18 -0000 Starting this also as a new thread to not break symmetry (Parsers have been forked already by Paul). Starting from my last proposal before fork at [1] I hereby propose to change the section on Generators from the OLD: """ 5. Generators A JSON generator produces JSON text. The resulting text MUST strictly conform to the JSON grammar. """ into the NEW: """ 5. Generators A JSON generator produces JSON text that MUST strictly conform to the JSON grammar. Generators MUST NOT duplicate names in objects if they can avoid or detect such duplication. """ This is intended to be "flanked" by the proposal in the sister thread cf. [2]. As compared to [1] in the above proposal I have replaced the ". The resulting text" with a simple and equivalent " that" as compared to [1] and also threw a fine grained MUST into the ring pairing well, with the one in the Parsers section [2]. This "MUST NOT duplicate ... if" reads pretty soft for implementers, but should be the only consensual non-breaking way out of the historical dilemma of not enforcing it for generators in the first place. What do the others think? References: [1]: http://www.ietf.org/mail-archive/web/json/current/msg00689.html [2]: http://www.ietf.org/mail-archive/web/json/current/msg00700.html All the best, Stefan. From markus.lanthaler@gmx.net Mon Jun 10 02:49:12 2013 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 D014C21F888F for ; Mon, 10 Jun 2013 02:49:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.15 X-Spam-Level: X-Spam-Status: No, score=-1.15 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rnmgsqhaw6fD for ; Mon, 10 Jun 2013 02:49:06 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) by ietfa.amsl.com (Postfix) with ESMTP id 6C65021F86FB for ; Mon, 10 Jun 2013 02:49:04 -0700 (PDT) Received: from mailout-de.gmx.net ([10.1.76.32]) by mrigmx.server.lan (mrigmx002) with ESMTP (Nemesis) id 0MJ0dz-1UnuWk1nYH-002V5J for ; Mon, 10 Jun 2013 11:49:03 +0200 Received: (qmail invoked by alias); 10 Jun 2013 09:49:03 -0000 Received: from 84-115-182-43.dynamic.surfer.at (EHLO Vostro3500) [84.115.182.43] by mail.gmx.net (mp032) with SMTP; 10 Jun 2013 11:49:03 +0200 X-Authenticated: #419883 X-Provags-ID: V01U2FsdGVkX18J8y4gegsJ8zovop4qO+qyCZSrviNE8JoRfJoMm3 ZtddqoDDmaYTA+ From: "Markus Lanthaler" To: References: <51B58261.5040808@drees.name> In-Reply-To: <51B58261.5040808@drees.name> Date: Mon, 10 Jun 2013 11:49:02 +0200 Message-ID: <00d201ce65bf$bd7edd50$387c97f0$@lanthaler@gmx.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac5lrXxUICkjXDb4TFGl3omV71ye0AAEblYw Content-Language: de X-Y-GMX-Trusted: 0 Subject: Re: [Json] Generators X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 10 Jun 2013 09:49:12 -0000 On Monday, June 10, 2013 9:38 AM, Stefan Drees wrote: > 5. Generators > > A JSON generator produces JSON text that MUST strictly conform to > the JSON grammar. > > Generators MUST NOT duplicate names in objects if they can avoid or > detect such duplication. > > """ [...] > This "MUST NOT duplicate ... if" reads pretty soft for implementers, > but should be the only consensual non-breaking way out of the > historical dilemma of not enforcing it for generators in the first place. The "if" makes the MUST NOT conditional which is at odds with its definition """ 1. MUST This word, or the terms "REQUIRED" or "SHALL", mean that the definition is an absolute requirement of the specification. """ I would suggest to just drop the if-statement but can see why people would disagree with that. -- Markus Lanthaler @markuslanthaler From w3c@marcosc.com Mon Jun 10 03:10:41 2013 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 11FBF21F8A85 for ; Mon, 10 Jun 2013 03:10:41 -0700 (PDT) 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=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qvj3AAX9KYZR for ; Mon, 10 Jun 2013 03:10:40 -0700 (PDT) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) by ietfa.amsl.com (Postfix) with ESMTP id E6B1221F885A for ; Mon, 10 Jun 2013 03:10:39 -0700 (PDT) Received: by mail-wi0-f179.google.com with SMTP id hj3so542950wib.0 for ; Mon, 10 Jun 2013 03:10:39 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=date:from:to:message-id:in-reply-to:references:subject:x-mailer :mime-version:content-type:content-transfer-encoding :content-disposition:x-gm-message-state; bh=hqAoKx0yjKGWEWovY8V2n0z7DijPLA6bHx/NWLmjoDY=; b=JFPkIUt4YtZCXvldIsN5bVEFLFY4wUP7YlPh4n9hMwFn0lNobif9H91lFs/pQSGZ6P DoBomYf4wJAKDG7zsheH5MfhkL7Z9+CmfZGnyXvJ/TiUn8pge8740ivqUR0QwTh0iDJf ZtsGgmmqQ92BjlIew+idLEn7IT9JUMhS9f3Xk4xtHfEJossMA7JOwWFxNmbC422xXLfh vyKwhs0LZUQ2B7/VqGE9wwpg5HZZ+3+jXGA3wCFMwBnvO+rNzGaD0qly5wZgx1LMFK5t yZbWgaz9pXV8JJ6P/1ddRWEyjtkNpnn38spPjy5Abz2XMkveOXqsJIfdX67YBXYBzjmr KPjg== X-Received: by 10.180.183.40 with SMTP id ej8mr2848208wic.37.1370859038965; Mon, 10 Jun 2013 03:10:38 -0700 (PDT) Received: from [192.168.1.65] (bl11-16-70.dsl.telepac.pt. [85.244.16.70]) by mx.google.com with ESMTPSA id fu14sm10272168wic.0.2013.06.10.03.10.36 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 10 Jun 2013 03:10:38 -0700 (PDT) Date: Mon, 10 Jun 2013 11:10:31 +0100 From: Marcos Caceres To: json@ietf.org Message-ID: <60EAB36FA95E40A180330B3D7F8377F5@marcosc.com> In-Reply-To: <51b5a11d.0881440a.629d.68d4SMTPIN_ADDED_BROKEN@mx.google.com> References: <51B58261.5040808@drees.name> <51b5a11d.0881440a.629d.68d4SMTPIN_ADDED_BROKEN@mx.google.com> X-Mailer: sparrow 1.6.4 (build 1178) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Gm-Message-State: ALoCoQmPcQaf7lwrq5Wa8+v57utFSWHJXfw+j2Beztqs0LO92c4Cru3EnjtUSQo83UPymZSjBJzs Subject: Re: [Json] Generators X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 10 Jun 2013 10:10:41 -0000 On Monday, 10 June 2013 at 10:49, Markus Lanthaler wrote: > On Monday, June 10, 2013 9:38 AM, Stefan Drees wrote: > > 5. Generators > > =20 > > A JSON generator produces JSON text that MUST strictly conform to > > the JSON grammar. > =20 Please try to avoid =22wish list=22 style conformance requirements. If yo= u want =22strictly=22 conforming documents generated (whatever that may m= ean), then please write the algorithm to produce such documents. =46or ex= ample: =22When generating JSON, as JSON generator MUST run the steps to generate= JSON text. The steps to generate JSON text are given by the following algorithm: =20 1. =E2=80=A6 2. =E2=80=A6 =20 =22 > > =20 > > Generators MUST NOT duplicate names in objects if they can avoid or > > detect such duplication. > > =20 > > =22=22=22 > =5B...=5D > > This =22MUST NOT duplicate ... if=22 reads pretty soft for implemente= rs, > > but should be the only consensual non-breaking way out of the > > historical dilemma of not enforcing it for generators in the first pl= ace. > =20 I agree. The above =22if they can avoid =5Bit=5D=22 if pretty lousy spec = text. Please define the algorithm instead to produce the results you want= . =20 =46or excellent examples of how to write a specification using step-based= conformance, please see the ES6 spec. See the parsing algorithm for JSON= here - you basically want a language neutral version of that, right=3F: http://people.mozilla.org/=7Ejorendorff/es6-draft.html=23sec-15.12.2 HTH, =20 Marcos Caceres From cabo@tzi.org Mon Jun 10 03:24:23 2013 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 75DC421F8B35 for ; Mon, 10 Jun 2013 03:24:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.051 X-Spam-Level: X-Spam-Status: No, score=-106.051 tagged_above=-999 required=5 tests=[AWL=0.198, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CQRGeeCmYHW1 for ; Mon, 10 Jun 2013 03:24:12 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id E0FDA21F8916 for ; Mon, 10 Jun 2013 03:24:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r5AAO4sb025752; Mon, 10 Jun 2013 12:24:04 +0200 (CEST) Received: from [192.168.217.105] (p54893267.dip0.t-ipconnect.de [84.137.50.103]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 5B1D53B2C; Mon, 10 Jun 2013 12:24:04 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <60EAB36FA95E40A180330B3D7F8377F5@marcosc.com> Date: Mon, 10 Jun 2013 12:24:01 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <51B58261.5040808@drees.name> <51b5a11d.0881440a.629d.68d4SMTPIN_ADDED_BROKEN@mx.google.com> <60EAB36FA95E40A180330B3D7F8377F5@marcosc.com> To: Marcos Caceres X-Mailer: Apple Mail (2.1508) Cc: json@ietf.org Subject: Re: [Json] Generators X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 10 Jun 2013 10:24:23 -0000 On Jun 10, 2013, at 12:10, Marcos Caceres wrote: > please write the algorithm hixiefy (vt): Make a specification less useful but more apparently "precise" by down-compiling readable English text that makes use of some structure and certain unstated assumptions into barely readable, ambiguous pseudo code based on the same unstated assumptions, but now leaving recognizing the structure as an exercise to the reader. I'm well aware that you sometimes have to give up writing an interoperability specification and instead actually specify an=20 algorithm, but that should be a last resort, never the approach=20 from the outset. > pretty lousy spec text. Yep. Gr=FC=DFe, Carsten From cabo@tzi.org Mon Jun 10 03:27:41 2013 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 77DC621F8477 for ; Mon, 10 Jun 2013 03:27:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.076 X-Spam-Level: X-Spam-Status: No, score=-106.076 tagged_above=-999 required=5 tests=[AWL=0.173, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3D1DpOzsgzAA for ; Mon, 10 Jun 2013 03:27:30 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 4717D21F894E for ; Mon, 10 Jun 2013 03:27:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r5AARMXa002128; Mon, 10 Jun 2013 12:27:22 +0200 (CEST) Received: from [192.168.217.105] (p54893267.dip0.t-ipconnect.de [84.137.50.103]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 109283B35; Mon, 10 Jun 2013 12:27:21 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <014BC561-ECB9-4C82-B759-580025770E58@vpnc.org> Date: Mon, 10 Jun 2013 12:27:20 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <2014F29A-4F38-4E8C-A05C-892F9B06A7E2@tzi.org> References: <20130609042518.11918.qmail@joyce.lan> <51B44197.2000006@drees.name> <014BC561-ECB9-4C82-B759-580025770E58@vpnc.org> To: Paul Hoffman X-Mailer: Apple Mail (2.1508) Cc: "json@ietf.org" Subject: Re: [Json] Description of parsers X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 10 Jun 2013 10:27:41 -0000 On Jun 9, 2013, at 22:38, Paul Hoffman wrote: >> duplicate names in objects That doesn't mean anything, until it has been defined. Is "foofoo" a duplicate name? Or is it just not allowed to write=20 { "foo" "foo" : "bar" } ? Or is it that all maps (objects) must have unique names, so=20 [{"foo": "bar"}, {"foo": "baz"}] is an instance of a duplicate name? Or maybe this is about the names within an object, so {"foo": {"foo": "bar"}} is an instance of a duplicate name? -> Of the name/value pairs that comprise a single object, no two = [shall/should/whatever] have the same name. For the purposes of this comparison, two names are the same if they are = the same sequence of characters after processing the strings (2.5). [RFC 4627 doesn't quite define what that is, either, but one can = complete section 2.5 with common knowledge such as that the quotes = aren't meant to be part of the decoded string.] Gr=FC=DFe, Carsten From stefan@drees.name Mon Jun 10 03:59:20 2013 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 3DF9121F85F7 for ; Mon, 10 Jun 2013 03:59:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.791 X-Spam-Level: X-Spam-Status: No, score=-1.791 tagged_above=-999 required=5 tests=[AWL=-0.142, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_21=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eWi34CinvGkE for ; Mon, 10 Jun 2013 03:59:14 -0700 (PDT) Received: from mout.web.de (mout.web.de [212.227.17.12]) by ietfa.amsl.com (Postfix) with ESMTP id DD2D621F8647 for ; Mon, 10 Jun 2013 03:59:13 -0700 (PDT) Received: from newyork.local.box ([93.129.126.10]) by smtp.web.de (mrweb103) with ESMTPSA (Nemesis) id 0MPpIE-1Ui8C53ErS-004eXD; Mon, 10 Jun 2013 12:59:12 +0200 Message-ID: <51B5B17E.5030706@drees.name> Date: Mon, 10 Jun 2013 12:59:10 +0200 From: Stefan Drees User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Marcos Caceres References: <51B58261.5040808@drees.name> <51b5a11d.0881440a.629d.68d4SMTPIN_ADDED_BROKEN@mx.google.com> <60EAB36FA95E40A180330B3D7F8377F5@marcosc.com> In-Reply-To: <60EAB36FA95E40A180330B3D7F8377F5@marcosc.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Provags-ID: V02:K0:uNWYZlzIl4uZo4WC9EZ4zsR1Ja75vajAe8i7H9APa4j QS0A2h+eu3vUn2XJh6vaoeXEROdk02/sW1yd5y9+KJN2uxGzDP gyQF+vdwu5uTYB/vn9i1ogHYOLob7bP0RYdng94i4deDRJUOmP kssK5QWUsuJw/huU9mA1oxCYq4OxrdzBJIhNzHqdSlbv5a70n8 3x1KWjF5q7oGy6xVKDyIg== Cc: json@ietf.org Subject: Re: [Json] Generators X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stefan@drees.name List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jun 2013 10:59:20 -0000 On 2013-06-10 12:10 CEST, Marcos Caceres wrote: > On Monday, 10 June 2013 at 10:49, Markus Lanthaler wrote: >> On Monday, June 10, 2013 9:38 AM, Stefan Drees wrote: >>> 5. Generators >>> >>> A JSON generator produces JSON text that MUST strictly conform to >>> the JSON grammar. >> > > Please try to avoid "wish list" style conformance requirements. If you > want "strictly" conforming documents generated (whatever that may mean), > then please write the algorithm to produce such documents. For example: > > "When generating JSON, as JSON generator MUST run the steps to generate JSON text. > > The steps to generate JSON text are given by the following algorithm: > 1. … > 2. … > " if I only once had the power to write my wish lists that strong and concise, I would be a very happy man I guess :-) We will not have a conformance section and we had until now no step by step description but only an "integral" check, where the result had to conform to the ABNF grammar of JSON. So the following message is the best we can state: If you are a wannabe X generator, ensure your output strictly conforms to our X grammar. Retro-inventing of stepwise solutions/recipes simply not having been around for all these years and then acting as if they had, to me personally gives a strong smell and is far off the charter, isn't it? >>> >>> Generators MUST NOT duplicate names in objects if they can avoid or >>> detect such duplication. >>> >>> """ >> [...] >>> This "MUST NOT duplicate ... if" reads pretty soft for implementers, >>> but should be the only consensual non-breaking way out of the >>> historical dilemma of not enforcing it for generators in the first place. >> > > I agree. The above "if they can avoid [it]" if pretty lousy spec text. > Please define the algorithm instead to produce the results you want. I might be tempted to change the sequence to a more natural looking one "detect before avoid" but then, if an implementation is not able to avoid it, why should it bother to detect or not detect? So the strongest excemption is noted first: A policy or a use case hinders me in ensuring the "uniqueness wish" for names in objects. On a personal note: If we avoid wordings like "pretty lousy spec text" in situations where many people are trying to retrofit best possible constraints into an area where these completely missed for years, to avoid further future "leakage" and without breaking reality that would be surely helpful, wouldn't it? So IMO the terrain for the pair Generators/Parsers has three main boundary conditions: a) the solutions for the generator / parser pair must match w.r.t. chaining the MUST/SHOULD/MAYs of each. b) the generator in reality always transforms some storage pattern (JSON RFC is agnostic of that!) into a JSON text conforming to our JSON ABNF. Thus, the Generator has not to deal with invalid "input": piece of cake :-) c) the parser in reality always transforms some JSON text into some storage pattern (JSON RFC is agnostic of that!). The parser has to deal with invalid input claiming to be JSON text! in this thread we discuss b) and try to not mess with a). Until now it has already been stated on this list, that in reality (and rightly so): 1. generator A can't detect duplicate names in objects 2. generator B uses duplicate names to annotate values with comments 3. generator C uses duplicate names to somehow stream, send historical data or deltas. Given that A, B and C all are valid JSON implementations of Generators we will not retro-invalidate them. In that light, the above MUST NOT ... if (describe the known exceptions) approximates best at least IMO the many variants proposed. > > For excellent examples of how to write a specification using > step-based conformance, please see the ES6 spec. See the parsing > algorithm for JSON here - you basically want a language neutral version > of that, right?: > > http://people.mozilla.org/~jorendorff/es6-draft.html#sec-15.12.2 ... Thank you for this nice description of the steps that a specific languages JSON Parser will have to perform to conform to that language specification. No, I think we do not want a language neutral version of the JSON.Parse description in ES6. Yes, we do want ES6s JSON expectations to remain valid if they were before, but we do not have a mandate to re-invent a step by step JSON Generator (or Parser) recipe, as that would need to be checked against all valid (as of now) implementation recipes of all existing parsers and would blow up this nice little successfull super star RFC quite a bit or two ;-) All the best, Stefan. From stefan@drees.name Mon Jun 10 04:27:00 2013 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 DE29421F86FB for ; Mon, 10 Jun 2013 04:26:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.086 X-Spam-Level: X-Spam-Status: No, score=-2.086 tagged_above=-999 required=5 tests=[AWL=0.163, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uzJHQpCt2ihR for ; Mon, 10 Jun 2013 04:26:54 -0700 (PDT) Received: from mout.web.de (mout.web.de [212.227.15.14]) by ietfa.amsl.com (Postfix) with ESMTP id 6E00421F8717 for ; Mon, 10 Jun 2013 04:26:52 -0700 (PDT) Received: from newyork.local.box ([93.129.126.10]) by smtp.web.de (mrweb103) with ESMTPSA (Nemesis) id 0LlniO-1UCfQd0NXc-00ZsSx; Mon, 10 Jun 2013 13:26:47 +0200 Message-ID: <51B5B7F6.20609@drees.name> Date: Mon, 10 Jun 2013 13:26:46 +0200 From: Stefan Drees User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Markus Lanthaler References: <51B58261.5040808@drees.name> <00d201ce65bf$bd7edd50$387c97f0$@lanthaler@gmx.net> In-Reply-To: <00d201ce65bf$bd7edd50$387c97f0$@lanthaler@gmx.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V02:K0:mba2uU8mSmeL7a2BmT5ejal/OMPSZ8ByESfzXUH/6Ng qHhZRjLpBt8DHEQzur8J62LrWzRgFueuinfx3FU3UGhQdD5+H1 qNYoGIoNtqLOcZmiCzcYjH1U7KWQNHQle/9WxTwXXIORBSLiVf XSeHGElhN6EifJozj+PLhypS9wZ6YpmsBQaGruKjVJJQWBBouK YzNAGQGFnjwrm3W+PQiDw== Cc: json@ietf.org Subject: Re: [Json] Generators X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stefan@drees.name List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jun 2013 11:27:00 -0000 On 2013-06-10 11:49 CEST, Markus Lanthaler wrote: > On Monday, June 10, 2013 9:38 AM, Stefan Drees wrote: >> 5. Generators >> >> A JSON generator produces JSON text that MUST strictly conform to >> the JSON grammar. >> >> Generators MUST NOT duplicate names in objects if they can avoid or >> detect such duplication. >> >> """ > [...] >> This "MUST NOT duplicate ... if" reads pretty soft for implementers, >> but should be the only consensual non-breaking way out of the >> historical dilemma of not enforcing it for generators in the first place. > > The "if" makes the MUST NOT conditional which is at odds with its definition > > """ > 1. MUST This word, or the terms "REQUIRED" or "SHALL", mean that the > definition is an absolute requirement of the specification. > """ that depends. If we act with care, we have to respect many boundary conditions. One is: There is only one term Generators in the spec we update minimally, but in reality many polarizing use cases drove implementations of such generators into existence (please also cf. [1] esp. where listing some of these and further motivate the concurrently proposed "UPPERCASE lowercase" selection). So the if effectively offers a subclassification we are not allowed to enforce by say inventing a second class citizen like eg. a DupesGenerator ... > I would suggest to just drop the if-statement but can see why people would > disagree with that. ... I personally would really wish to allow for trailing commas in arrays and objects, but our job - as I understand it - is to update the JSON RFC **and** keep the grown ecosystem intact thus defend the RFCs coolness, brevity and embracing functionality for all existing implementations of Generators, Parsers and combinations thereof. Some of these terms may not appear in the charter of the json wg, but might match those actually in there ;-) All the best, Stefan. From w3c@marcosc.com Mon Jun 10 04:28:00 2013 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 993DF21F85BF for ; Mon, 10 Jun 2013 04:27:59 -0700 (PDT) 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=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 07Iso05sLEKg for ; Mon, 10 Jun 2013 04:27:58 -0700 (PDT) Received: from mail-we0-x234.google.com (mail-we0-x234.google.com [IPv6:2a00:1450:400c:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id 89DA621F84A1 for ; Mon, 10 Jun 2013 04:27:58 -0700 (PDT) Received: by mail-we0-f180.google.com with SMTP id w56so4701235wes.39 for ; Mon, 10 Jun 2013 04:27:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=date:from:to:cc:message-id:in-reply-to:references:subject:x-mailer :mime-version:content-type:content-transfer-encoding :content-disposition:x-gm-message-state; bh=DAjRQN8KnVrlNEtzka9IWu/yGr0XFmEWeq2YfkZ60zY=; b=CajAMARhOjYpGQdiaPZ03E7sEB6M+jAPTybN3S1IH7ywDx6uCkC+ezKsbcsaatV8wt CWtsbjBJbje+m2G2FpoG7+u8hsjsSRTU3vdOzvEuXOYEOwK12WcwVSmyeYAl4bcDu01P QTVrZGmpB7e06k7rzU9otWrM5Fy0pIanEiW1axpIdiOj7voCaTs88b9XgzxQFl/d2bcD uPj2F4Rp0wsGf9IIqECINdpn42SFwFuEp9fz5d3DYeO4uFbhj183MVlr07ymz3g47Dvs GTwZOSj6hS9Q/qKACLX1u4VAVhViWKoTTbi8g2MdbgnH8Z6PWzbHrOKO/V5m+R9S4YwV yrtQ== X-Received: by 10.194.158.194 with SMTP id ww2mr5524936wjb.3.1370863677679; Mon, 10 Jun 2013 04:27:57 -0700 (PDT) Received: from [172.16.0.7] (bl11-16-70.dsl.telepac.pt. [85.244.16.70]) by mx.google.com with ESMTPSA id f8sm10433939wiv.0.2013.06.10.04.27.55 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 10 Jun 2013 04:27:56 -0700 (PDT) Date: Mon, 10 Jun 2013 12:27:54 +0100 From: Marcos Caceres To: Carsten Bormann Message-ID: <8BD6412FBAD444A393B55D3CE2D80B00@marcosc.com> In-Reply-To: References: <51B58261.5040808@drees.name> <51b5a11d.0881440a.629d.68d4SMTPIN_ADDED_BROKEN@mx.google.com> <60EAB36FA95E40A180330B3D7F8377F5@marcosc.com> X-Mailer: sparrow 1.6.4 (build 1178) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Gm-Message-State: ALoCoQmDCtiCAkMfmns/ulI4vzMknp6DIGbwRljfUdUI6dGk0UUyw4CSOLzHqPa2huS4tI5v54Ej Cc: json@ietf.org Subject: Re: [Json] Generators X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 10 Jun 2013 11:28:00 -0000 On Monday, June 10, 2013 at 11:24 AM, Carsten Bormann wrote: > On Jun 10, 2013, at 12:10, Marcos Caceres wrote: > > > please write the algorithm > > hixiefy (vt): Personal attacks are not cool. I kindly ask that you refrain from doing that. > Make a specification less useful but more apparently > "precise" by down-compiling readable English text that makes use of > some structure and certain unstated assumptions into barely readable, > ambiguous pseudo code based on the same unstated assumptions, but now > leaving recognizing the structure as an exercise to the reader. This was not what I was suggesting. It's why I pointed to ES6. It's algorithms are very clear and easy to follow for implementers. If you haven't already, I encourage you to read some ES6 - it's actually quite a delight to read and follow along to, even for someone that is not an expert (and certainly does not exhibit the language issues you mentioned above). Having said that, yes, the HTML5 spec is hard to read in places, but I would not blame any one individual for that - HTML5 is a very complex system that was specified from the messy organic growth of the Web: trying to standardize it with English is hard, but at least we have something that works fairly well now across user agent. > I'm well aware that you sometimes have to give up writing an > interoperability specification and instead actually specify an > algorithm, but that should be a last resort, never the approach > from the outset. I don't understand? the end result of these specifications is code in some system (i.e., all specs are "interoperability specifications"). We want the code to be the same no matter what system it is run in (i.e., interoperable). Having a list of steps provides clear guidance for people to follow, and lets the implementer know exactly where and how to apply error handling (e.g., in the case of duplicate property names). It also helps users (developers) understand what is going on inside the system*. Having clear steps also allows for the creation of a more precise test suite: one can write a test for each step in the algorithm - thus getting more precise specification verification. *Having said that, it is not a requirement that implementers follow the specification as the algorithm is written - so long as the end result is indistinguishable from that which would be achieved by following a given algorithm. -- Marcos Caceres From stefan@drees.name Mon Jun 10 04:30:29 2013 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 8410821F8900 for ; Mon, 10 Jun 2013 04:30:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.092 X-Spam-Level: X-Spam-Status: No, score=-2.092 tagged_above=-999 required=5 tests=[AWL=0.157, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QkgUwBGxHL6Q for ; Mon, 10 Jun 2013 04:30:24 -0700 (PDT) Received: from mout.web.de (mout.web.de [212.227.15.14]) by ietfa.amsl.com (Postfix) with ESMTP id 8D16A21F88AC for ; Mon, 10 Jun 2013 04:30:23 -0700 (PDT) Received: from newyork.local.box ([93.129.126.10]) by smtp.web.de (mrweb003) with ESMTPSA (Nemesis) id 0McFQF-1V2qzq2guV-00JRcl; Mon, 10 Jun 2013 13:30:21 +0200 Message-ID: <51B5B8CD.5090105@drees.name> Date: Mon, 10 Jun 2013 13:30:21 +0200 From: Stefan Drees User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Markus Lanthaler References: <51B58261.5040808@drees.name> <00d201ce65bf$bd7edd50$387c97f0$@lanthaler@gmx.net> <51B5B7F6.20609@drees.name> In-Reply-To: <51B5B7F6.20609@drees.name> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V02:K0:R3+qfzcpz0Ok5wb1hbMDALe32XUMbBK+DTNGnokxPD/ KCXqjLY/h10FgWbAJWO1StCe5Xge6apLwnLppGtPcQ2t/8Zw8N EVMwidKBRv2ZGAyB2cfJ2Z/DU0m/ll2QxE6xGgKOIZdgRa59ia wzAc9mtvux3LgikXraP1yEkR5tKwN5RqPBeU8P3N2Ja3d5ePp+ tujF+ARi+BqlgUTD70Bbg== Cc: json@ietf.org Subject: Re: [Json] Generators X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stefan@drees.name List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jun 2013 11:30:30 -0000 Sorry, waited for the URL to be defined by IETF mail archiving, but then eventually hit send before entering the reference mentioned in the message below. Now here it is: References: [1]: http://www.ietf.org/mail-archive/web/json/current/msg00706.html Stefan. Am 10.06.13 13:26, schrieb Stefan Drees: > On 2013-06-10 11:49 CEST, Markus Lanthaler wrote: >> On Monday, June 10, 2013 9:38 AM, Stefan Drees wrote: >>> 5. Generators >>> >>> A JSON generator produces JSON text that MUST strictly conform to >>> the JSON grammar. >>> >>> Generators MUST NOT duplicate names in objects if they can avoid or >>> detect such duplication. >>> >>> """ >> [...] >>> This "MUST NOT duplicate ... if" reads pretty soft for implementers, >>> but should be the only consensual non-breaking way out of the >>> historical dilemma of not enforcing it for generators in the first >>> place. >> >> The "if" makes the MUST NOT conditional which is at odds with its >> definition >> >> """ >> 1. MUST This word, or the terms "REQUIRED" or "SHALL", mean that the >> definition is an absolute requirement of the specification. >> """ > > that depends. If we act with care, we have to respect many boundary > conditions. One is: There is only one term Generators in the spec we > update minimally, but in reality many polarizing use cases drove > implementations of such generators into existence (please also cf. [1] > esp. where listing some of these and further motivate the concurrently > proposed "UPPERCASE lowercase" selection). > So the if effectively offers a subclassification we are not allowed to > enforce by say inventing a second class citizen like eg. a > DupesGenerator ... > >> I would suggest to just drop the if-statement but can see why people >> would >> disagree with that. ... > > I personally would really wish to allow for trailing commas in arrays > and objects, but our job - as I understand it - is to update the JSON > RFC **and** keep the grown ecosystem intact thus defend the RFCs > coolness, brevity and embracing functionality for all existing > implementations of Generators, Parsers and combinations thereof. Some of > these terms may not appear in the charter of the json wg, but might > match those actually in there ;-) ... From stefan@drees.name Mon Jun 10 04:56:22 2013 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 A50AE21F8F29 for ; Mon, 10 Jun 2013 04:56:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.797 X-Spam-Level: X-Spam-Status: No, score=-1.797 tagged_above=-999 required=5 tests=[AWL=-0.148, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_14=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qUTrWbr5+ZB6 for ; Mon, 10 Jun 2013 04:56:16 -0700 (PDT) Received: from mout.web.de (mout.web.de [212.227.15.4]) by ietfa.amsl.com (Postfix) with ESMTP id A8CD821F8647 for ; Mon, 10 Jun 2013 04:56:13 -0700 (PDT) Received: from newyork.local.box ([93.129.126.10]) by smtp.web.de (mrweb004) with ESMTPSA (Nemesis) id 0M4lkz-1UQjp92N6T-00yz5Q; Mon, 10 Jun 2013 13:56:11 +0200 Message-ID: <51B5BED9.3030308@drees.name> Date: Mon, 10 Jun 2013 13:56:09 +0200 From: Stefan Drees User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Carsten Bormann References: <20130609042518.11918.qmail@joyce.lan> <51B44197.2000006@drees.name> <014BC561-ECB9-4C82-B759-580025770E58@vpnc.org> <2014F29A-4F38-4E8C-A05C-892F9B06A7E2@tzi.org> In-Reply-To: <2014F29A-4F38-4E8C-A05C-892F9B06A7E2@tzi.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:YLPfFOPn0OEJX2GqXnygCphnRzvBbckkI7kJpfTFqMk+UcW163W 21btAl3u0izZxtaFZhVGomr0WpbXXh/JNwslHN1hKp6NPG3tqVs3x9ZRNubpdSxGMmIvEN6 X3TJAnt+9RzvehCxeksTzMseXiaPU4uzhx+VMIrH2wwy+xPsw1LKElv/1dtUe7Z6MQm5Jdi l8zpBjgx1wZ01Jf1xx58Q== Cc: Paul Hoffman , "json@ietf.org" Subject: Re: [Json] Description of parsers X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stefan@drees.name List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jun 2013 11:56:22 -0000 On 2013-06-10 12:27 CEST, Carsten Bormann wrote: > On Jun 9, 2013, at 22:38, Paul Hoffman ... wrote: > >>> duplicate names in objects > > That doesn't mean anything, until it has been defined. I think here the contxt is confined to parsers and is a summarizing description with focus on the parsers. I understand the job of the section 2 to introduce the vocabulary. So the name is the first part of the ordered pair (name, value). > > Is "foofoo" a duplicate name? not in itself, but maybe if some other "foofoo" in the same object and nesting level comes along or preceeded it. > > Or is it just not allowed to write > { "foo" "foo" : "bar" } > ? here the parser is already out, as this is invalid JSON. > Or is it that all maps (objects) must have unique names, so > [{"foo": "bar"}, {"foo": "baz"}] > is an instance of a duplicate name? we should talk about names of a single object and nesting level. So no. > Or maybe this is about the names within an object, so > {"foo": {"foo": "bar"}} > is an instance of a duplicate name? No. ditto. > -> > Of the name/value pairs that comprise a single object, no two > [shall/should/whatever] have the same name. > For the purposes of this comparison, two names are the same if they > are the same sequence of characters after processing the strings (2.5). As long as we do not "invent" something, but are all sure, that the "common" knowledge where it fills a real gap has also been "shared by all known implementers" knowledge :-) ... > [RFC 4627 doesn't quite define what that is, either, but one can > complete section 2.5 with common knowledge such as that the quotes > aren't meant to be part of the decoded string.] ... How do the existing validators and parsers decide that {"a" "a":"b"} is invalid maybe the ABNF rules :-?) """ object = begin-object [ member *( value-separator member ) ] end-object member = string name-separator value [...] string = quotation-mark *char quotation-mark char = unescaped / escape ( %x22 / ; " quotation mark U+0022 %x5C / ; \ reverse solidus U+005C %x2F / ; / solidus U+002F %x62 / ; b backspace U+0008 %x66 / ; f form feed U+000C %x6E / ; n line feed U+000A %x72 / ; r carriage return U+000D %x74 / ; t tab U+0009 %x75 4HEXDIG ) ; uXXXX U+XXXX escape = %x5C ; \ quotation-mark = %x22 ; " unescaped = %x20-21 / %x23-5B / %x5D-10FFFF """ where "a" "a" seems not to match the rule for a string in rule member. All the best, Stefan. From w3c@marcosc.com Mon Jun 10 05:45:24 2013 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 B2F3D21F894E for ; Mon, 10 Jun 2013 05:45:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_21=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hUKyD8UsFXZy for ; Mon, 10 Jun 2013 05:45:23 -0700 (PDT) Received: from mail-wg0-x232.google.com (mail-wg0-x232.google.com [IPv6:2a00:1450:400c:c00::232]) by ietfa.amsl.com (Postfix) with ESMTP id 1C58C21F8FB3 for ; Mon, 10 Jun 2013 05:21:23 -0700 (PDT) Received: by mail-wg0-f50.google.com with SMTP id k13so4790617wgh.17 for ; Mon, 10 Jun 2013 05:20:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=date:from:to:cc:message-id:in-reply-to:references:subject:x-mailer :mime-version:content-type:content-transfer-encoding :content-disposition:x-gm-message-state; bh=FCJL8VunuTNSlfq23HmNTyEw0lWXLIA9AUW5zHfdRIE=; b=S7RVA2FImrbpZr+vTZ2CBJPDbRCGJtWT439F9BA4j4F56vr14k2E70YteUuhVyBG4A iG4kUaBC6tq7+LUL7ryb65k65UlzDqkyEOL4K3pWc0KscOnxkk+qwRLyl+3w1CFCfKzF Q2XZRi5fMzQE1vCgscYKNlcxPRDaUioMkTprQQeNZRGfcnNSfl4VL9gyoGNovZZN1znA 23nFP+DkN554Gl8MAO6Q1Gt+thRJvRlNqvAnSPmMEKDuY+Fh421yHc9HFVEoR28kK7TK wjQykWz8S0efbV3Jh6bRyIs7FISvyITvRuw+UdBFZgSxeC0ABBKX5G5O7ca7tqoTUAZ6 pkqg== X-Received: by 10.180.14.199 with SMTP id r7mr4583289wic.6.1370866848142; Mon, 10 Jun 2013 05:20:48 -0700 (PDT) Received: from [172.16.0.7] (bl11-16-70.dsl.telepac.pt. [85.244.16.70]) by mx.google.com with ESMTPSA id dj7sm11141696wib.6.2013.06.10.05.20.46 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 10 Jun 2013 05:20:47 -0700 (PDT) Date: Mon, 10 Jun 2013 13:20:44 +0100 From: Marcos Caceres To: stefan@drees.name Message-ID: In-Reply-To: <51B5B17E.5030706@drees.name> References: <51B58261.5040808@drees.name> <51b5a11d.0881440a.629d.68d4SMTPIN_ADDED_BROKEN@mx.google.com> <60EAB36FA95E40A180330B3D7F8377F5@marcosc.com> <51B5B17E.5030706@drees.name> X-Mailer: sparrow 1.6.4 (build 1178) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Gm-Message-State: ALoCoQka6hsIJGwOZ3dEuqW+dZeFOxBWgSr7nP65cLtfhEL2d/WaS5wR9cXuNWO1nCrmU777u+Rl Cc: json@ietf.org Subject: Re: [Json] Generators X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 10 Jun 2013 12:45:24 -0000 Hi Stefan, =20 On Monday, June 10, 2013 at 11:59 AM, Stefan Drees wrote: > On 2013-06-10 12:10 CEST, Marcos Caceres wrote: > > On Monday, 10 June 2013 at 10:49, Markus Lanthaler wrote: > > > On Monday, June 10, 2013 9:38 AM, Stefan Drees wrote: > > > > 5. Generators > > > > =20 > > > > A JSON generator produces JSON text that MUST strictly conform to= > > > > the JSON grammar. > > > =20 > > =20 > > =20 > > =20 > > Please try to avoid =22wish list=22 style conformance requirements. I= f you > > want =22strictly=22 conforming documents generated (whatever that may= mean), > > then please write the algorithm to produce such documents. =46or exam= ple: > > =20 > > =22When generating JSON, as JSON generator MUST run the steps to gene= rate JSON text. > > =20 > > The steps to generate JSON text are given by the following algorithm:= > > 1. =E2=80=A6 > > 2. =E2=80=A6 > > =22 > =20 > =20 > =20 > if I only once had the power to write my wish lists that strong and =20 > concise, I would be a very happy man I guess :-) > =20 > We will not have a conformance section and we had until now no step by = =20 > step description but only an =22integral=22 check, where the result had= to =20 > conform to the ABN=46 grammar of JSON. > So the following message is the best we can state: > If you are a wannabe X generator, ensure your output strictly conforms = =20 > to our X grammar. > =20 > Retro-inventing of stepwise solutions/recipes simply not having been =20 > around for all these years and then acting as if they had, to me =20 > personally gives a strong smell and is far off the charter, isn't it=3F= I haven't read the charter, tbh =E2=80=A6 I literally stumbled onto this = list yesterday :) However, I'm worried that overly simplistic or optimis= tic conformance requirements will just force people to go and look at ES6= to actually write the parsing and generation algorithms (or worst, they = will just find some other random implementation out there and copy that).= That could greatly diminish the value of this specification as it will l= eave implementers scratching their heads about how to implement either a = parser or a generator. =20 Also, given the legacy of JSON, it should be possible to see which parser= behavior =22won=22 (e.g., Doug's original JSON.js=3F) - and model this s= pec off that. =20 Additionally, I suspect few people actually implement an ABN=46 parser - = whatever is expressed in ABN=46 will have to be translated into code for = a specific implementation. You can essentially shortcut that by specifyin= g the algorithm and making implementer's lives easier. That's not to say= that the ABN=46 should not be there (it helps the reader understand comp= onents of the JSON grammar) - but the reality of the situation should be = acknowledged (ABN=46 is an editorial aid, but rarely, A=46AIK, a tool use= d in implementations in it's pure form to do syntactical checking). =20 =20 > > > > Generators MUST NOT duplicate names in objects if they can avoid = or > > > > detect such duplication. > > > > =20 > > > > =22=22=22 > > > =5B...=5D > > > > This =22MUST NOT duplicate ... if=22 reads pretty soft for implem= enters, > > > > but should be the only consensual non-breaking way out of the > > > > historical dilemma of not enforcing it for generators in the firs= t place. > > > =20 > > =20 > > =20 > > =20 > > I agree. The above =22if they can avoid =5Bit=5D=22 if pretty lousy s= pec text. > > Please define the algorithm instead to produce the results you want. > =20 > =20 > =20 > I might be tempted to change the sequence to a more natural looking one= =20 > =22detect before avoid=22 but then, if an implementation is not able to= =20 > avoid it, why should it bother to detect or not detect=3F So the strong= est =20 > excemption is noted first: A policy or a use case hinders me in ensurin= g =20 > the =22uniqueness wish=22 for names in objects. > =20 > On a personal note: If we avoid wordings like =22pretty lousy spec text= =22 =20 > in situations where many people are trying to retrofit best possible =20 > constraints into an area where these completely missed for years, to =20 > avoid further future =22leakage=22 and without breaking reality that wo= uld =20 > be surely helpful, wouldn't it=3F Yes, I'm sorry; I didn't mean any offense. I just meant that it was a con= ditional MUST, and that's not how MUST should be used (as it means one pa= rser can do one thing and another can do another thing =E2=80=A6 which is= an interoperability anti-pattern). This would, obviously, be bad if I'm = sending one JSON representation from the client and it gets transformed i= nto a different one on the server and the spec says that this behavior is= ok. =20 On the other hand, if the spec has to say, =22well, that's the reality ri= ght now=E2=80=A6 and here are some guidance on how to avoid that problem = without breaking clients and servers:=22 that might have to do. =20 > So IMO the terrain for the pair Generators/Parsers has three main =20 > boundary conditions: > =20 > a) the solutions for the generator / parser pair must match w.r.t. > chaining the MUST/SHOULD/MAYs of each. > =20 > b) the generator in reality always transforms some storage pattern > (JSON R=46C is agnostic of that=21) into a JSON text conforming to > our JSON ABN=46. Thus, the Generator has not to deal with invalid > =22input=22: piece of cake :-) > =20 > c) the parser in reality always transforms some JSON text into some > storage pattern (JSON R=46C is agnostic of that=21). The parser has to > deal with invalid input claiming to be JSON text=21 > =20 > in this thread we discuss b) and try to not mess with a). > =20 > Until now it has already been stated on this list, that in reality (and= =20 > rightly so): > =20 > 1. generator A can't detect duplicate names in objects > =20 > 2. generator B uses duplicate names to annotate values with comments > =20 > 3. generator C uses duplicate names to somehow stream, send historical > data or deltas. > =20 > Given that A, B and C all are valid JSON implementations of Generators = =20 > we will not retro-invalidate them. Agree. Whatever is specified needs to be backwards compatible on the pars= er side. Perhaps it's futile to assume a =22generator=22, because most of= the time it's people who are writing JSON by hand (so it doesn't make an= y sense to use R=46C2119 language relating to any =22generator=22 because= people can't be a conformance class). Best you can do with generators is= to assume some =22best practice=22 acknowledging that JSON is used in th= e scenarios A, B, C, and possibly others to help dictate the behavior of = the parser. =20 > In that light, the above MUST NOT ... if (describe the known exceptions= ) =20 > approximates best at least IMO the many variants proposed. Thanks for the context. It's indeed a tough one :) =20 > > =46or excellent examples of how to write a specification using > > step-based conformance, please see the ES6 spec. See the parsing > > algorithm for JSON here - you basically want a language neutral versi= on > > of that, right=3F: > > =20 > > http://people.mozilla.org/=7Ejorendorff/es6-draft.html=23sec-15.12.2 = ... > =20 > Thank you for this nice description of the steps that a specific =20 > languages JSON Parser will have to perform to conform to that language = =20 > specification. > =20 > No, I think we do not want a language neutral version of the JSON.Parse= =20 > description in ES6. > =20 > Yes, we do want ES6s JSON expectations to remain valid if they were =20 > before, but we do not have a mandate to re-invent a step by step JSON =20 > Generator (or Parser) recipe, as that would need to be checked against = =20 > all valid (as of now) implementation recipes of all existing parsers an= d =20 > would blow up this nice little successfull super star R=46C quite a bit= or =20 > two ;-) Ok, looks like I need to find the charter. However, concerns about the si= ze of the spec should not ever enter the discussion - if it needs to be a= long, bloated spec, to achieve interoperability and clarity - then that = is the =22right thing to do=22 (tm)=E2=80=A6 or, put another way, please = make the spec only as long as it needs to be to achieve interoperability = and the goals, and no longer :) =20 From cabo@tzi.org Mon Jun 10 05:45:46 2013 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 EDD2921F8265 for ; Mon, 10 Jun 2013 05:45:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.095 X-Spam-Level: X-Spam-Status: No, score=-106.095 tagged_above=-999 required=5 tests=[AWL=0.154, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JDQZ4eGVBJTF for ; Mon, 10 Jun 2013 05:45:39 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 12C2421F8EAE for ; Mon, 10 Jun 2013 05:27:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r5ACQVFB028309; Mon, 10 Jun 2013 14:26:31 +0200 (CEST) Received: from [192.168.217.105] (p54893267.dip0.t-ipconnect.de [84.137.50.103]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 32F883C77; Mon, 10 Jun 2013 14:26:31 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <8BD6412FBAD444A393B55D3CE2D80B00@marcosc.com> Date: Mon, 10 Jun 2013 14:26:30 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <51B58261.5040808@drees.name> <51b5a11d.0881440a.629d.68d4SMTPIN_ADDED_BROKEN@mx.google.com> <60EAB36FA95E40A180330B3D7F8377F5@marcosc.com> <8BD6412FBAD444A393B55D3CE2D80B00@marcosc.com> To: Marcos Caceres X-Mailer: Apple Mail (2.1508) Cc: json@ietf.org Subject: Re: [Json] Generators X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 10 Jun 2013 12:45:46 -0000 I apologize for what can be read as a cheap shot. ECMAscript actually is a demonstration that you can write a quite useful = specification in this way, and I can say that I have always enjoyed = reading it, even if some of it is pretty much a puzzle that needs to be = solved before you can derive some of the simplest properties (maybe I = just enjoy programming puzzles :-). However, JavaScript is a procedural programming language, so specifying = its behavior in English-language pseudo-code is at least natural. = (Also, the ECMAscript editors are much less guilty of unspecified = assumptions than I have seen in other places.) It is not the natural mode for specifying a data interchange format. > I don't understand? the end result of these specifications is code in = some system (i.e., all specs are "interoperability specifications"). We = want the code to be the same Actually, no. > no matter what system it is run in (i.e., interoperable). That is the one we want. > Having a list of steps provides clear guidance for people to follow, = and lets the implementer know exactly where and how to apply error = handling (e.g., in the case of duplicate property names). It also helps = users (developers) understand what is going on inside the system*.=20 This almost always leads to overspecification, combined with = underexplanation with respect to the reasons why some path was chosen = and not another, and what choices are actually available. Keeping that = knowledge behind closed doors in the committee, and only delivering the = equivalent of compiled code, is also one of the major kinds of = misconduct in standardization work. > Having clear steps also allows for the creation of a more precise test = suite: one can write a test for each step in the algorithm - thus = getting more precise specification verification.=20 That works if those steps are actually exposed, in which case there may = be even more overspecification. > *Having said that, it is not a requirement that implementers follow = the specification as the algorithm is written - so long as the end = result is indistinguishable from that which would be achieved by = following a given algorithm.=20 Comparing two algorithms is much harder (even for humans) than checking = an implementation against assertions. Even more so if one of them is written in English, so it cannot even be = executed unambiguously. Don't get me wrong: Adding a pseudocode example can do a lot to aid = understanding (and to disambiguate poorly worded assertions). However, = turning English language pseudocode into the default mode of explaining = things is a major mistake (and going full FDT is almost always worse, = except for small elements such as ABNF). I'm not going to repeat what = can be read as another copy of the cheap shot (and even implicitly = blaming a single person for such an outcome is always wrong, mea culpa), = but I think you are well aware what might count as exhibit A. Let's not = go there. Douglas' tight prose in RFC 4627 is actually something I would recommend = to emulate. The "ambiguities" we are discussing are either the result of very = "creative" use or were left in deliberately (SHOULD...). That's why I'm a bit unhappy that we seem to have started wordsmithing = before getting some of the decisions done. Gr=FC=DFe, Carsten From dean@deanlandolt.com Mon Jun 10 05:56:16 2013 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 EC84F21F8F4A for ; Mon, 10 Jun 2013 05:56:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.376 X-Spam-Level: X-Spam-Status: No, score=-1.376 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_45=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cVaHIs+wnnWS for ; Mon, 10 Jun 2013 05:56:09 -0700 (PDT) Received: from mail-pd0-f171.google.com (mail-pd0-f171.google.com [209.85.192.171]) by ietfa.amsl.com (Postfix) with ESMTP id 4CEAC21F881F for ; Mon, 10 Jun 2013 05:56:08 -0700 (PDT) Received: by mail-pd0-f171.google.com with SMTP id y14so4479673pdi.2 for ; Mon, 10 Jun 2013 05:56:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=vETk8iP4pGNTL00w+W8gj0sqvX8cYFjv6hO44h/ItzI=; b=h6j0Z3nNnYT0L4cf86gBbGd3GtHUYbJz3a2Sz3SSILd7mFeOr46vKQHksXxXaeAGol fzlc2TeMp7y70dnzaEqaMMWLnpCIXxsG3gXicTdEo8KaF1f9GQYgJfno2/efwQYFoFaM lW6k9bCQUXJh8d+UxF+QcNejUP65UVGJaqxDyJ3q+xKgPUlRUfyI2VRrY2SBIVUVMEaz BCdETvWNr2lUOrBbX+cgrwUZvGgNFtoBSNQSzHZGIIoqEnGTM/uIAMFliUmaRq7EQr6f rSoULYEWXCFfSKS2kD7dl9BOgegJBmeaQGtQTI2wvE5hx0bOSSLa8BNk+qTTdiMaKAVB 97Jg== X-Received: by 10.68.136.230 with SMTP id qd6mr9604479pbb.112.1370868966955; Mon, 10 Jun 2013 05:56:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.70.38.36 with HTTP; Mon, 10 Jun 2013 05:55:25 -0700 (PDT) In-Reply-To: <51B2121B.5080801@crockford.com> References: <51AF8479.5080002@crockford.com> <51AF9ACF.5020507@cisco.com> <51AFB3F8.8060708@crockford.com> <8F32953C-C788-4DC9-888E-920E2BEB7FDD@yahoo.com> <831B8E46-F239-4353-8F95-8DF3F9BD2E78@yahoo.com> <51AFC924.2030805@crockford.com> <60141305-DCEA-4EC6-9CDF-82B52B13AE91@wirfs-brock.com> <51B20E48.8040109@crockford.com> <944ECA7F-A548-4903-9526-847065066E8E@wirfs-brock.com> <51B2121B.5080801@crockford.com> From: Dean Landolt Date: Mon, 10 Jun 2013 08:55:25 -0400 Message-ID: To: Douglas Crockford Content-Type: multipart/alternative; boundary=047d7b10d0dbcf318404decc4d10 X-Gm-Message-State: ALoCoQmKYSaS57k0pNa4bJHmmC9ANnxjBoZ8iZw+mOnyp1Rod4x9+N4iRz/zoazPty9NyPIHevrd Cc: Allen Wirfs-Brock , Paul Hoffman , "json@ietf.org" Subject: Re: [Json] The names within an object SHOULD be unique. X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 10 Jun 2013 12:56:16 -0000 --047d7b10d0dbcf318404decc4d10 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Jun 7, 2013 at 1:02 PM, Douglas Crockford wrote: > On 6/7/2013 9:59 AM, Allen Wirfs-Brock wrote: > >> On Jun 7, 2013, at 9:46 AM, Douglas Crockford wrote: >> >> On 6/6/2013 8:42 AM, Allen Wirfs-Brock wrote: >>> >>>> Given that duplicate names have historically been valid, that some >>>> people use them, and that the standard ECMAScript JSON parser accepts them >>>> I don't see why allowing a parser to reject duplicate names is helpful. >>>> >>>> >>>> >>>> Because some parsers do so, and have for years. JSON.parse is not the >>> only JSON parser. Our purpose here is not to attempt to fix this thing, >>> because fixing it will break it. There were unfortunately ambiguities in >>> the RFC. If we can, we should remove the ambiguities, but we must do so >>> without changing the meaning of what JSON is. >>> >> I think it is more important to preserve the validity of existing >> archival datasets then it is to preserve the validity of existing parsers >> that throw on duplicate keys. >> >> We should not be invalidating data or programs. We should only be > explaining better. No breakage is acceptable. No breakage. In this case "no breakage" effectively means no hope of interoperability going forward. What, then, is the point of this exercise? To echo AWB's point, I've seen the duplicate-keys-for-comments technique used (and encouraged) by many in the js community for years -- I'm sure there's a large volume of otherwise-valid json out there. This is handled in a variety of ways in the wild -- shouldn't this be a high priority to correct? And all things being equal, programs rot a lot faster than data -- there's no correcting for the mass of historical duplicate-key json. Another possible solution: specify that parsers MUST NOT throw on duplicate keys and recommend omitting duplicate keys entirely. Given history I believe this is the only sane way to handle duplicate keys -- as was noted earlier in this thread they're completely useless after a parse/serialization cycle anyway. This may put some noses out of joint but web reality suggests this is the only robust solution. --047d7b10d0dbcf318404decc4d10 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Fri, Jun 7, 2013 at 1:02 PM, Douglas Crockford <douglas@cro= ckford.com> wrote:
On 6/7/2013 9:59 AM, Allen= Wirfs-Brock wrote:
On Jun 7, 2013, at 9:46 AM, Douglas Crockford wrote:

On 6/6/2013 8:42 AM, Allen Wirfs-Brock wrote:
Given that duplicate names have historically been valid, that some people u= se them, and that the standard ECMAScript JSON parser accepts them I don= 9;t see why allowing a parser to reject duplicate names is helpful.



Because some parsers do so, and have for years. JSON.parse is not the only = JSON parser. Our purpose here is not to attempt to fix this thing, because = fixing it will break it. There were unfortunately ambiguities in the RFC. I= f we can, we should remove the ambiguities, but we must do so without chang= ing the meaning of what JSON is.
I think it is more important to preserve the validity of existing archival = datasets then it is to preserve the validity of existing parsers that throw= on duplicate keys.

We should not be invalidating data or programs. We should only be explainin= g better. No breakage is acceptable. No breakage.


=
In this case "no breakage" effectively means no hope o= f interoperability going forward. What, then, is the point of this exercise= ? To echo AWB's point, I've seen the duplicate-keys-for-comments te= chnique used (and encouraged) by many in the js community for years -- I= 9;m sure there's a large volume of otherwise-valid json out there. This= is handled in a variety of ways in the wild -- shouldn't this be a hig= h priority to correct? And all things being equal, programs rot a lot faste= r than data -- there's no correcting for the mass of historical duplica= te-key json.

Another possible solution: specify that parsers MUST NOT th= row on duplicate keys and recommend omitting duplicate keys entirely. Given= history I believe this is the only sane way to handle duplicate keys -- as= was noted earlier in this thread they're completely useless after a pa= rse/serialization cycle anyway. This may put some noses out of joint but we= b reality suggests this is the only robust solution.
--047d7b10d0dbcf318404decc4d10-- From w3c@marcosc.com Mon Jun 10 06:02:44 2013 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 1E1E021F8EBC for ; Mon, 10 Jun 2013 06:02:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qUtHzIvNmxxC for ; Mon, 10 Jun 2013 06:02:43 -0700 (PDT) Received: from mail-we0-x229.google.com (mail-we0-x229.google.com [IPv6:2a00:1450:400c:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id E20B521F8CB4 for ; Mon, 10 Jun 2013 06:02:42 -0700 (PDT) Received: by mail-we0-f169.google.com with SMTP id n57so4884762wev.14 for ; Mon, 10 Jun 2013 06:02:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=date:from:to:cc:message-id:in-reply-to:references:subject:x-mailer :mime-version:content-type:content-transfer-encoding :content-disposition:x-gm-message-state; bh=oIkjdxbdnCdFiu0zzH5zsN248nlR3JQfKKzNgAVHL9Y=; b=TF+KohIJepRfyI9bV+UqzwI3jZ25l6Pyd4VilvybvyWOjxLTW4nV8O5bu2/95CHkfU 2l5brn7KOv7j8GYQ6zQYd0+eVHIHbltmYTP4alXbuWpDS/fPMctwDTRu1YGET4YmTs4D Jt145mqUYeG6q9l07kItyUW1IkZQjg3HwREc65tFaNboL6l1xWSLzDSvtxQCC1TTOzP0 6jLkqb4jf1G9/W44Ah5oB4brYLz/PV/FrP5UrCmcBUnS0K53tbTZP8tGqOQq2HY8t8Io +4D2kCZvDu0oocFWLHWM7KwDqV1wfXQwhaVc/xZ8Nqu994LkpGsigEpQhOkrIB3Lr5gh Ji6A== X-Received: by 10.180.182.228 with SMTP id eh4mr4544106wic.42.1370869362028; Mon, 10 Jun 2013 06:02:42 -0700 (PDT) Received: from [172.16.0.7] (bl11-16-70.dsl.telepac.pt. [85.244.16.70]) by mx.google.com with ESMTPSA id b19sm11208107wik.10.2013.06.10.06.02.40 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 10 Jun 2013 06:02:41 -0700 (PDT) Date: Mon, 10 Jun 2013 14:02:39 +0100 From: Marcos Caceres To: Carsten Bormann Message-ID: In-Reply-To: References: <51B58261.5040808@drees.name> <51b5a11d.0881440a.629d.68d4SMTPIN_ADDED_BROKEN@mx.google.com> <60EAB36FA95E40A180330B3D7F8377F5@marcosc.com> <8BD6412FBAD444A393B55D3CE2D80B00@marcosc.com> X-Mailer: sparrow 1.6.4 (build 1178) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Gm-Message-State: ALoCoQn3ooKjPXT2MxjETIVODsFDV0YhA7oJU6XBJj0ECQH89qoA7yD0G4g+uocuNsJLcATp6UqB Cc: json@ietf.org Subject: Re: [Json] Generators X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 10 Jun 2013 13:02:44 -0000 On Monday, June 10, 2013 at 1:26 PM, Carsten Bormann wrote: > > Comparing two algorithms is much harder (even for humans) than checking an implementation against assertions. > Even more so if one of them is written in English, so it cannot even be executed unambiguously. Right, but this is why we have test suites - i.e., to provide unambiguous computationally-verifiable testable assertions of what the English is saying. Personally, the primary motivation for me to see the algorithms is so that we can make sure we have a consistent way of testing everything in the spec. In my experience, the algorithms also help identify the gaps - particularly as you try to test and code against them. Yes, this also means having very competent people writing the tests so to make sure edge cases are also captured. > Don't get me wrong: Adding a pseudocode example can do a lot to aid understanding (and to disambiguate poorly worded assertions). However, turning English language pseudocode into the default mode of explaining things is a major mistake (and going full FDT is almost always worse, except for small elements such as ABNF). I'm not going to repeat what can be read as another copy of the cheap shot (and even implicitly blaming a single person for such an outcome is always wrong, mea culpa), but I think you are well aware what might count as exhibit A. Let's not go there. My experience has been different, I admit. I'm mostly involved with specs at the W3C and we exclusively do algorithmic specs. I won't claim that one approach is better than the other, as I can only speak from my personal experience. I've jotted down some of those thoughts here: http://www.w3.org/TR/test-methodology/ > Douglas' tight prose in RFC 4627 is actually something I would recommend to emulate. > The "ambiguities" we are discussing are either the result of very "creative" use or were left in deliberately (SHOULD...). > That's why I'm a bit unhappy that we seem to have started wordsmithing before getting some of the decisions done. You are probably right. Like I said in a previous email, I just joined the list and have no idea at what stage you all are at - but I'm happy to try to help. -- Marcos Caceres From cowan@ccil.org Mon Jun 10 06:23:24 2013 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 5F27321F901F for ; Mon, 10 Jun 2013 06:23:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.374 X-Spam-Level: X-Spam-Status: No, score=-3.374 tagged_above=-999 required=5 tests=[AWL=0.225, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z2pP2THgQhlT for ; Mon, 10 Jun 2013 06:23:11 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id D518721F905F for ; Mon, 10 Jun 2013 06:22:59 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1Um23j-0006Zk-Rw; Mon, 10 Jun 2013 09:22:55 -0400 Date: Mon, 10 Jun 2013 09:22:55 -0400 From: John Cowan To: Marcos Caceres Message-ID: <20130610132255.GA22228@mercury.ccil.org> References: <51B58261.5040808@drees.name> <51b5a11d.0881440a.629d.68d4SMTPIN_ADDED_BROKEN@mx.google.com> <60EAB36FA95E40A180330B3D7F8377F5@marcosc.com> <51B5B17E.5030706@drees.name> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Cc: stefan@drees.name, json@ietf.org Subject: Re: [Json] Generators X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 10 Jun 2013 13:23:24 -0000 Marcos Caceres scripsit: > Yes, I'm sorry; I didn't mean any offense. I just meant that it was > a conditional MUST, and that's not how MUST should be used (as it > means one parser can do one thing and another can do another thing > … which is an interoperability anti-pattern). There are two kinds of conditional MUSTs. A conditional MUST of the form "The program MUST do such-and-such if thus-and-so is true" is perfectly fine. But a conditional of the form "The program MUST do such-and-such if it can", which is what we have here, needs to be rewritten as "The program SHOULD do such-and-such." -- What has four pairs of pants, lives John Cowan in Philadelphia, and it never rains http://www.ccil.org/~cowan but it pours? cowan@ccil.org --Rufus T. Firefly From mamille2@cisco.com Mon Jun 10 06:24:37 2013 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 112DA21F894E for ; Mon, 10 Jun 2013 06:24:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id olO-hYNDtl7M for ; Mon, 10 Jun 2013 06:24:26 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id BE08C21F8F9E for ; Mon, 10 Jun 2013 06:24:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7011; q=dns/txt; s=iport; t=1370870666; x=1372080266; h=from:to:subject:date:message-id:mime-version; bh=8JWch3Kjf1eWPfXH/vbi3mjRaFe8Eket5ANqGdMBh5A=; b=dkgHBesvDmpKJYsGnwjTD09VZne0qQHwcKad7+UcHjv9sgMVal7acHG3 ZChWsg1/gSmUGyyPScdlucQcsrSvHYO+/BqOAOnrAiaQL9XSklcxLDdE+ igVdt88t46vCjxngEAXCMlXptq5HInNBucpU4IB+qb/qb/tngp8LACyLE s=; X-Files: smime.p7s : 4136 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtYFAK/StVGtJXG8/2dsb2JhbABagwl5vkGBAxZtB4IlAQSBCwEqJjAnBBsGh3+ZBaAUjweDN2EDkAGBLJdVgw+CJw X-IronPort-AV: E=Sophos;i="4.87,837,1363132800"; d="p7s'?scan'208";a="220957758" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-4.cisco.com with ESMTP; 10 Jun 2013 13:24:24 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r5ADON0L015975 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 10 Jun 2013 13:24:23 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.24]) by xhc-rcd-x04.cisco.com ([fe80::200:5efe:173.37.183.34%12]) with mapi id 14.02.0318.004; Mon, 10 Jun 2013 08:24:23 -0500 From: "Matt Miller (mamille2)" To: "json@ietf.org" Thread-Topic: State of the Working Group - 2013-06-09 Thread-Index: AQHOZd3SvphjlQTJHkuJdVKabs7nwA== Date: Mon, 10 Jun 2013 13:24:22 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.129.24.59] Content-Type: multipart/signed; boundary="Apple-Mail=_4C250E41-F90C-4DAA-B485-483D91344836"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Subject: [Json] State of the Working Group - 2013-06-09 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 10 Jun 2013 13:24:37 -0000 --Apple-Mail=_4C250E41-F90C-4DAA-B485-483D91344836 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii ello All, We've had a lot of great discussion this week; covering a range of = topics, and into quite a degree of depth. Let's keep it going! However, some of these discussions might have gotten too entangled for = clear discussion, particularly around Unicode. The chairs might be = asking for summaries or recaps on these topics, to see if there is some = clarity. We just want to make sure we're all on the same page as we = continue the discussions. While the chairs feel we are still some time away from making any = consensus calls, there are a few things that look to be very close. To = that end, Paul and/or myself will be asking for last-chance proposals on = some specific topics, including the current proposals for those topics. = This in no way means discussion is done; it is merely a nudging for = anyone that might have further additions or tweaks. Thank you, Matt Miller and Paul Hoffman --Apple-Mail=_4C250E41-F90C-4DAA-B485-483D91344836 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMezCCBjQw ggQcoAMCAQICAR4wDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDE1NVoX DTE3MTAyNDIxMDE1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMcJg8zOLdgasSmkLhOrlr6KMoOMpohBllVHrdRvEg/q6r8jR+EK 75xCGhR8ToREoqe7zM9/UnC6TS2y9UKTpT1v7RSMzR0t6ndl0TWBuUr/UXBhPk+Kmy7bI4yW4urC +y7P3/1/X7U8ocb8VpH/Clt+4iq7nirMcNh6qJR+xjOhV+VHzQMALuGYn5KZmc1NbJQYclsGkDxD z2UbFqE2+6vIZoL+jb9x4Pa5gNf1TwSDkOkikZB1xtB4ZqtXThaABSONdfmv/Z1pua3FYxnCFmdr /+N2JLKutIxMYqQOJebr/f/h5t95m4JgrM3Y/w7YX9d7YAL9jvN4SydHsU6n65cCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRTcu2SnODaywFc fH6WNU7y1LhRgjAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBAAqDCH14qywG XLhjjF6uHLkjd02hcdh9hrw+VUsv+q1eeQWB21jWj3kJ96AUlPCoEGZ/ynJNScWy6QMVQjbbMXlt UfO4n4bGGdKo3awPWp61tjAFgraLJgDk+DsSvUD6EowjMTNx25GQgyYJ5RPIzKKR9tQW8gGK+2+R HxkUCTbYFnL6kl8Ch507rUdPPipJ9CgJFws3kDS3gOS5WFMxcjO5DwKfKSETEPrHh7p5shuuNktv sv6hxHTLhiMKX893gxdT3XLS9OKmCv87vkINQcNEcIIoFWbP9HORz9v3vQwR4e3ksLc2JZOAFK+s sS5XMEoznzpihEP0PLc4dCBYjbvSD7kxgDwZ+Aj8Q9PkbvE9sIPP7ON0fz095HdThKjiVJe6vofq +n6b1NBc8XdrQvBmunwxD5nvtTW4vtN6VY7mUCmxsCieuoBJ9OlqmsVWQvifIYf40dJPZkk9YgGT zWLpXDSfLSplbY2LL9C9U0ptvjcDjefLTvqSFc7tw1sEhF0n/qpA2r0GpvkLRDmcSwVyPvmjFBGq Up/pNy8ZuPGQmHwFi2/14+xeSUDG2bwnsYJQG2EdJCB6luQ57GEnTA/yKZSTKI8dDQa8Sd3zfXb1 9mOgSF0bBdXbuKhEpuP9wirslFe6fQ1t5j5R0xi72MZ8ikMu1RQZKCyDbMwazlHiMIIGPzCCBSeg AwIBAgIDBoRIMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcN MTMwNDMwMjE1NDQyWhcNMTQwNTAyMDUzOTA0WjBbMRkwFwYDVQQNExBiN2F6NndOY0t0R3JtMEpF MRswGQYDVQQDDBJtYW1pbGxlMkBjaXNjby5jb20xITAfBgkqhkiG9w0BCQEWEm1hbWlsbGUyQGNp c2NvLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJbKBMsG+9UFTx9uq/bhhXgu vJvO8z7cwKaqqwZhVf5z/kHFyCNijtmTOE+YXjA8mWR4aoBwB5SvGypI/cJUofJ+AlBTC4g+RMx/ K0Ab4/jQqTQz9CDzMOB+Wm+rt8ZJ7A8ZzOJmNDAsf/VvB8l2A1SQz1UsAixgH16NTr8SlblAXEKk 4hwpCudUiNjjQokqJ0H686UBKVorcZSgXaza8XMqGtJF/8mNhR9GQYi7Xht1ky+9LFOrto2daZto KJRwMeVusVdHUeKEQSu7jztw8HchH3KEb7Q+r5X+hhDZoddfKE8d5eyPuhiZdrzv7OlNZ0fSLdx7 3AE3nx9/R5YlXucCAwEAAaOCAtgwggLUMAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQW MBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQUxGd+/qrdVudHrIKkw5xOMY7eaLUwHwYD VR0jBBgwFoAUU3Ltkpzg2ssBXHx+ljVO8tS4UYIwHQYDVR0RBBYwFIESbWFtaWxsZTJAY2lzY28u Y29tMIIBTAYDVR0gBIIBQzCCAT8wggE7BgsrBgEEAYG1NwECAzCCASowLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0 Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBp c3N1ZWQgYWNjb3JkaW5nIHRvIHRoZSBDbGFzcyAxIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9m IHRoZSBTdGFydENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBw dXJwb3NlIGluIGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMDYG A1UdHwQvMC0wK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUxLWNybC5jcmwwgY4G CCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIv Y2xhc3MxL2NsaWVudC9jYTBCBggrBgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2Vy dHMvc3ViLmNsYXNzMS5jbGllbnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRz c2wuY29tLzANBgkqhkiG9w0BAQUFAAOCAQEAlDhXbGEI7lbqUcu5r2JHZaMsbRZda/99ZqODzWGX 0llou9jGccsAWDPPwRRe2+ROpXfH4cuJZElTcLDeZSp/qpXKhjYieFSX8+Ml9sKEj5UOSqQLyoLk PtrIJV12Jk3nuG2Jc0UeEnGwK/aqtzy7+bfEVI0ziyVM2gChHh0RH74KyiwYWknbOTRIkZcz/ulE DVFQp63uj6wfmDNvAUHBAdhKVqA1S/rfP1KcDZpf1NfvwXJibiqTRA6K1EOxTJOP41n/XdvHqHXL RWL2xrOUI9/URANr/ok3OrsuZEMFnAAGefS1bWS/hFtUGVkHGiKEBbyDW7da2ULXbuC7umrQnzGC A28wggNrAgEBMIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkG A1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwaESDAJBgUrDgMCGgUA oIIBrzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMzA2MTAxMzI0 MjNaMCMGCSqGSIb3DQEJBDEWBBQdqkQ9w7XqQMXKkoHcSMDiUi9FtDCBpQYJKwYBBAGCNxAEMYGX MIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3Mg MSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwaESDCBpwYLKoZIhvcNAQkQAgsxgZeg gZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1 cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAx IFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDBoRIMA0GCSqGSIb3DQEBAQUABIIBAHrd 8kfkdy1cwABsA3B5dD8xsnVJKgjLx3ViW9kJGHrd5NYPjekkXA8Rc7JazmxEJSfXY26eRGMl8A2T SwcMIFEY6EaDCB4Jme6j4OMk1TXl0agPae3TT0xpJVDyakC8oxo93nO+Z06ZDRZ4MzAbc/hLctHp Uzl8DOP85CjEXjHLGRjgNK7A/wt1OKHpBkus1RkbdTH1YZgj/dy2Vd5h+ZaoqfPuJw3Z+/0kdN7f mDUkRL4o84FTzF5E8yhZqZq4AgnrKxQDhjjIbzJ6JLZLraGKHIiXJfojCK4XstX39hzusbNE83uJ H+7teznlMbo1cmC+f8TkuhcReDeGx9yOUfoAAAAAAAA= --Apple-Mail=_4C250E41-F90C-4DAA-B485-483D91344836-- From cowan@ccil.org Mon Jun 10 06:47:20 2013 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 6E80B21F8B07 for ; Mon, 10 Jun 2013 06:47:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.382 X-Spam-Level: X-Spam-Status: No, score=-3.382 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s5D2SYfTo4nF for ; Mon, 10 Jun 2013 06:47:16 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id 0DC8E21F8916 for ; Mon, 10 Jun 2013 06:47:15 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1Um2RA-0000Xt-Qm; Mon, 10 Jun 2013 09:47:08 -0400 Date: Mon, 10 Jun 2013 09:47:08 -0400 From: John Cowan To: Dean Landolt Message-ID: <20130610134708.GC22228@mercury.ccil.org> References: <51AFB3F8.8060708@crockford.com> <8F32953C-C788-4DC9-888E-920E2BEB7FDD@yahoo.com> <831B8E46-F239-4353-8F95-8DF3F9BD2E78@yahoo.com> <51AFC924.2030805@crockford.com> <60141305-DCEA-4EC6-9CDF-82B52B13AE91@wirfs-brock.com> <51B20E48.8040109@crockford.com> <944ECA7F-A548-4903-9526-847065066E8E@wirfs-brock.com> <51B2121B.5080801@crockford.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Cc: Allen Wirfs-Brock , Paul Hoffman , Douglas Crockford , "json@ietf.org" Subject: Re: [Json] The names within an object SHOULD be unique. X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 10 Jun 2013 13:47:20 -0000 Dean Landolt scripsit: > > We should not be invalidating data or programs. We should only be > > explaining better. No breakage is acceptable. No breakage. > > In this case "no breakage" effectively means no hope of interoperability > going forward. What, then, is the point of this exercise? Indeed. For if the spec is ambiguous (and it is) and has been interpreted differently by different users (and it has), "no breakage" would mean carefully preserving all those ambiguities exactly as-is. How is that "explaining better"? Better to call off the whole exercise if we are constrained to bug-for-bug compatibility. Even HTML5, which is all about compatibility, doesn't insist that each and every pre-HTML5 parser is already fully conformant. > Another possible solution: specify that parsers MUST NOT throw on > duplicate keys and recommend omitting duplicate keys entirely. "Recommend" is a synonym for SHOULD, so it already says that. -- You're a brave man! Go and break through the John Cowan lines, and remember while you're out there cowan@ccil.org risking life and limb through shot and shell, http://ccil.org/~cowan we'll be in here thinking what a sucker you are! --Rufus T. Firefly From w3c@marcosc.com Mon Jun 10 06:57:27 2013 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 8F02421F8FB6 for ; Mon, 10 Jun 2013 06:57:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PNRtY0dNefOx for ; Mon, 10 Jun 2013 06:57:24 -0700 (PDT) Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [IPv6:2a00:1450:400c:c00::229]) by ietfa.amsl.com (Postfix) with ESMTP id 1B5DE21F8FA1 for ; Mon, 10 Jun 2013 06:57:23 -0700 (PDT) Received: by mail-wg0-f41.google.com with SMTP id k13so3112335wgh.2 for ; Mon, 10 Jun 2013 06:57:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=date:from:to:cc:message-id:in-reply-to:references:subject:x-mailer :mime-version:content-type:content-transfer-encoding :content-disposition:x-gm-message-state; bh=5HOpqI+VhuVG4jcsjjmL9u+rniSUmxq6ZNSEBmWuT8U=; b=PfNEzC3HaPxbM6ZX5WStR2mvXa64WrVfgHGnWMQZCKpuTlbyPTJq3Jm80XlWD+5ONj X+Tva4ddku7gGkGGDzJoFfXNT7X+9bFqspUHIV6GsDcuEnqcoKEmLBXlmRYidf8/Iw0A nEmL/5SvtFtH6YzrFDlZyvTndLDmGlptnXnR+z5sguKr4/4IdRs7spwQPgg2mPHm2WZm MpLpQPxGbdTdnHFv2ypops3NgthqF1PQj2zcKjHwcyf+QIiWvUCfDN+Lw6TPSoQDRReM f7xygfNjBD4rfdHFqYTIAi11OVeOTTCpXJpDyuQ5z23wK7AS0/TajFK6fsZ/McpgjO2n lDbA== X-Received: by 10.180.211.49 with SMTP id mz17mr4758527wic.43.1370872642440; Mon, 10 Jun 2013 06:57:22 -0700 (PDT) Received: from [172.16.0.7] (bl11-16-70.dsl.telepac.pt. [85.244.16.70]) by mx.google.com with ESMTPSA id ft10sm11519325wib.7.2013.06.10.06.57.20 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 10 Jun 2013 06:57:21 -0700 (PDT) Date: Mon, 10 Jun 2013 14:57:19 +0100 From: Marcos Caceres To: John Cowan Message-ID: <749B7AC5B7D748ECAC486E5A299B2F70@marcosc.com> In-Reply-To: <20130610134708.GC22228@mercury.ccil.org> References: <51AFB3F8.8060708@crockford.com> <8F32953C-C788-4DC9-888E-920E2BEB7FDD@yahoo.com> <831B8E46-F239-4353-8F95-8DF3F9BD2E78@yahoo.com> <51AFC924.2030805@crockford.com> <60141305-DCEA-4EC6-9CDF-82B52B13AE91@wirfs-brock.com> <51B20E48.8040109@crockford.com> <944ECA7F-A548-4903-9526-847065066E8E@wirfs-brock.com> <51B2121B.5080801@crockford.com> <20130610134708.GC22228@mercury.ccil.org> X-Mailer: sparrow 1.6.4 (build 1178) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Gm-Message-State: ALoCoQkVoKrVlcWXKZ6sdGdapap2sobO5pdrqfRg+gAIohwbN0A1VHQc3t3aGWq2tTAb0p7b8ceN Cc: Allen Wirfs-Brock , Dean Landolt , Paul Hoffman , Douglas Crockford , "=?utf-8?Q?json=40ietf.org?=" Subject: Re: [Json] The names within an object SHOULD be unique. X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 10 Jun 2013 13:57:27 -0000 On Monday, June 10, 2013 at 2:47 PM, John Cowan wrote: > Dean Landolt scripsit: > > > > We should not be invalidating data or programs. We should only be > > > explaining better. No breakage is acceptable. No breakage. > > > > > > > > In this case "no breakage" effectively means no hope of interoperability > > going forward. What, then, is the point of this exercise? > > > > Indeed. For if the spec is ambiguous (and it is) and has been interpreted > differently by different users (and it has), "no breakage" would mean > carefully preserving all those ambiguities exactly as-is. How is that > "explaining better"? Better to call off the whole exercise if we are > constrained to bug-for-bug compatibility. > > Even HTML5, which is all about compatibility, doesn't insist that each > and every pre-HTML5 parser is already fully conformant. Agree. Maybe we can get agreement of what is intolerable parsing behavior first (i.e., what is currently considered harmful and why in existing implementations - if anything)? -- Marcos Caceres From cabo@tzi.org Mon Jun 10 07:00:22 2013 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 72A2E21F93B9 for ; Mon, 10 Jun 2013 07:00:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.111 X-Spam-Level: X-Spam-Status: No, score=-106.111 tagged_above=-999 required=5 tests=[AWL=0.138, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RV9X3alecQNU for ; Mon, 10 Jun 2013 07:00:15 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 7B47421F93B7 for ; Mon, 10 Jun 2013 07:00:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r5AE03IG010875; Mon, 10 Jun 2013 16:00:08 +0200 (CEST) Received: from [192.168.217.105] (p54893267.dip0.t-ipconnect.de [84.137.50.103]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id C28A13D7F; Mon, 10 Jun 2013 16:00:02 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <20130610132255.GA22228@mercury.ccil.org> Date: Mon, 10 Jun 2013 16:00:01 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <5F89A4E9-806E-4356-B915-5464A06D65B2@tzi.org> References: <51B58261.5040808@drees.name> <51b5a11d.0881440a.629d.68d4SMTPIN_ADDED_BROKEN@mx.google.com> <60EAB36FA95E40A180330B3D7F8377F5@marcosc.com> <51B5B17E.5030706@drees.name> <20130610132255.GA22228@mercury.ccil.org> To: John Cowan X-Mailer: Apple Mail (2.1508) Cc: json@ietf.org, stefan@drees.name, Marcos Caceres Subject: Re: [Json] Generators X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 10 Jun 2013 14:00:22 -0000 On Jun 10, 2013, at 15:22, John Cowan wrote: > But a conditional of the form > "The program MUST do such-and-such if it can", which is what we have > here, needs to be rewritten as "The program SHOULD do such-and-such." That is not quite what SHOULD means: 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course. So "SHOULD" =3D "MUST unless it can be determined appropriate not to", = and we typically try to explain those circumstances and implications in = the draft. The fact that you cannot do such-and-such may not at all make it = appropriate not to do such-and-such! (After all, not being able to do something is typically the result of a = design decision, and that decision simply may have been inappropriate in = the first place; the SHOULD does not exculpate you here.) Gr=FC=DFe, Carsten From cowan@ccil.org Mon Jun 10 07:18:15 2013 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 12C5521F8EC6 for ; Mon, 10 Jun 2013 07:18:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.389 X-Spam-Level: X-Spam-Status: No, score=-3.389 tagged_above=-999 required=5 tests=[AWL=0.210, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g02wDXTSRUcL for ; Mon, 10 Jun 2013 07:18:10 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id DFA8121F8EBC for ; Mon, 10 Jun 2013 07:18:09 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1Um2v9-0003wu-AF; Mon, 10 Jun 2013 10:18:07 -0400 Date: Mon, 10 Jun 2013 10:18:07 -0400 From: John Cowan To: Carsten Bormann Message-ID: <20130610141806.GB6163@mercury.ccil.org> References: <51B58261.5040808@drees.name> <51b5a11d.0881440a.629d.68d4SMTPIN_ADDED_BROKEN@mx.google.com> <60EAB36FA95E40A180330B3D7F8377F5@marcosc.com> <51B5B17E.5030706@drees.name> <20130610132255.GA22228@mercury.ccil.org> <5F89A4E9-806E-4356-B915-5464A06D65B2@tzi.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5F89A4E9-806E-4356-B915-5464A06D65B2@tzi.org> User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Cc: json@ietf.org, stefan@drees.name, Marcos Caceres Subject: [Json] MUSTard (was: Generators) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 10 Jun 2013 14:18:15 -0000 Carsten Bormann scripsit: > The fact that you cannot do such-and-such may not at all make it > appropriate not to do such-and-such! I think it does; otherwise we get paradoxes like this one: 1) It is my moral duty to prevent the world from being destroyed and every person on it killed (for example by Vogons); 2) It is impossible for me to stop the world from being destroyed by Vogons; 3) Therefore, it is my moral duty to do the impossible. > (After all, not being able to do something is typically the result of > a design decision, and that decision simply may have been inappropriate > in the first place; the SHOULD does not exculpate you here.) That sounds more like MUST to me. A major purpose of including SHOULDs is to allow implementation tradeoffs to exist. If it comes to that, not even MUST is truly absolute: a processor spec might say that on encountering a certain opcode, the processor MUST add the r2 register to the r1 register, but this requirement is not generally held to apply when the processor is on fire. There are things that airplane engines MUST do even when they *are* on fire, however. -- John Cowan cowan@ccil.org "Mr. Lane, if you ever wish anything that I can do, all you will have to do will be to send me a telegram asking and it will be done." "Mr. Hearst, if you ever get a telegram from me asking you to do anything, you can put the telegram down as a forgery." From stedolan@stedolan.net Mon Jun 10 09:55:34 2013 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 2DC2E21F9703 for ; Mon, 10 Jun 2013 09:55:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.047 X-Spam-Level: X-Spam-Status: No, score=-0.047 tagged_above=-999 required=5 tests=[AWL=0.379, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ow+YejPCTAUm for ; Mon, 10 Jun 2013 09:55:28 -0700 (PDT) Received: from mail-la0-x234.google.com (mail-la0-x234.google.com [IPv6:2a00:1450:4010:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id 264F721F9814 for ; Mon, 10 Jun 2013 09:55:20 -0700 (PDT) Received: by mail-la0-f52.google.com with SMTP id fo12so4075592lab.39 for ; Mon, 10 Jun 2013 09:55:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:x-originating-ip:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :x-gm-message-state; bh=6/2uOpG/JH8CzmL9Pfxz6SLDe0Yh0x56gzGaj3WVikk=; b=kfe2JRI8wdRrWkoeY6YRqHIDCv40UdXw1v8y/vovgdon6abyAucx4EDl4OqB3cZzMQ IGhqkdlDW5BlYponokJUBlfvsmGkTRIVUX+nGDV1WlAV2hmWVkNGPNR/ntryx+k+QT6D uBYpYXCYs5RSHGWEqbmt2SwfRm6y7zLs5TpNSPjEpXxd3RnNcWIKPuaLYHChSsKUwN/r iJcRqT7PhWJUNcOz44GlTgFb7236O7GfkxIIEkdylPkIJKL9V/4Xcnkkx99DJVElEoM3 xKHk8eUGwGEE9hBUHUfiqSnFs9+YGi+Wd6XE5PR+VggmNmZ+FYle90Tv+YRnvD3ppUC6 CTDw== MIME-Version: 1.0 X-Received: by 10.152.23.99 with SMTP id l3mr5256219laf.82.1370883319768; Mon, 10 Jun 2013 09:55:19 -0700 (PDT) Sender: stedolan@stedolan.net Received: by 10.114.176.231 with HTTP; Mon, 10 Jun 2013 09:55:19 -0700 (PDT) X-Originating-IP: [131.111.184.8] In-Reply-To: <51B45FAA.4070900@drees.name> References: <51AF8479.5080002@crockford.com> <51b1168c.e686440a.5339.5fc4SMTPIN_ADDED_BROKEN@mx.google.com> <51B1B47C.9060009@drees.name> <51B1E909.2010402@drees.name> <51B1FE6A.80409@drees.name> <51B45FAA.4070900@drees.name> Date: Mon, 10 Jun 2013 17:55:19 +0100 X-Google-Sender-Auth: Mon2a_AhhRBFSLNreTtYPyZUVn4 Message-ID: From: Stephen Dolan To: stefan@drees.name Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQkL5SWw6kTGZPLo1212Wzyhw73jc+TTARiFKNuQDDRb6ow7al5pw1xLPP4XySG5Wn1QbeEZ Cc: Vinny A , Markus Lanthaler , "json@ietf.org" Subject: Re: [Json] The names within an object SHOULD be unique. X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 10 Jun 2013 16:55:35 -0000 On Sun, Jun 9, 2013 at 11:57 AM, Stefan Drees wrote: > > I think you mean "call-reception", right? > You're right, apologies. > Really having a hard time trying to imagine a use case, where someone came > up with such an implementation of "separation of concerns". > But I'd have a good old name for it: "Broken phone" :-) > [...] > Ahem, the "hole" appears to be two system components playing broken phone. The issue is, that currently there exists a JSON document which one RFC-conforming correct JSON parser can say is indistinguishable from {a: true}, and another equally RFC-conforming correct JSON parser can say is indistinguishable from {a: false}. While my example might not have been great, this still seems easily exploitable: two parsers parsing a supposedly standard format can be tricked into seeing completely different results from the same input. Surely it would be better if we could say that one of those parsers was not RFC-conforming? Stephen From paul.hoffman@vpnc.org Mon Jun 10 10:01:48 2013 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 869D821F995B for ; Mon, 10 Jun 2013 10:01:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.408 X-Spam-Level: X-Spam-Status: No, score=-102.408 tagged_above=-999 required=5 tests=[AWL=0.191, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4E47wuoj9p4c for ; Mon, 10 Jun 2013 10:01:47 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 2218A21F994C for ; Mon, 10 Jun 2013 10:01:45 -0700 (PDT) Received: from [10.20.30.90] (50-0-66-165.dsl.dynamic.sonic.net [50.0.66.165]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r5AH1b1F043408 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 10 Jun 2013 10:01:38 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Paul Hoffman In-Reply-To: Date: Mon, 10 Jun 2013 10:01:37 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <62F282B7-11AA-44F8-A03B-201F2DAE51B5@vpnc.org> References: <51AF8479.5080002@crockford.com> <51b1168c.e686440a.5339.5fc4SMTPIN_ADDED_BROKEN@mx.google.com> <51B1B47C.9060009@drees.name> <51B1E909.2010402@drees.name> <51B1FE6A.80409@drees.name> <51B45FAA.4070900@drees.name> To: Stephen Dolan X-Mailer: Apple Mail (2.1508) Cc: json@ietf.org Subject: Re: [Json] The names within an object SHOULD be unique. X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 10 Jun 2013 17:01:48 -0000 On Jun 10, 2013, at 9:55 AM, Stephen Dolan = wrote: > The issue is, that currently there exists a JSON document which one > RFC-conforming correct JSON parser can say is indistinguishable from > {a: true}, and another equally RFC-conforming correct JSON parser can > say is indistinguishable from {a: false}. >=20 > While my example might not have been great, this still seems easily > exploitable: two parsers parsing a supposedly standard format can be > tricked into seeing completely different results from the same input. > Surely it would be better if we could say that one of those parsers > was not RFC-conforming? Stated that narrowly, yes. But given your first paragraph, the = comparison might be more fully stated as "would it be better if we could = says that one of these parsers was not RFC-conforming if making such a = statement caused what was a stored valid JSON text now non-valid". --Paul Hoffman= From stedolan@stedolan.net Mon Jun 10 10:02:37 2013 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 9285821F9964 for ; Mon, 10 Jun 2013 10:02:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.449 X-Spam-Level: X-Spam-Status: No, score=-1.449 tagged_above=-999 required=5 tests=[AWL=1.528, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NDQ6iXYfpU+I for ; Mon, 10 Jun 2013 10:02:32 -0700 (PDT) Received: from mail-lb0-f176.google.com (mail-lb0-f176.google.com [209.85.217.176]) by ietfa.amsl.com (Postfix) with ESMTP id 0DE5421F995F for ; Mon, 10 Jun 2013 10:02:31 -0700 (PDT) Received: by mail-lb0-f176.google.com with SMTP id z5so6560131lbh.35 for ; Mon, 10 Jun 2013 10:02:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:x-originating-ip:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding:x-gm-message-state; bh=EiZ2eFAokufupA1l2nBB7qDdmnSZARSSYEWhLLyKA0A=; b=X0v596B8hKp70R8TR8XhtdmkADuDwebVYbWAKA7uzhJC8GNmjhHboQge1AH3Le1jtR +R1jEEq74dGACWHXgoxhosFN/rUrwHuTASLQY27URxzu7TPrNmoghoibpG2aOcyYsGvc iK3i+04dRounNOlttlja72cLQ2HB/EjZVM8n/rQXbkAUtotMrU0/rRrBXH+UPi5XXOPN XBcO2LZM4D8ccb2gNR2KvpyqXmtaPjrUGQ8qp7cDiEpcFPrfUaKbQHxJ9sZdc6AQUmou qSnbkWeU+uKp2E287P+kYbSiqGy0Aamuc/fSdC3TKt4Nv2dRZOD0l+TMGmP7SLu/xsth +iqw== MIME-Version: 1.0 X-Received: by 10.112.61.199 with SMTP id s7mr1123418lbr.53.1370883750948; Mon, 10 Jun 2013 10:02:30 -0700 (PDT) Sender: stedolan@stedolan.net Received: by 10.114.176.231 with HTTP; Mon, 10 Jun 2013 10:02:30 -0700 (PDT) X-Originating-IP: [131.111.184.8] In-Reply-To: References: Date: Mon, 10 Jun 2013 18:02:30 +0100 X-Google-Sender-Auth: uPuYRrSDkozlztx35KqcxdPwQZw Message-ID: From: Stephen Dolan To: R S Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQkFoCUqqTN6LR+5S2crUm34EYH2VIZwthmyYadK85XPZr/5yGKcK4rv/Fw2Zm9fTtAU1146 Cc: Paul Hoffman , "json@ietf.org" Subject: Re: [Json] A possible summary of the discussion so far on code points and characters X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 10 Jun 2013 17:02:37 -0000 On Sun, Jun 9, 2013 at 1:23 AM, R S wrote: > It's a requirement. Here are some additional references: > > > > > The paragraph following the one I cited: > > 'Throughout the rest of this document, the phrase =93code unit=94 and the= word > =93character=94 will be used to refer to a 16-bit unsigned value used to > represent a single 16-bit unit of text. The phrase =93Unicode character= =94 will > be used to refer to the abstract linguistic or typographical unit > represented by a single Unicode scalar value (which may be longer than 16 > bits and thus may be represented by more than one code unit). The phrase > =93code point=94 refers to such a Unicode scalar value. =93Unicode charac= ter=94 only > refers to entities represented by single Unicode scalar values: the > components of a combining character sequence are still individual =93Unic= ode > characters,=94 even though a user might think of the whole sequence as a > single character.' > > - Rob Sorry, I misread. Stephen From stedolan@stedolan.net Mon Jun 10 10:08:35 2013 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 B36F521F8616 for ; Mon, 10 Jun 2013 10:08:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.556 X-Spam-Level: X-Spam-Status: No, score=-0.556 tagged_above=-999 required=5 tests=[AWL=-0.130, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7md-78g7d6CF for ; Mon, 10 Jun 2013 10:08:30 -0700 (PDT) Received: from mail-la0-x22c.google.com (mail-la0-x22c.google.com [IPv6:2a00:1450:4010:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 2227521F8FB3 for ; Mon, 10 Jun 2013 10:08:26 -0700 (PDT) Received: by mail-la0-f44.google.com with SMTP id er20so5974549lab.3 for ; Mon, 10 Jun 2013 10:08:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:x-originating-ip:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :x-gm-message-state; bh=ZrT54Aq8shJBIzsPyO/HD3EZAI3NOh7Ca6QEv4Dtqko=; b=hJ2Y5SLAEdROA5H033+HOXJ51ewKM9L/ujPeqzZnFn1WW29wje/ze/42cY4fYjkibF RNdzwplHR61RDBegvmJs6CISFO11UgXoIQA1A7Zubd/3QD5xObBowvk6WpPnVMwnsRYx rg1eYj7Df3IsQIi2lYQmtju2eMJbgDYzyMOKJUHKgk+SPuZ4V/zWwDj5AcmUMryPbUQ6 zdq16R9/WMEWBIyVHXEv/rsd5R7GHyOWge2ScIEqTkXjIWwyOy5pibLStV0FNh6pgtVP pcmr2T0WNjoJQKPJbzrt9oUjyOCak8Nb5i8hoSgXEXFvkHICBjtOLZz9JJxbMxTOWxdx kOGg== MIME-Version: 1.0 X-Received: by 10.152.120.196 with SMTP id le4mr679394lab.6.1370884105990; Mon, 10 Jun 2013 10:08:25 -0700 (PDT) Sender: stedolan@stedolan.net Received: by 10.114.176.231 with HTTP; Mon, 10 Jun 2013 10:08:25 -0700 (PDT) X-Originating-IP: [131.111.184.8] In-Reply-To: <62F282B7-11AA-44F8-A03B-201F2DAE51B5@vpnc.org> References: <51AF8479.5080002@crockford.com> <51b1168c.e686440a.5339.5fc4SMTPIN_ADDED_BROKEN@mx.google.com> <51B1B47C.9060009@drees.name> <51B1E909.2010402@drees.name> <51B1FE6A.80409@drees.name> <51B45FAA.4070900@drees.name> <62F282B7-11AA-44F8-A03B-201F2DAE51B5@vpnc.org> Date: Mon, 10 Jun 2013 18:08:25 +0100 X-Google-Sender-Auth: 2z1CRGt-mFRoU-TcINmncGmHmws Message-ID: From: Stephen Dolan To: Paul Hoffman Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQlfHN355bSnIhuWj3Bd9Pj62CoB41dmA48qkUCjCzVCyyXR9l8GiHLXkE57P4d/2vhNBO8Q Cc: "json@ietf.org" Subject: Re: [Json] The names within an object SHOULD be unique. X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 10 Jun 2013 17:08:35 -0000 On Mon, Jun 10, 2013 at 6:01 PM, Paul Hoffman wrote: > > > On Jun 10, 2013, at 9:55 AM, Stephen Dolan wrote: > >> The issue is, that currently there exists a JSON document which one >> RFC-conforming correct JSON parser can say is indistinguishable from >> {a: true}, and another equally RFC-conforming correct JSON parser can >> say is indistinguishable from {a: false}. >> >> While my example might not have been great, this still seems easily >> exploitable: two parsers parsing a supposedly standard format can be >> tricked into seeing completely different results from the same input. >> Surely it would be better if we could say that one of those parsers >> was not RFC-conforming? > > Stated that narrowly, yes. But given your first paragraph, the comparison might be > more fully stated as "would it be better if we could says that one of these parsers was > not RFC-conforming if making such a statement caused what was a stored valid > JSON text now non-valid". I don't propose making any stored valid JSON text become non-valid. {a: true, a: false} is currently a valid JSON text, and it should remain so or things would break. Some JSON parsers consider that document distinguishable from {a: false} (e.g. streaming parsers that return all key/value pairs). Most of them don't. I propose that it be invalid to consider that document indistinguishable from {a: true}. Parsers are free to accept or reject it, and if they accept it they are free to return either one or two "a" entries, but if they only return one it must be {a: false}. Stephen From paul.hoffman@vpnc.org Mon Jun 10 10:35:49 2013 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 D01E721F96C2 for ; Mon, 10 Jun 2013 10:35:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.413 X-Spam-Level: X-Spam-Status: No, score=-102.413 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eDFL3-ROgqib for ; Mon, 10 Jun 2013 10:35:49 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 0C88621F96B1 for ; Mon, 10 Jun 2013 10:35:49 -0700 (PDT) Received: from [10.20.30.90] (50-0-66-165.dsl.dynamic.sonic.net [50.0.66.165]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r5AHZjjq044733 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 10 Jun 2013 10:35:46 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Paul Hoffman In-Reply-To: <51B58261.5040808@drees.name> Date: Mon, 10 Jun 2013 10:35:45 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <8512D965-C32C-4C69-A709-350333C925A0@vpnc.org> References: <51B58261.5040808@drees.name> To: stefan@drees.name X-Mailer: Apple Mail (2.1508) Cc: "json@ietf.org" Subject: Re: [Json] Generators X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 10 Jun 2013 17:35:50 -0000 On Jun 10, 2013, at 12:38 AM, Stefan Drees wrote: > A JSON generator produces JSON text that MUST strictly conform to > the JSON grammar. This would be more definitive as "...the JSON grammar from Section 2 of = this document". > Generators MUST NOT duplicate names in objects if they can avoid or > detect such duplication. +1 to the others who have said "yuck" to the poor use of 2119 MUST here. = Further, this is a significant change from both RFC 4726 and ECMAScript. = Proposed new wording: Generators SHOULD NOT create objects that have duplicate names because = objects with duplicate names can be interpreted in different ways by = conformant JSON parsers. --Paul Hoffman From tsaloranta@gmail.com Mon Jun 10 10:39:16 2013 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 43A2521F8BE6 for ; Mon, 10 Jun 2013 10:39:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.405 X-Spam-Level: X-Spam-Status: No, score=-2.405 tagged_above=-999 required=5 tests=[AWL=0.194, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FWHeNFflUtrB for ; Mon, 10 Jun 2013 10:39:15 -0700 (PDT) Received: from mail-we0-x22d.google.com (mail-we0-x22d.google.com [IPv6:2a00:1450:400c:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id B576D21F8ECB for ; Mon, 10 Jun 2013 10:39:14 -0700 (PDT) Received: by mail-we0-f173.google.com with SMTP id x54so4303483wes.32 for ; Mon, 10 Jun 2013 10:39:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Abp+mPalt1/bbYHtL5LlNjuPgxJtqmVJf1XIXiAfQgY=; b=WnanS3WPK51MZQGdaE2uV+1rIXnG3HEheVudig3pEVOqGDOBYQXCfdNOanU5XwNXdr O/9DH0xWqx8LV6KtBFJLLBnMJbcoNepapJGGpHX3H8/kzIytAl5vjcV4T48SMo9qG5Vs bOGAvj3p4LQrFRKMxmRQzYHT/eioGGBvjulz5Q6pHsg6Q4HDmByEmBLxGhIK5TV4cEyF RFAIB6AN25HEYoynB8fcD/FqCkENSOC1xT91xtCi3CCI35MzX5PLkOWDAdlitlZn+oaf Z9hafYHWHgj1bYxkK9TF1TdyFhuVJPoV5SiiBRgANcxuQmxB78qtaZSPJs8Jfve6L7yG Qfbw== MIME-Version: 1.0 X-Received: by 10.180.11.194 with SMTP id s2mr3590624wib.7.1370885953718; Mon, 10 Jun 2013 10:39:13 -0700 (PDT) Received: by 10.227.72.74 with HTTP; Mon, 10 Jun 2013 10:39:13 -0700 (PDT) In-Reply-To: References: <51B58261.5040808@drees.name> <51b5a11d.0881440a.629d.68d4SMTPIN_ADDED_BROKEN@mx.google.com> <60EAB36FA95E40A180330B3D7F8377F5@marcosc.com> <51B5B17E.5030706@drees.name> Date: Mon, 10 Jun 2013 10:39:13 -0700 Message-ID: From: Tatu Saloranta To: Marcos Caceres Content-Type: multipart/alternative; boundary=001a11c355a24c914c04ded04281 Cc: stefan@drees.name, "json@ietf.org" Subject: Re: [Json] Generators X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 10 Jun 2013 17:39:16 -0000 --001a11c355a24c914c04ded04281 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Mon, Jun 10, 2013 at 5:20 AM, Marcos Caceres wrote: > Hi Stefan, > > On Monday, June 10, 2013 at 11:59 AM, Stefan Drees wrote: > > > On 2013-06-10 12:10 CEST, Marcos Caceres wrote: > > > On Monday, 10 June 2013 at 10:49, Markus Lanthaler wrote: > > > > On Monday, June 10, 2013 9:38 AM, Stefan Drees wrote: > > > > > 5. Generators > > > > > > > > > > A JSON generator produces JSON text that MUST strictly conform to > > > > > the JSON grammar. > > > > > > > > > > > > > > > > Please try to avoid "wish list" style conformance requirements. If yo= u > > > want "strictly" conforming documents generated (whatever that may > mean), > > > then please write the algorithm to produce such documents. For exampl= e: > > > > > > "When generating JSON, as JSON generator MUST run the steps to > generate JSON text. > > > > > > The steps to generate JSON text are given by the following algorithm: > > > 1. =85 > > > 2. =85 > > > " > > > > > > > > if I only once had the power to write my wish lists that strong and > > concise, I would be a very happy man I guess :-) > > > > We will not have a conformance section and we had until now no step by > > step description but only an "integral" check, where the result had to > > conform to the ABNF grammar of JSON. > > So the following message is the best we can state: > > If you are a wannabe X generator, ensure your output strictly conforms > > to our X grammar. > > > > Retro-inventing of stepwise solutions/recipes simply not having been > > around for all these years and then acting as if they had, to me > > personally gives a strong smell and is far off the charter, isn't it? > > I haven't read the charter, tbh =85 I literally stumbled onto this list > yesterday :) Make sure you then read preceding discussions. Many of the concerns have been discussed in considerable length. It appears bit arrogant to start commenting on "should leave all these loopholes" when there are solid reasons for not mandating things that various implementation can not support in practice. Practice based on existing significant use cases, as discussed on the list. > However, I'm worried that overly simplistic or optimistic conformance > requirements will just force people to go and look at ES6 to actually wri= te > the parsing and generation algorithms (or worst, they will just find some > other random implementation out there and copy that). That could greatly > diminish the value of this specification as it will leave implementers > scratching their heads about how to implement either a parser or a > generator. > > Also, given the legacy of JSON, it should be possible to see which parser > behavior "won" (e.g., Doug's original JSON.js?) - and model this spec off > that. > > Which is what has been discussed in detail as well; and is what lead to current proposal of "if only one of duplicate values used, it shall be the last one". > Additionally, I suspect few people actually implement an ABNF parser - > whatever is expressed in ABNF will have to be translated into code for a > specific implementation. You can essentially shortcut that by specifying > the algorithm and making implementer's lives easier. That's not to say > that the ABNF should not be there (it helps the reader understand > components of the JSON grammar) - but the reality of the situation should > be acknowledged (ABNF is an editorial aid, but rarely, AFAIK, a tool used > in implementations in it's pure form to do syntactical checking). > > > > > > Generators MUST NOT duplicate names in objects if they can avoid = or > > > > > detect such duplication. > > > > > > > > > > """ > > > > [...] > > > > > This "MUST NOT duplicate ... if" reads pretty soft for > implementers, > > > > > but should be the only consensual non-breaking way out of the > > > > > historical dilemma of not enforcing it for generators in the firs= t > place. > > > > > > > > > > > > > > > > I agree. The above "if they can avoid [it]" if pretty lousy spec text= . > > > Please define the algorithm instead to produce the results you want. > > > > > > > > I might be tempted to change the sequence to a more natural looking one > > "detect before avoid" but then, if an implementation is not able to > > avoid it, why should it bother to detect or not detect? So the stronges= t > > excemption is noted first: A policy or a use case hinders me in ensurin= g > > the "uniqueness wish" for names in objects. > > > > On a personal note: If we avoid wordings like "pretty lousy spec text" > > in situations where many people are trying to retrofit best possible > > constraints into an area where these completely missed for years, to > > avoid further future "leakage" and without breaking reality that would > > be surely helpful, wouldn't it? > > Yes, I'm sorry; I didn't mean any offense. I just meant that it was a > conditional MUST, and that's not how MUST should be used (as it means one > parser can do one thing and another can do another thing =85 which is an > interoperability anti-pattern). This would, obviously, be bad if I'm > sending one JSON representation from the client and it gets transformed > into a different one on the server and the spec says that this behavior i= s > ok. > But this is reality: the only way to guarantee, for example, uniqueness of keys leads to constraints that make it impossible to process JSON content without tracking all names of currently open JSON objects in memory. In worst case this is comparable to just holding on to the whole logical JSON tree representation. > > On the other hand, if the spec has to say, "well, that's the reality righ= t > now=85 and here are some guidance on how to avoid that problem without > breaking clients and servers:" that might have to do. > > which is what I understand specification tries to say. -+ Tatu +- --001a11c355a24c914c04ded04281 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
On Mon, Jun 10, 2013 at 5:20 AM, Marcos Caceres <w3c@marco= sc.com> wrote:
Hi Stefan,

On Monday, June 10, 2013 at 11:59 AM, Stefan Drees wrote:

> On 2013-06-10 12:10 CEST, Marcos Caceres wrote:
> > On Monday, 10 June 2013 at 10:49, Markus Lanthaler wrote:
> > > On Monday, June 10, 2013 9:38 AM, Stefan Drees wrote:
> > > > 5. Generators
> > > >
> > > > A JSON generator produces JSON text that MUST strictly = conform to
> > > > the JSON grammar.
> > >
> >
> >
> >
> > Please try to avoid "wish list" style conformance requi= rements. If you
> > want "strictly" conforming documents generated (whateve= r that may mean),
> > then please write the algorithm to produce such documents. For ex= ample:
> >
> > "When generating JSON, as JSON generator MUST run the steps = to generate JSON text.
> >
> > The steps to generate JSON text are given by the following algori= thm:
> > 1. =85
> > 2. =85
> > "
>
>
>
> if I only once had the power to write my wish lists that strong and > concise, I would be a very happy man I guess :-)
>
> We will not have a conformance section and we had until now no step by=
> step description but only an "integral" check, where the res= ult had to
> conform to the ABNF grammar of JSON.
> So the following message is the best we can state:
> If you are a wannabe X generator, ensure your output strictly conforms=
> to our X grammar.
>
> Retro-inventing of stepwise solutions/recipes simply not having been > around for all these years and then acting as if they had, to me
> personally gives a strong smell and is far off the charter, isn't = it?

I haven't read the charter, tbh =85 I literally stumbled on= to this list yesterday :) =A0

Make su= re you then read preceding discussions. Many of the concerns have been disc= ussed in considerable length. It appears bit arrogant to start commenting o= n "should leave all these loopholes" when there are solid reasons= for not mandating things that various implementation can not support in pr= actice. Practice based on existing significant use cases, as discussed on t= he list.
=A0
However, I'm worried that = overly simplistic or optimistic conformance requirements will just force pe= ople to go and look at ES6 to actually write the parsing and generation alg= orithms (or worst, they will just find some other random implementation out= there and copy that). That could greatly diminish the value of this specif= ication as it will leave implementers scratching their heads about how to i= mplement either a parser or a generator.

Also, given the legacy of JSON, it should be possible to see which parser b= ehavior "won" (e.g., Doug's original JSON.js?) - and model th= is spec off that.


Which is what has been discussed= in detail as well; and is what lead to current proposal of "if only o= ne of duplicate values used, it shall be the last one".
=A0
Additionally, I suspect few people actually implement an ABNF parser - what= ever is expressed in ABNF will have to be translated into code for a specif= ic implementation. You can essentially shortcut that by specifying the algo= rithm and making implementer's lives easier. =A0That's not to say t= hat the ABNF should not be there (it helps the reader understand components= of the JSON grammar) - but the reality of the situation should be acknowle= dged (ABNF is an editorial aid, but rarely, AFAIK, a tool used in implement= ations in it's pure form to do syntactical checking).

> > > > Generators MUST NOT duplicate names in objects if they = can avoid or
> > > > detect such duplication.
> > > >
> > > > """
> > > [...]
> > > > This "MUST NOT duplicate ... if" reads pretty= soft for implementers,
> > > > but should be the only consensual non-breaking way out = of the
> > > > historical dilemma of not enforcing it for generators i= n the first place.
> > >
> >
> >
> >
> > I agree. The above "if they can avoid [it]" if pretty l= ousy spec text.
> > Please define the algorithm instead to produce the results you wa= nt.
>
>
>
> I might be tempted to change the sequence to a more natural looking on= e
> "detect before avoid" but then, if an implementation is not = able to
> avoid it, why should it bother to detect or not detect? So the stronge= st
> excemption is noted first: A policy or a use case hinders me in ensuri= ng
> the "uniqueness wish" for names in objects.
>
> On a personal note: If we avoid wordings like "pretty lousy spec = text"
> in situations where many people are trying to retrofit best possible > constraints into an area where these completely missed for years, to > avoid further future "leakage" and without breaking reality = that would
> be surely helpful, wouldn't it?

Yes, I'm sorry; I didn't mean any offense. I just meant that = it was a conditional MUST, and that's not how MUST should be used (as i= t means one parser can do one thing and another can do another thing =85 wh= ich is an interoperability anti-pattern). This would, obviously, be bad if = I'm sending one JSON representation from the client and it gets transfo= rmed into a different one on the server and the spec says that this behavio= r is ok.


But this is reality: = the only way to guarantee, for example, uniqueness of keys leads to constra= ints that make it impossible to process JSON content without tracking all n= ames of currently open JSON objects in memory. In worst case this is compar= able to just holding on to the whole logical JSON tree representation.
=A0

On the other hand, if the spec has to say, "well, that's the reali= ty right now=85 and here are some guidance on how to avoid that problem wit= hout breaking clients and servers:" that might have to do.


which is= what I understand specification tries to say.

-+ Tatu +-

=A0
--001a11c355a24c914c04ded04281-- From nico@cryptonector.com Mon Jun 10 10:43:53 2013 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 80EED21F8ECB for ; Mon, 10 Jun 2013 10:43:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.957 X-Spam-Level: X-Spam-Status: No, score=-1.957 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IrmjqWm8+spL for ; Mon, 10 Jun 2013 10:43:48 -0700 (PDT) Received: from homiemail-a29.g.dreamhost.com (caiajhbdcaid.dreamhost.com [208.97.132.83]) by ietfa.amsl.com (Postfix) with ESMTP id 6238821F8EF7 for ; Mon, 10 Jun 2013 10:43:48 -0700 (PDT) Received: from homiemail-a29.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a29.g.dreamhost.com (Postfix) with ESMTP id B9738674060 for ; Mon, 10 Jun 2013 10:43:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=5qYuKfwxwBkSo/HlYu/3 PJI0SuE=; b=BYSAcyMGT/lbwHKM5+EDf1wMOK8wfSAz0XTH6rHp28UOqJeaT3z/ JAh25uFEfJeEfSMB+hTu3MxHd5ny/l5nHBssVw0we+YjA7sstFrY8OaV3dx57AGh jw5etLc1tFB0xBSOre7KF068o9ltgTQnM98laYymezkXOiyE6YFzTss= Received: from mail-we0-f176.google.com (mail-we0-f176.google.com [74.125.82.176]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a29.g.dreamhost.com (Postfix) with ESMTPSA id 1E718674070 for ; Mon, 10 Jun 2013 10:43:36 -0700 (PDT) Received: by mail-we0-f176.google.com with SMTP id t56so5121418wes.35 for ; Mon, 10 Jun 2013 10:43:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=zCr+6vKOLkLbNtcwWm7IQuyqFF/uSXKBElhSj32lImc=; b=AI8kz1tZ/UndT9E+MnC+mjEk+k1Jr3QlX+d7kMhragADEPGw5KbVai+Yi0T/JKSfq/ 3dd6fJ3iKUX34eILQGnbvxZGw51duPK9tl6ziqVtjyCdWt9RCN3lds6mIKXUu8ivqvpv tMAMvoiUlHsH/IzUiUPgRpa32YN83MmUtEOePMMPKcJda8leiahvqNr5zMiXC7KdevSg 4zSPEL5O/tJ1ly3aeLJlcil6W85h0N0wSRqBTNBoKcbZE8Rdi3F3OQWuUmikD3QLqKem KEorxjhjaNvnd/+fm82pqIi+ikHifdnnlBjacvX3lhCnlp1Y25Y8lxfNbYGfnMv5vO1q 3ctA== MIME-Version: 1.0 X-Received: by 10.180.185.225 with SMTP id ff1mr5245237wic.36.1370886214115; Mon, 10 Jun 2013 10:43:34 -0700 (PDT) Received: by 10.216.63.136 with HTTP; Mon, 10 Jun 2013 10:43:33 -0700 (PDT) In-Reply-To: References: <51AF8479.5080002@crockford.com> <51b1168c.e686440a.5339.5fc4SMTPIN_ADDED_BROKEN@mx.google.com> <51B1B47C.9060009@drees.name> <51B1E909.2010402@drees.name> <51B1FE6A.80409@drees.name> <51B45FAA.4070900@drees.name> <62F282B7-11AA-44F8-A03B-201F2DAE51B5@vpnc.org> Date: Mon, 10 Jun 2013 12:43:33 -0500 Message-ID: From: Nico Williams To: Stephen Dolan Content-Type: text/plain; charset=UTF-8 Cc: Paul Hoffman , "json@ietf.org" Subject: Re: [Json] The names within an object SHOULD be unique. X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 10 Jun 2013 17:43:53 -0000 On Mon, Jun 10, 2013 at 12:08 PM, Stephen Dolan wrote: > On Mon, Jun 10, 2013 at 6:01 PM, Paul Hoffman wrote: >> >> >> On Jun 10, 2013, at 9:55 AM, Stephen Dolan wrote: >> >>> The issue is, that currently there exists a JSON document which one >>> RFC-conforming correct JSON parser can say is indistinguishable from >>> {a: true}, and another equally RFC-conforming correct JSON parser can >>> say is indistinguishable from {a: false}. >>> >>> While my example might not have been great, this still seems easily >>> exploitable: two parsers parsing a supposedly standard format can be >>> tricked into seeing completely different results from the same input. >>> Surely it would be better if we could say that one of those parsers >>> was not RFC-conforming? >> >> Stated that narrowly, yes. But given your first paragraph, the comparison might be >> more fully stated as "would it be better if we could says that one of these parsers was >> not RFC-conforming if making such a statement caused what was a stored valid >> JSON text now non-valid". > > I don't propose making any stored valid JSON text become non-valid. > {a: true, a: false} is currently a valid JSON text, and it should > remain so or things would break. > > Some JSON parsers consider that document distinguishable from {a: > false} (e.g. streaming parsers that return all key/value pairs). Most > of them don't. > > I propose that it be invalid to consider that document > indistinguishable from {a: true}. Parsers are free to accept or reject > it, and if they accept it they are free to return either one or two > "a" entries, but if they only return one it must be {a: false}. More briefly: {"a": true, "a": false} MAY be indistinguishable from either {"a": true, "a": false} or from {"a": false}, but MUST NOT be indistinguishable from {"a": true}. That would allow a streaming parser application like this: while ((name, value) = parser.nextPair()) { doCommand(name, value); } But not one like this, which I doubt anyone will argue should be allowed: while ((name, value) = parser.nextPair()) { if (hash[name]) continue; hash[name] = value; doCommand(name, value); } But what about this: while ((name, value) = parser.nextPair()) { if (hash[name]) throw "duplicate names!"; hash[name] = value; doCommand(name, value); } Here {"a": true, "a": false} would be distinguished from {"a": true} only by the error thrown, but the doCommand("a", true) action will have run. Is this invalidated by your construction? I think it's not, and one could make a reasonable argument that it should not be. (In particular {"a": true, "a": false, "b": null} would be equivalent to {"a": true} + an exception in this last case, but it would be distinct from {"a": true, "b": null}.) +1 from me. From cowan@ccil.org Mon Jun 10 10:50:51 2013 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 1417421F854E for ; Mon, 10 Jun 2013 10:50:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.396 X-Spam-Level: X-Spam-Status: No, score=-3.396 tagged_above=-999 required=5 tests=[AWL=0.203, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JCkr90DO9wfX for ; Mon, 10 Jun 2013 10:50:46 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id 92EF321F85F7 for ; Mon, 10 Jun 2013 10:50:42 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1Um6Em-0000Sm-La; Mon, 10 Jun 2013 13:50:36 -0400 Date: Mon, 10 Jun 2013 13:50:36 -0400 From: John Cowan To: Nico Williams Message-ID: <20130610175036.GB31359@mercury.ccil.org> References: <51B1E909.2010402@drees.name> <51B1FE6A.80409@drees.name> <51B45FAA.4070900@drees.name> <62F282B7-11AA-44F8-A03B-201F2DAE51B5@vpnc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Cc: Stephen Dolan , Paul Hoffman , "json@ietf.org" Subject: Re: [Json] The names within an object SHOULD be unique. X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 10 Jun 2013 17:50:51 -0000 Nico Williams scripsit: > But not one like this, which I doubt anyone will argue should be > allowed: > > while ((name, value) = parser.nextPair()) { > if (hash[name]) > continue; > hash[name] = value; > doCommand(name, value); > } I do argue that it should be allowed. Both "assume last" and "assume first", and for that matter "assume middle", are valid interpretations of RFC 4627, and ought to continue to be allowed. -- Ambassador Trentino: I've said enough. I'm a man of few words. Rufus T. Firefly: I'm a man of one word: scram! --Duck Soup John Cowan From stefan@drees.name Mon Jun 10 10:52:12 2013 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 622A521F8749 for ; Mon, 10 Jun 2013 10:52:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.092 X-Spam-Level: X-Spam-Status: No, score=-2.092 tagged_above=-999 required=5 tests=[AWL=0.157, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c3BMPEMO-RZC for ; Mon, 10 Jun 2013 10:52:06 -0700 (PDT) Received: from mout.web.de (mout.web.de [212.227.17.12]) by ietfa.amsl.com (Postfix) with ESMTP id 29C0B21F9953 for ; Mon, 10 Jun 2013 10:52:03 -0700 (PDT) Received: from newyork.local.box ([93.129.126.10]) by smtp.web.de (mrweb103) with ESMTPSA (Nemesis) id 0MBTIY-1Ubgeg2llO-00A7fS; Mon, 10 Jun 2013 19:51:57 +0200 Message-ID: <51B6123B.5010708@drees.name> Date: Mon, 10 Jun 2013 19:51:55 +0200 From: Stefan Drees User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Stephen Dolan References: <51AF8479.5080002@crockford.com> <51b1168c.e686440a.5339.5fc4SMTPIN_ADDED_BROKEN@mx.google.com> <51B1B47C.9060009@drees.name> <51B1E909.2010402@drees.name> <51B1FE6A.80409@drees.name> <51B45FAA.4070900@drees.name> <62F282B7-11AA-44F8-A03B-201F2DAE51B5@vpnc.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V02:K0:mfnvqEm2MxGgvA0MPopVecnJDrMDY2zPHkomfnZhGPn wwWWEzL8Inv8I+OednMuk6OI5QFSfQ95CSyVXsMSP+74m7e4d0 PTiNIiSIKiCNuhtdyn4vLYfGrMzqqXGSHXXpkVxwTakYxLJtMy Av/nC6igHkIAZe8WYndgs02oMYJDEPlPv2Ncmfif/kh7Gz1iYT UgJFK1ntE4/YXOGzfluDA== Cc: Paul Hoffman , "json@ietf.org" Subject: Re: [Json] The names within an object SHOULD be unique. X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stefan@drees.name List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jun 2013 17:52:12 -0000 On 2013-06-10 19:08 CEST, Stephen Dolan wrote: > On Mon, Jun 10, 2013 at 6:01 PM, Paul Hoffman ... wrote: >> >> >> On Jun 10, 2013, at 9:55 AM, Stephen Dolan ... wrote: >> >>> The issue is, that currently there exists a JSON document which one >>> RFC-conforming correct JSON parser can say is indistinguishable from >>> {a: true}, and another equally RFC-conforming correct JSON parser can >>> say is indistinguishable from {a: false}. >>> >>> While my example might not have been great, this still seems easily >>> exploitable: two parsers parsing a supposedly standard format can be >>> tricked into seeing completely different results from the same input. >>> Surely it would be better if we could say that one of those parsers >>> was not RFC-conforming? >> >> Stated that narrowly, yes. But given your first paragraph, the comparison might be >> more fully stated as "would it be better if we could says that one of these parsers was >> not RFC-conforming if making such a statement caused what was a stored valid >> JSON text now non-valid". > > I don't propose making any stored valid JSON text become non-valid. > {a: true, a: false} is currently a valid JSON text, and it should > remain so or things would break. > > Some JSON parsers consider that document distinguishable from {a: > false} (e.g. streaming parsers that return all key/value pairs). Most > of them don't. > > I propose that it be invalid to consider that document > indistinguishable from {a: true}. Parsers are free to accept or reject > it, and if they accept it they are free to return either one or two > "a" entries, but if they only return one it must be {a: false}. ... I presume, that if round-tripping - that is taking the "JSONing" as reversible operation for whatever is deemed important to keep intact over multiple encode-decode cycles - would have been a concern, this somehow would have been noted in the JSON RFC right from the start ;-) In the current discussions I see a lot of focus on the transformation from JSON text into some storage structure of another representation motivated by consequences thereof. If I take eg. a conforming JSON parser that keeps even the duplicated entries inside a map in the parsers implementation "private representation" and than let it act - say as a proxy - and generate "matching" JSON text from that again, it is perfectly valid and ok to receive: {a: true, a: false} parse this (i.e. store) and emit as (re-)generated JSON text (forward): {a: false, a: true} Right :-?) There is some traditional asymmetry of "interest" comparing: A) Private Storage Representation of Generator and B) Private Storage Representation of Parser Isn't it? It looks more like JSON text is "simply found" as the interchange of the JSON represented data is the emphasis not the initial transformation of whatever that lead to the JSON text in the first place. So I think what generators MAY introduce as indeterminism into the conversion (since years), the parsers will have to deal with (wishes aside). Setting all "hope" on this weak ordering assumption leading to the concept of a "last" entry, which breaks down in the proxy sample given above, might be misleading. Please note, that I do believe, that the discussions transported through all these - I guess already - 300000 words exchanged back and forth in the endeavour to apply some cosmetics to the 2000 words RFC are of sufficient value for everyone participating :-) Stefan. From nico@cryptonector.com Mon Jun 10 11:00:59 2013 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 09CE021F9976 for ; Mon, 10 Jun 2013 11:00:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GQbvOt2h4yaA for ; Mon, 10 Jun 2013 11:00:53 -0700 (PDT) Received: from homiemail-a26.g.dreamhost.com (caiajhbdcaid.dreamhost.com [208.97.132.83]) by ietfa.amsl.com (Postfix) with ESMTP id 0AB3D21F9968 for ; Mon, 10 Jun 2013 11:00:52 -0700 (PDT) Received: from homiemail-a26.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a26.g.dreamhost.com (Postfix) with ESMTP id A0B14B8058 for ; Mon, 10 Jun 2013 11:00:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=QFIGNW5LDUmWoG+vi8ZB 4e4p3ZA=; b=tGsdnA/BcOjqmBd0Kbz46L27FZIyeh2QRlr1XmWXzPf2hq/0DoLu tXMM34rZymcN1afGsR9PH2eEKighFohxkXsXwqetPQPIUKMF16ZWhkH6VYpIvfdz Osr+jfdqg+OK6v0GONiD/LtxTXq0IuxqCzvbX6RVLyFNA88fVi/JB6w= Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a26.g.dreamhost.com (Postfix) with ESMTPSA id 4D86BB8057 for ; Mon, 10 Jun 2013 11:00:51 -0700 (PDT) Received: by mail-wi0-f182.google.com with SMTP id m6so1172200wiv.15 for ; Mon, 10 Jun 2013 11:00:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=GXniu/qfZVoeIG8O8PZLOQCi4BWc/oKS461QIQsfNc8=; b=FlQ+HPvQJr8iVFWTC0XuvhIZODMh0oIeJvgBx91yZJ9Dayv5qP2VjTpXuWzk+sKx2o kAjCK3HOHA5sdi2ArLJ+Tb8AsOJOTodhF8ltWcCOPFXoqIwImw4nGIfHSeu6f7+D7cgf e27le064XY/wLSOGeLkqgeEbK3Yow0W0IFL+NqoqcaY6op+X9ctY/T2EMS6X6yVMUGfE 4Eft7zbgFIGkQxsIUT/23ucMbx48wmASgcTDU5YWk6q5x6V7T2FZ7rJKIUjCkCLXo/rL 5k8bV94yzbnjFEY6UUjuW8UrI1C/wqLUsUkE7VH0XJ+yg/hoHie5nSv8TBwc1hdANcI3 uGTw== MIME-Version: 1.0 X-Received: by 10.180.90.164 with SMTP id bx4mr5327295wib.13.1370887249671; Mon, 10 Jun 2013 11:00:49 -0700 (PDT) Received: by 10.216.63.136 with HTTP; Mon, 10 Jun 2013 11:00:49 -0700 (PDT) In-Reply-To: <8512D965-C32C-4C69-A709-350333C925A0@vpnc.org> References: <51B58261.5040808@drees.name> <8512D965-C32C-4C69-A709-350333C925A0@vpnc.org> Date: Mon, 10 Jun 2013 13:00:49 -0500 Message-ID: From: Nico Williams To: Paul Hoffman Content-Type: text/plain; charset=UTF-8 Cc: stefan@drees.name, "json@ietf.org" Subject: Re: [Json] Generators X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 10 Jun 2013 18:00:59 -0000 On Mon, Jun 10, 2013 at 12:35 PM, Paul Hoffman wrote: > > On Jun 10, 2013, at 12:38 AM, Stefan Drees wrote: >> Generators MUST NOT duplicate names in objects if they can avoid or >> detect such duplication. > > +1 to the others who have said "yuck" to the poor use of 2119 MUST here. Further, this is a significant change from both RFC 4726 and ECMAScript. Proposed new wording: Agreed. If we want a MUST then we need to distinguish types of encoders/parsers ("non-streaming ... MUST ...; streaming ... MAY/SHOULD ..."). That, I think, is why it might be valuable to distinguish types of encoders/parsers: so we can apply requirements to one common implementation type that we cannot to the other. The RFC2119 approach to this is to say SHOULD/SHOULD NOT and explain what exceptions might be made. Six of one, half a dozen of the other... I'd prefer a construction that ends up having a MUST because I suspect it will be understood more readily by future implementors, but either construction will do in the end. Although, to be extra careful here, since this sub-thread is about encoders, I'm not sure that a non-streaming encoder can be expected to detect duplicates in a has table (which would normally be an error at insertion time, but let's say it's happened). And so perhaps we can't really distinguish *encoder* types, only parser types. Nico -- From nico@cryptonector.com Mon Jun 10 11:04:35 2013 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 6DE7321F9990 for ; Mon, 10 Jun 2013 11:04:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.958 X-Spam-Level: X-Spam-Status: No, score=-1.958 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WhmMUK7+rt3Z for ; Mon, 10 Jun 2013 11:04:28 -0700 (PDT) Received: from homiemail-a66.g.dreamhost.com (caiajhbdcaid.dreamhost.com [208.97.132.83]) by ietfa.amsl.com (Postfix) with ESMTP id BA00F21F9995 for ; Mon, 10 Jun 2013 11:04:28 -0700 (PDT) Received: from homiemail-a66.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a66.g.dreamhost.com (Postfix) with ESMTP id 8C40F350079 for ; Mon, 10 Jun 2013 11:04:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=K7MJVs3Ea/uGP5AZT1RR 6N25rMc=; b=QJIGWvkGZ7ZA8rVEwmsXzi1aKXihZBy4bifd57s+W/+3MVb1UwN+ 5O+hSTu/s1OP5wtTs/jMglRiLQHx7azk4RtPwopeEMhd8OhDy5APkwXKo/PMNL1l Ez/8TorWMR1IyaN/N7QeP6T01gn6s8IYMYDgd7sIfFblPzWshyoz/Ng= Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a66.g.dreamhost.com (Postfix) with ESMTPSA id 3FA48350078 for ; Mon, 10 Jun 2013 11:04:28 -0700 (PDT) Received: by mail-wg0-f50.google.com with SMTP id k13so5204089wgh.29 for ; Mon, 10 Jun 2013 11:04:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=30gigOWwINjZYo7xcr2ufggJqjpyITXT761fh7I2ogY=; b=l3IhaoN0/Gj+/d9O68M5CNrv5IahrefZwDEml4SeCrkBHnZcwxr1p47FPMWmwe+gYl 41vypJA/wNFEj0/C3vI5tCEwyxQ5uQ20fJctKDt6lUmNvwMbXvXuW7u3/3GkdB2SS6li iJouOSZEE24TWo18+8eNnMss+//WdEvq25p+izA8GZIIqYIaZFURiLZvETc9BTtCCPYJ 23Av2suAuMnc5nQa/yfZYQtfJ5emhvSPhNhi25Cq+MGu5eKIYRRxjchsX7NulMjuP1Vj X0IcdC5+U2HDFLsZj7tLZ1DqXTlAbrSEI19tWjnbYTJXw3RA47YjwCtbtas4e6AhJVvC kQsA== MIME-Version: 1.0 X-Received: by 10.180.90.164 with SMTP id bx4mr5334704wib.13.1370887466978; Mon, 10 Jun 2013 11:04:26 -0700 (PDT) Received: by 10.216.63.136 with HTTP; Mon, 10 Jun 2013 11:04:26 -0700 (PDT) In-Reply-To: <20130610175036.GB31359@mercury.ccil.org> References: <51B1E909.2010402@drees.name> <51B1FE6A.80409@drees.name> <51B45FAA.4070900@drees.name> <62F282B7-11AA-44F8-A03B-201F2DAE51B5@vpnc.org> <20130610175036.GB31359@mercury.ccil.org> Date: Mon, 10 Jun 2013 13:04:26 -0500 Message-ID: From: Nico Williams To: John Cowan Content-Type: text/plain; charset=UTF-8 Cc: Stephen Dolan , Paul Hoffman , "json@ietf.org" Subject: Re: [Json] The names within an object SHOULD be unique. X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 10 Jun 2013 18:04:35 -0000 On Mon, Jun 10, 2013 at 12:50 PM, John Cowan wrote: > Nico Williams scripsit: > >> But not one like this, which I doubt anyone will argue should be >> allowed: >> >> while ((name, value) = parser.nextPair()) { >> if (hash[name]) >> continue; >> hash[name] = value; >> doCommand(name, value); >> } > > I do argue that it should be allowed. Both "assume last" and "assume > first", and for that matter "assume middle", are valid interpretations > of RFC 4627, and ought to continue to be allowed. I'm OK with disallowing the above, but if we can't get consensus even on that then what we should do is leave the original text as it was and move this discussion to the Security Considerations section (to point out the risks) and the best practices document (to say "best practice is not to do this"). From cromis@gmail.com Mon Jun 10 12:33:23 2013 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 45BBE21F9AD2 for ; Mon, 10 Jun 2013 12:33:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9nxS-jUnAJS0 for ; Mon, 10 Jun 2013 12:33:17 -0700 (PDT) Received: from mail-qe0-f53.google.com (mail-qe0-f53.google.com [209.85.128.53]) by ietfa.amsl.com (Postfix) with ESMTP id C1ACF21F9AD3 for ; Mon, 10 Jun 2013 12:33:16 -0700 (PDT) Received: by mail-qe0-f53.google.com with SMTP id 1so4255686qee.26 for ; Mon, 10 Jun 2013 12:33:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=DI+PZ7wxbaphnNOP1BZSm+8yDKTf/oTUUzuedtVGFB4=; b=1CJr7lBf2ArsExN4n1TNCU6sIawRJ4BU9TVfkxDBlYJjTS0xC964mqOpMqaNJAvJpO Hsf9sdbwrfqaBOr8vncJZtQdMTTV4u/2LG+BlVG80ns4dPrlaT0drS4fAhX5zyjXOcUy eBuxPG/T0mVXTAGXbN7exNJidJyIZL/q7Vsc4OgtPFnyiQrCBov+SSF2kWfBFWLNG7ba 0ILqFGafftxvCiMoF5N/J3uWSLBaDnM4V9tp1RIA0t+n4tovNXc0gLAkssIZ/dLEew48 oxqzQb/xFtTlsx09PssYhL7iA8Xs8pwc7aXfFaVN8T/qkNK3LYpjpBg30dMgyvhWrU2o zZ3Q== X-Received: by 10.224.11.199 with SMTP id u7mr15119538qau.76.1370892796268; Mon, 10 Jun 2013 12:33:16 -0700 (PDT) MIME-Version: 1.0 Sender: cromis@gmail.com Received: by 10.49.106.228 with HTTP; Mon, 10 Jun 2013 12:32:55 -0700 (PDT) In-Reply-To: <51b507b1.c686e00a.3a7e.ffffa0adSMTPIN_ADDED_BROKEN@mx.google.com> References: <51b23e6d.6196420a.0b15.4245SMTPIN_ADDED_BROKEN@mx.google.com> <51b4dbbe.64da440a.1fc2.6dd2SMTPIN_ADDED_BROKEN@mx.google.com> <51b4ec44.ea05420a.7c73.ffffa487SMTPIN_ADDED_BROKEN@mx.google.com> <51b507b1.c686e00a.3a7e.ffffa0adSMTPIN_ADDED_BROKEN@mx.google.com> From: Jacob Davies Date: Mon, 10 Jun 2013 12:32:55 -0700 X-Google-Sender-Auth: VwSlFKU7qIjCltKg7DpN4PRo2nc Message-ID: To: Markus Lanthaler Content-Type: text/plain; charset=ISO-8859-1 Cc: "json@ietf.org" Subject: Re: [Json] Allow any JSON value at the top level X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 10 Jun 2013 19:33:23 -0000 Lots of people do this, in my experience, including me pretty often. The original specification has an asymmetry in what values may be sent at the top level motivated by an encoding-detection scheme that is now obsolete. Some people seem to like it because composite values are a good idea for top-level payloads, but if that were the case one ought to object on similar principle to any value that does not permit further arbitrary sub-structure (like a number). Sometimes a number is just a number. And arrays are a poor choice for arbitrarily complex metadata anyway. The big problem with the current requirement is that arbitrary sub-values of a JSON value cannot be sent as application/json. So for instance, if you wish to implement a form of PATCH on a JSON document, you must demand that clients wrap their new value in a JSON object or array instead of sending raw primitive values. If you implement a service returning an inherently primitive value (e.g. a plain-text document server) you must wrap your responses in a JSON object or array even though there is nothing else that could reasonably be added. A system designer might be justified in saying that every response is an object, but the spec shouldn't dictate what is really a matter of taste (use of in-band rather than out-of-band metadata). On Sun, Jun 9, 2013 at 3:54 PM, Markus Lanthaler wrote: > On Sunday, June 09, 2013 11:06 PM, R S wrote: >>> Why can't a separate media type, e.g., application/json-value, >>> be defined allowing this? >> >> We could do that, but it might be a bit pointless. It won't change >> the fact that primitive values are already sent as application/json. > > Who's doing that? > > > -- > Markus Lanthaler > @markuslanthaler > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json From cabo@tzi.org Mon Jun 10 13:09:24 2013 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 27C7D21F8616 for ; Mon, 10 Jun 2013 13:09:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.973 X-Spam-Level: X-Spam-Status: No, score=-105.973 tagged_above=-999 required=5 tests=[AWL=-0.024, BAYES_00=-2.599, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 89Z-9+DFGAqs for ; Mon, 10 Jun 2013 13:09:18 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 0E16321F854E for ; Mon, 10 Jun 2013 13:09:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r5AK990d014818; Mon, 10 Jun 2013 22:09:09 +0200 (CEST) Received: from [192.168.217.135] (p54893267.dip0.t-ipconnect.de [84.137.50.103]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id AB3873FB1; Mon, 10 Jun 2013 22:09:08 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <51B19672.8040706@it.aoyama.ac.jp> Date: Mon, 10 Jun 2013 22:09:07 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <403AD068-4C78-4DB1-B8D4-30267B98C831@tzi.org> References: <255B9BB34FB7D647A506DC292726F6E1151B21F79E@WSMSG3153V.srv.dir.telstra.com> <255B9BB34FB7D647A506DC292726F6E1151B21F8CA@WSMSG3153V.srv.dir.telstra.com> <51B17E54.9030107@drees.name> <51B19672.8040706@it.aoyama.ac.jp> To: =?iso-8859-1?Q?Martin_J=2E_D=FCrst?= X-Mailer: Apple Mail (2.1508) Cc: "Manger, James H" , stefan@drees.name, "Joe Hildebrand \(jhildebr\)" , "json@ietf.org" Subject: Re: [Json] ABNF nits X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 10 Jun 2013 20:09:24 -0000 On Jun 7, 2013, at 10:14, Martin J. D=FCrst = wrote: > Another way to do this is to just note that you are using ABNF *except = that literals are case-sensitive*. I'm sure there's an RFC or two which = have done so. And, for your merriment, here is the right way to do this (RFC 4997): ; case-sensitive literals C =3D %d67 COMPRESSED =3D %d67.79.77.80.82.69.83.83.69.68 CONTROL =3D %d67.79.78.84.82.79.76 DEFAULT =3D %d68.69.70.65.85.76.84 ENFORCE =3D %d69.78.70.79.82.67.69 INITIAL =3D %d73.78.73.84.73.65.76 LENGTH =3D %d76.69.78.71.84.72 THIS =3D %d84.72.73.83 U =3D %d85 UNCOMPRESSED =3D %d85.78.67.79.77.80.82.69.83.83.69.68 VALUE =3D %d86.65.76.85.69 VARIABLE =3D %d86.65.82.73.65.66.76.69 false =3D %d102.97.108.115.101 true =3D %d116.114.117.101 (Yes, I automatically generated that ABNF from the list of literals.) Gr=FC=DFe, Carsten From cowan@ccil.org Mon Jun 10 13:17:58 2013 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 B03B221E80A1 for ; Mon, 10 Jun 2013 13:17:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.403 X-Spam-Level: X-Spam-Status: No, score=-3.403 tagged_above=-999 required=5 tests=[AWL=0.196, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0FBrAbNp0D4k for ; Mon, 10 Jun 2013 13:17:54 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id 33C5821F9A14 for ; Mon, 10 Jun 2013 13:17:48 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1Um8XC-0007fk-7Q; Mon, 10 Jun 2013 16:17:46 -0400 Date: Mon, 10 Jun 2013 16:17:46 -0400 From: John Cowan To: Jacob Davies Message-ID: <20130610201746.GC1057@mercury.ccil.org> References: <51b23e6d.6196420a.0b15.4245SMTPIN_ADDED_BROKEN@mx.google.com> <51b4dbbe.64da440a.1fc2.6dd2SMTPIN_ADDED_BROKEN@mx.google.com> <51b4ec44.ea05420a.7c73.ffffa487SMTPIN_ADDED_BROKEN@mx.google.com> <51b507b1.c686e00a.3a7e.ffffa0adSMTPIN_ADDED_BROKEN@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Cc: Markus Lanthaler , "json@ietf.org" Subject: Re: [Json] Allow any JSON value at the top level X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 10 Jun 2013 20:17:58 -0000 Jacob Davies scripsit: > The original specification has an asymmetry in what values may be sent > at the top level motivated by an encoding-detection scheme that is now > obsolete. How do we know what the motivation is? I think the self-delimiting nature is more important. In any case, even if numbers, strings, booleans, and null were allowed at the top level, all application/json entity bodies would still begin with a non-null ASCII character, which is sufficient for encoding detection. -- John Cowan cowan@ccil.org http://ccil.org/~cowan Any sufficiently-complicated C or Fortran program contains an ad-hoc, informally-specified bug-ridden slow implementation of half of Common Lisp. --Greenspun's Tenth Rule of Programming (rules 1-9 are unknown) From sgbeal@googlemail.com Mon Jun 10 13:18:27 2013 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 F2F1E21E80A1 for ; Mon, 10 Jun 2013 13:18:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.589 X-Spam-Level: X-Spam-Status: No, score=-1.589 tagged_above=-999 required=5 tests=[AWL=0.388, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wbLrFwDHNEAd for ; Mon, 10 Jun 2013 13:18:25 -0700 (PDT) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) by ietfa.amsl.com (Postfix) with ESMTP id 497F821E80A4 for ; Mon, 10 Jun 2013 13:18:25 -0700 (PDT) Received: by mail-wi0-f177.google.com with SMTP id ey16so3497929wid.4 for ; Mon, 10 Jun 2013 13:18:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=hZmB6pKTAniqAzWNKAa483YxJJrkUkS/Kt2cC/4YNGc=; b=P+nJ1KiXsVFynvHetEQQvLrSTvANWqxhRoNoeLZPs09L72RFhMx3hWnQ0pi1DwGsQn zjWE79Hhu3Ny6o+zBeo+7onxY+Yhn1BLuZmluziPLF29Y9iKgaSWBBaIp5u1yemkGdzf SSMpbbxFrCQxRD37hrskynHEZmrWSLL3pDYC1yDtKv3bpVeMi8JE6oe0xw6VE0gXaqJk RBYDJ9AJW8rImPHuVVz+A61AQPLR2SsGZujC+HBqFRJSHFaw2JiSr8j9lGbYxGWI6SAE +YDhSBRZG9rE5IWOot+YM9EantGVv+kFhy451Kmhd0cFITSWm4dEJFbaRbNc9xGaGzt5 //Bg== MIME-Version: 1.0 X-Received: by 10.180.212.74 with SMTP id ni10mr5655861wic.41.1370895499430; Mon, 10 Jun 2013 13:18:19 -0700 (PDT) Received: by 10.194.42.230 with HTTP; Mon, 10 Jun 2013 13:18:19 -0700 (PDT) In-Reply-To: References: <51B1E909.2010402@drees.name> <51B1FE6A.80409@drees.name> <51B45FAA.4070900@drees.name> <62F282B7-11AA-44F8-A03B-201F2DAE51B5@vpnc.org> <20130610175036.GB31359@mercury.ccil.org> Date: Mon, 10 Jun 2013 22:18:19 +0200 Message-ID: From: Stephan Beal To: "json@ietf.org" Content-Type: multipart/alternative; boundary=001a11c363ba44959904ded27be6 Subject: Re: [Json] The names within an object SHOULD be unique. X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 10 Jun 2013 20:18:27 -0000 --001a11c363ba44959904ded27be6 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Jun 10, 2013 at 8:04 PM, Nico Williams wrote: > I'm OK with disallowing the above, but if we can't get consensus even > on that then what we should do is leave the original text as it was > and move this discussion to the Security Considerations section (to > point out the risks) and the best practices document (to say "best > practice is not to do this"). > That also has the strong advantage of not upsetting anyone (==implementors) who isn't already upset by the status quo (and i haven't seen any posts suggesting that the status quo is fundamentally broken). -- ----- stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal --001a11c363ba44959904ded27be6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Mon, Jun 10, 2013 at 8:04 PM, Nico Williams <nic= o@cryptonector.com> wrote:
I'm OK with disallowing the above, but if we can't get co= nsensus even
on that then what we should do is leave the original text as it was
and move this discussion to the Security Considerations section (to
point out the risks) and the best practices document (to say "best
practice is not to do this").

That also has the strong advantage of not upsetting anyone (=3D=3Dimpleme= ntors) who isn't already upset by the status quo (and i haven't see= n any posts suggesting that the status quo is fundamentally broken).

--
----- stephan beal
http://wanderinghorse.net/home= /stephan/
--001a11c363ba44959904ded27be6-- From mamille2@cisco.com Mon Jun 10 13:23:08 2013 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 7C8A621E8056 for ; Mon, 10 Jun 2013 13:23:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GPKWbBu0uKiT for ; Mon, 10 Jun 2013 13:23:03 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id ABFE621F9A1A for ; Mon, 10 Jun 2013 13:23:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6497; q=dns/txt; s=iport; t=1370895782; x=1372105382; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=hnFXShP3nrc344PpGerP/boAPT5ZIE6A/fI3Qe5YTqo=; b=K17WkgdxrJ3/Sa0wBnupQUCNhrKY5p9uvYFyOdbKeHePWE+PzFmgRtIV CGxKMXIlxEhFpdzKdwBDHf5gzrfFqxkNYSrWBVlhK21IV0aBDfnfQ4hZR xHHlldHJIHu5Lp8YISx29mITGwIjqyPiB+xhQy2EUshsdrwWRQqoFPffW c=; X-Files: smime.p7s : 4136 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aq0GAFc0tlGtJV2c/2dsb2JhbABZgwl5vkSBBRZtB4IkAQEEHWwCAQgiJAIwJQIEGwaHf7lujwc4gn9hA5ABgSyXVYMPgic X-IronPort-AV: E=Sophos;i="4.87,840,1363132800"; d="p7s'?scan'208";a="221059712" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-8.cisco.com with ESMTP; 10 Jun 2013 20:22:59 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r5AKMwwR006396 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 10 Jun 2013 20:22:58 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.24]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.02.0318.004; Mon, 10 Jun 2013 15:22:58 -0500 From: "Matt Miller (mamille2)" To: "json@ietf.org" Thread-Topic: [Json] Proposed change to the title of the spec - LAST CHANCE ON PROPOSALS Thread-Index: AQHOZhhLYQIN4II3zka0SOV93eR4qw== Date: Mon, 10 Jun 2013 20:22:57 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.129.24.59] Content-Type: multipart/signed; boundary="Apple-Mail=_80FC0520-D1B3-4F4A-BE45-5E21CEC19464"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Subject: Re: [Json] Proposed change to the title of the spec - LAST CHANCE ON PROPOSALS X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 10 Jun 2013 20:23:08 -0000 --Apple-Mail=_80FC0520-D1B3-4F4A-BE45-5E21CEC19464 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hello all, This is your last chance for proposing changes to the document title. If = anyone has additional proposals, please send them to the list as soon as = possible. The chairs will be calling for consensus presently. Here are the proposals we have so far: #1) Leave document as-is #2) The JSON Data Interchange Format #3) The JSON Format for Encoding Data Thanks, Matt Miller & Paul Hoffman= --Apple-Mail=_80FC0520-D1B3-4F4A-BE45-5E21CEC19464 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMezCCBjQw ggQcoAMCAQICAR4wDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDE1NVoX DTE3MTAyNDIxMDE1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMcJg8zOLdgasSmkLhOrlr6KMoOMpohBllVHrdRvEg/q6r8jR+EK 75xCGhR8ToREoqe7zM9/UnC6TS2y9UKTpT1v7RSMzR0t6ndl0TWBuUr/UXBhPk+Kmy7bI4yW4urC +y7P3/1/X7U8ocb8VpH/Clt+4iq7nirMcNh6qJR+xjOhV+VHzQMALuGYn5KZmc1NbJQYclsGkDxD z2UbFqE2+6vIZoL+jb9x4Pa5gNf1TwSDkOkikZB1xtB4ZqtXThaABSONdfmv/Z1pua3FYxnCFmdr /+N2JLKutIxMYqQOJebr/f/h5t95m4JgrM3Y/w7YX9d7YAL9jvN4SydHsU6n65cCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRTcu2SnODaywFc fH6WNU7y1LhRgjAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBAAqDCH14qywG XLhjjF6uHLkjd02hcdh9hrw+VUsv+q1eeQWB21jWj3kJ96AUlPCoEGZ/ynJNScWy6QMVQjbbMXlt UfO4n4bGGdKo3awPWp61tjAFgraLJgDk+DsSvUD6EowjMTNx25GQgyYJ5RPIzKKR9tQW8gGK+2+R HxkUCTbYFnL6kl8Ch507rUdPPipJ9CgJFws3kDS3gOS5WFMxcjO5DwKfKSETEPrHh7p5shuuNktv sv6hxHTLhiMKX893gxdT3XLS9OKmCv87vkINQcNEcIIoFWbP9HORz9v3vQwR4e3ksLc2JZOAFK+s sS5XMEoznzpihEP0PLc4dCBYjbvSD7kxgDwZ+Aj8Q9PkbvE9sIPP7ON0fz095HdThKjiVJe6vofq +n6b1NBc8XdrQvBmunwxD5nvtTW4vtN6VY7mUCmxsCieuoBJ9OlqmsVWQvifIYf40dJPZkk9YgGT zWLpXDSfLSplbY2LL9C9U0ptvjcDjefLTvqSFc7tw1sEhF0n/qpA2r0GpvkLRDmcSwVyPvmjFBGq Up/pNy8ZuPGQmHwFi2/14+xeSUDG2bwnsYJQG2EdJCB6luQ57GEnTA/yKZSTKI8dDQa8Sd3zfXb1 9mOgSF0bBdXbuKhEpuP9wirslFe6fQ1t5j5R0xi72MZ8ikMu1RQZKCyDbMwazlHiMIIGPzCCBSeg AwIBAgIDBoRIMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcN MTMwNDMwMjE1NDQyWhcNMTQwNTAyMDUzOTA0WjBbMRkwFwYDVQQNExBiN2F6NndOY0t0R3JtMEpF MRswGQYDVQQDDBJtYW1pbGxlMkBjaXNjby5jb20xITAfBgkqhkiG9w0BCQEWEm1hbWlsbGUyQGNp c2NvLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJbKBMsG+9UFTx9uq/bhhXgu vJvO8z7cwKaqqwZhVf5z/kHFyCNijtmTOE+YXjA8mWR4aoBwB5SvGypI/cJUofJ+AlBTC4g+RMx/ K0Ab4/jQqTQz9CDzMOB+Wm+rt8ZJ7A8ZzOJmNDAsf/VvB8l2A1SQz1UsAixgH16NTr8SlblAXEKk 4hwpCudUiNjjQokqJ0H686UBKVorcZSgXaza8XMqGtJF/8mNhR9GQYi7Xht1ky+9LFOrto2daZto KJRwMeVusVdHUeKEQSu7jztw8HchH3KEb7Q+r5X+hhDZoddfKE8d5eyPuhiZdrzv7OlNZ0fSLdx7 3AE3nx9/R5YlXucCAwEAAaOCAtgwggLUMAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQW MBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQUxGd+/qrdVudHrIKkw5xOMY7eaLUwHwYD VR0jBBgwFoAUU3Ltkpzg2ssBXHx+ljVO8tS4UYIwHQYDVR0RBBYwFIESbWFtaWxsZTJAY2lzY28u Y29tMIIBTAYDVR0gBIIBQzCCAT8wggE7BgsrBgEEAYG1NwECAzCCASowLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0 Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBp c3N1ZWQgYWNjb3JkaW5nIHRvIHRoZSBDbGFzcyAxIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9m IHRoZSBTdGFydENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBw dXJwb3NlIGluIGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMDYG A1UdHwQvMC0wK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUxLWNybC5jcmwwgY4G CCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIv Y2xhc3MxL2NsaWVudC9jYTBCBggrBgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2Vy dHMvc3ViLmNsYXNzMS5jbGllbnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRz c2wuY29tLzANBgkqhkiG9w0BAQUFAAOCAQEAlDhXbGEI7lbqUcu5r2JHZaMsbRZda/99ZqODzWGX 0llou9jGccsAWDPPwRRe2+ROpXfH4cuJZElTcLDeZSp/qpXKhjYieFSX8+Ml9sKEj5UOSqQLyoLk PtrIJV12Jk3nuG2Jc0UeEnGwK/aqtzy7+bfEVI0ziyVM2gChHh0RH74KyiwYWknbOTRIkZcz/ulE DVFQp63uj6wfmDNvAUHBAdhKVqA1S/rfP1KcDZpf1NfvwXJibiqTRA6K1EOxTJOP41n/XdvHqHXL RWL2xrOUI9/URANr/ok3OrsuZEMFnAAGefS1bWS/hFtUGVkHGiKEBbyDW7da2ULXbuC7umrQnzGC A28wggNrAgEBMIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkG A1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwaESDAJBgUrDgMCGgUA oIIBrzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMzA2MTAyMDIy NTdaMCMGCSqGSIb3DQEJBDEWBBRi4M4Ma0ISilcy5UjWJrV9p4dD3jCBpQYJKwYBBAGCNxAEMYGX MIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3Mg MSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwaESDCBpwYLKoZIhvcNAQkQAgsxgZeg gZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1 cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAx IFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDBoRIMA0GCSqGSIb3DQEBAQUABIIBAA7J lm/H8jfnFQ+Sq192wQRYpMVevezWaetyCt/rc0oZS8A01BYBbXgg7n6NkaRmbxQurJGSC5KxPGzU 6WfUkdw7UuTUmN8q2os4hxFIHn9c8gKBYV/bPEhQT0+YoJlQtmzz+NuB4BPRjV7GSPhwCjgCD6AA AKpQ/mv7JR07/mDH0Px/dmWk3Baeng7HGoicDU9Z+OUOWoc/5KCo8tZ531NJAbLPR27CfFo4lZyx VAMansrzrBAVt0OpIHOUy06/eU650aze1dLJrF6WdCuVjASuOsW5kLQ0zN0O7IheVUyGEXFu0Qul OBz/rVjY3WPDGurXJTNey1WglgWav6hnfVcAAAAAAAA= --Apple-Mail=_80FC0520-D1B3-4F4A-BE45-5E21CEC19464-- From tbray@textuality.com Mon Jun 10 13:35:06 2013 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 3AFAF21F9A7D for ; Mon, 10 Jun 2013 13:35:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.48 X-Spam-Level: X-Spam-Status: No, score=0.48 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_PBL=0.905, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3WrgJfpX5hst for ; Mon, 10 Jun 2013 13:35:02 -0700 (PDT) Received: from mail-ve0-x22f.google.com (mail-ve0-x22f.google.com [IPv6:2607:f8b0:400c:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id EEDE521F8647 for ; Mon, 10 Jun 2013 13:34:55 -0700 (PDT) Received: by mail-ve0-f175.google.com with SMTP id da11so5087060veb.6 for ; Mon, 10 Jun 2013 13:34:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=KOZiUW9WyNhUGfe6pJnT0bNz5eYCxx6LzOXr347lpiw=; b=DAz/3ebXvWni807OU5vQJhWVceOWtTsztXUNR47YsjLuqHIrU8gXtxQE9tQppd6h0Q NjW1Iizhupxo8WRcw8HSvnyfyw4I4MbdJxWBNIeu8JJe9TaT8qwRvay2OGdXwxCX/HKA iZ1S+LMhRtFDn5A/MxqSSPou/gFSYiAW9i9t2YO3OE7AgrncaibAg1h+R7XhACnixiRQ A1aeucb7l3wUa0c1pBOubybWh4H6wLiddehkNtn9GLyk+Ql+5Bf8rV6+vcxrEGCmYyWv uCY2aGVPdAhSMNPkqjeTp6kMYKsfsyk1hRhU4EQ6WDXznnnjgl9dAqvGfucNHwy6BU0y ZXoA== MIME-Version: 1.0 X-Received: by 10.52.237.228 with SMTP id vf4mr5657844vdc.79.1370896495382; Mon, 10 Jun 2013 13:34:55 -0700 (PDT) Received: by 10.220.25.199 with HTTP; Mon, 10 Jun 2013 13:34:55 -0700 (PDT) X-Originating-IP: [24.114.40.223] Received: by 10.220.25.199 with HTTP; Mon, 10 Jun 2013 13:34:55 -0700 (PDT) In-Reply-To: References: Date: Mon, 10 Jun 2013 13:34:55 -0700 Message-ID: From: Tim Bray To: "Matt Miller, (mamille2)" Content-Type: multipart/alternative; boundary=089e0122f6aaa1be5804ded2b68f X-Gm-Message-State: ALoCoQm5olsls2g1LLoqkhIVfRplCHediOm25fMNmCGDg2lKxoEk470qdQhR7oZksbtdSbcRt/Cz Cc: json@ietf.org Subject: Re: [Json] Proposed change to the title of the spec - LAST CHANCE ON PROPOSALS X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 10 Jun 2013 20:35:06 -0000 --089e0122f6aaa1be5804ded2b68f Content-Type: text/plain; charset=UTF-8 I'm OK on #2 or #3 On Jun 10, 2013 1:23 PM, "Matt Miller (mamille2)" wrote: > Hello all, > > This is your last chance for proposing changes to the document title. If > anyone has additional proposals, please send them to the list as soon as > possible. The chairs will be calling for consensus presently. > > Here are the proposals we have so far: > > #1) Leave document as-is > > #2) The JSON Data Interchange Format > > #3) The JSON Format for Encoding Data > > > Thanks, > > Matt Miller & Paul Hoffman > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > > --089e0122f6aaa1be5804ded2b68f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

I'm OK on #2 or #3

On Jun 10, 2013 1:23 PM, "Matt Miller (mami= lle2)" <mamille2@cisco.com> wrote:
Hello all,

This is your last chance for proposing changes to the document title. If an= yone has additional proposals, please send them to the list as soon as poss= ible. =C2=A0The chairs will be calling for consensus presently.

Here are the proposals we have so far:

#1) =C2=A0Leave document as-is

#2) =C2=A0The JSON Data Interchange Format

#3) The JSON Format for Encoding Data


Thanks,

Matt Miller & Paul Hoffman
_________________________________________= ______
json mailing list
json@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/json

--089e0122f6aaa1be5804ded2b68f-- From stefan@drees.name Mon Jun 10 13:39:31 2013 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 035D121F9926 for ; Mon, 10 Jun 2013 13:39:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[AWL=0.151, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6BPBrd-EYl7e for ; Mon, 10 Jun 2013 13:39:25 -0700 (PDT) Received: from mout.web.de (mout.web.de [212.227.15.3]) by ietfa.amsl.com (Postfix) with ESMTP id E5E1721F848A for ; Mon, 10 Jun 2013 13:39:24 -0700 (PDT) Received: from newyork.local.box ([93.129.126.10]) by smtp.web.de (mrweb004) with ESMTPSA (Nemesis) id 0Mg1Nl-1UyZRu0TG1-00NRyF; Mon, 10 Jun 2013 22:39:23 +0200 Message-ID: <51B63979.40601@drees.name> Date: Mon, 10 Jun 2013 22:39:21 +0200 From: Stefan Drees User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "Matt Miller (mamille2)" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:0tVGXDioqYWpNq5yRq2nM969wVlh50KMEijoeBCVs2ceyps9YLZ L1UmQGbZ81LnDbcqAd6mx0y4Dl5dG9137Zn3etRyv5UcI1w6rSmIve5GJIhzB5LL9EvH7tg j+ZabxXtARmISFbh3Fc4pfZPPf3bUbLXMUWBwPAOweYvopjyipSYz82VPJ2lIXnZsYsVD0E nvezIK7c8qwXwb/E1cYwg== Cc: "json@ietf.org" Subject: Re: [Json] Proposed change to the title of the spec - LAST CHANCE ON PROPOSALS X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stefan@drees.name List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jun 2013 20:39:31 -0000 On 2013-06-10 22:22 CEST, Matt Miller wrote: > Hello all, > > This is your last chance for proposing changes to the document > title. > If anyone has additional proposals, please send them to the list as soon > as possible. The chairs will be calling for consensus presently. > > Here are the proposals we have so far: > > #1) Leave document as-is > > #2) The JSON Data Interchange Format > > #3) The JSON Format for Encoding Data > ... I thus hereby propose as new title: NEW: """ The JSON Text Format """ Rationale: The discussions on this list and daily experience make it clear to me, that both "encoding/decoding" and "data interchange" functionality of JSON are somehow working (even enabling a microscopic XML dialect ;-) but seem to promise more robustness and reproducability than can be spelled out with MUSTardy and without at least breaking someones pet toy, but one thing stands out and will remain: The JSON text was and ist the subject of this RFC, and the main ingredient should be clearly stated on the label, shouldn't it? All the best, Stefan Drees. From sayrer@gmail.com Mon Jun 10 13:40:47 2013 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 B6EDE21F9926 for ; Mon, 10 Jun 2013 13:40:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.422 X-Spam-Level: X-Spam-Status: No, score=-2.422 tagged_above=-999 required=5 tests=[AWL=0.177, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gEAd08iyKGQU for ; Mon, 10 Jun 2013 13:40:47 -0700 (PDT) Received: from mail-we0-x234.google.com (mail-we0-x234.google.com [IPv6:2a00:1450:400c:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id C8EB921F96DF for ; Mon, 10 Jun 2013 13:40:46 -0700 (PDT) Received: by mail-we0-f180.google.com with SMTP id w56so5131401wes.25 for ; Mon, 10 Jun 2013 13:40:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=/XoqtOtIL46UkILtMRFSMCiI6JQ3aDj2kmELg6uTERc=; b=I11mkS24C2OyrqTq/E2zjyDufhl7FLJeGyKJkhEHBAH3eMlpH3GO1+iAbeB++k8R+J /N6j6M1so+F3EdoU+KrUrh3hG0rfDHJV1u4k/HxVAs8rbMm6sm0ADntJ7xTx+IoOs2vh 4UTy56yokY4mgp5r5OD1MNJP7FB6HKDNkHJWts7uZhTbXa//lV0Oj8h9YnzmTKyrQrNF pgetk9aTgap1ydTfBqdF6w4PW9VVqWLGLagzqU57a6WvcB7hhmMyJ49F7m7DNy5EYshM lSRImivrzklDH5HB2kwzJxuI9sXjapXQByMDMbCL3NPHu0GD2czupZYVwE4b94Tgj/K6 NyGA== MIME-Version: 1.0 X-Received: by 10.194.86.106 with SMTP id o10mr6355528wjz.93.1370896845838; Mon, 10 Jun 2013 13:40:45 -0700 (PDT) Received: by 10.194.83.35 with HTTP; Mon, 10 Jun 2013 13:40:45 -0700 (PDT) In-Reply-To: References: Date: Mon, 10 Jun 2013 13:40:45 -0700 Message-ID: From: R S To: "Matt Miller (mamille2)" Content-Type: multipart/alternative; boundary=089e0102e0dc85214704ded2cbbc Cc: "json@ietf.org" Subject: Re: [Json] Proposed change to the title of the spec - LAST CHANCE ON PROPOSALS X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 10 Jun 2013 20:40:47 -0000 --089e0102e0dc85214704ded2cbbc Content-Type: text/plain; charset=ISO-8859-1 #2 - Rob On Mon, Jun 10, 2013 at 1:22 PM, Matt Miller (mamille2) wrote: > Hello all, > > This is your last chance for proposing changes to the document title. If > anyone has additional proposals, please send them to the list as soon as > possible. The chairs will be calling for consensus presently. > > Here are the proposals we have so far: > > #1) Leave document as-is > > #2) The JSON Data Interchange Format > > #3) The JSON Format for Encoding Data > > > Thanks, > > Matt Miller & Paul Hoffman > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > > --089e0102e0dc85214704ded2cbbc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
#2

- Rob


On Mon, Jun 10, 2013 at 1:22 PM,= Matt Miller (mamille2) <mamille2@cisco.com> wrote:
Hello all,

This is your last chance for proposing changes to the document title. If an= yone has additional proposals, please send them to the list as soon as poss= ible. =A0The chairs will be calling for consensus presently.

Here are the proposals we have so far:

#1) =A0Leave document as-is

#2) =A0The JSON Data Interchange Format

#3) The JSON Format for Encoding Data


Thanks,

Matt Miller & Paul Hoffman
_________________________________________= ______
json mailing list
json@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/json


--089e0102e0dc85214704ded2cbbc-- From waldron.rick@gmail.com Mon Jun 10 13:40:54 2013 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 0DC6321F96DF for ; Mon, 10 Jun 2013 13:40:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TWP8+XSx4QQ7 for ; Mon, 10 Jun 2013 13:40:49 -0700 (PDT) Received: from mail-vc0-f177.google.com (mail-vc0-f177.google.com [209.85.220.177]) by ietfa.amsl.com (Postfix) with ESMTP id C33FB21F9A9F for ; Mon, 10 Jun 2013 13:40:49 -0700 (PDT) Received: by mail-vc0-f177.google.com with SMTP id hv10so4744358vcb.22 for ; Mon, 10 Jun 2013 13:40:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=JBAytN2IXhZXCQz16nDskflJm/fEqcBZzYbeymstdcg=; b=vIAr4B5aPqqJ5JO/iAhMRGlSF7ANZEXrOnU4tt2PkmIGQg5xyeUD0Tq0l2mkoUgPp1 9S+JPFuKaoDwBEKa8/OSiWthJoPd5b1WV0LpUrVwEzL0xYeyeoImjrJfraQ++bxt5302 r86vQIEqhY/icNCseQQ2g+WDvxkLg38zZW7Ux00NOE0Ws7CxbMTvDTie4/l8PftUHhYN q4wlpgsiZXUirp9l0qtWwTMpV2+snUCKYTE2XxvO4eSEp82N/tYcsFDtDGrCxhJcSn+s sZBd36fC15+pyTtMviJ8ZSjwGnWblD+BPcasvo1tsvF3uhndWktTzmEefX4DLi+Kf7k+ 8oIA== X-Received: by 10.52.20.77 with SMTP id l13mr5756683vde.21.1370896849285; Mon, 10 Jun 2013 13:40:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.137.140 with HTTP; Mon, 10 Jun 2013 13:40:29 -0700 (PDT) In-Reply-To: References: From: Rick Waldron Date: Mon, 10 Jun 2013 16:40:29 -0400 Message-ID: To: "Matt Miller (mamille2)" Content-Type: multipart/alternative; boundary=20cf307cfd84b9c5c304ded2cbcf Cc: "json@ietf.org" Subject: Re: [Json] Proposed change to the title of the spec - LAST CHANCE ON PROPOSALS X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 10 Jun 2013 20:40:54 -0000 --20cf307cfd84b9c5c304ded2cbcf Content-Type: text/plain; charset=ISO-8859-1 On Mon, Jun 10, 2013 at 4:22 PM, Matt Miller (mamille2) wrote: > Hello all, > > This is your last chance for proposing changes to the document title. If > anyone has additional proposals, please send them to the list as soon as > possible. The chairs will be calling for consensus presently. > > Here are the proposals we have so far: > > #1) Leave document as-is > > #2) The JSON Data Interchange Format > #2 is the title used in ECMA-262, v5.1 Rick > > #3) The JSON Format for Encoding Data > > > Thanks, > > Matt Miller & Paul Hoffman > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > > --20cf307cfd84b9c5c304ded2cbcf Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Mon, Jun 10, 2013 at 4:22 PM, Matt Miller (mamille2) <mamill= e2@cisco.com> wrote:
Hello all,

This is your last chance for proposing changes to the document title. If an= yone has additional proposals, please send them to the list as soon as poss= ible. =A0The chairs will be calling for consensus presently.

Here are the proposals we have so far:

#1) =A0Leave document as-is

#2) =A0The JSON Data Interchange Format

#2 is the title used in ECMA-262, v5.1


Rick
=A0

#3) The JSON Format for Encoding Data


Thanks,

Matt Miller & Paul Hoffman
_________________________________________= ______
json mailing list
json@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/json


--20cf307cfd84b9c5c304ded2cbcf-- From paul.hoffman@vpnc.org Mon Jun 10 13:48:00 2013 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 046C321F9A3D for ; Mon, 10 Jun 2013 13:48:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.418 X-Spam-Level: X-Spam-Status: No, score=-102.418 tagged_above=-999 required=5 tests=[AWL=0.181, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a3uF2fFtolgf for ; Mon, 10 Jun 2013 13:47:59 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 46CFD21F9A3B for ; Mon, 10 Jun 2013 13:47:59 -0700 (PDT) Received: from [10.20.30.90] (50-0-66-165.dsl.dynamic.sonic.net [50.0.66.165]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r5AKlwlu052229 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 10 Jun 2013 13:47:58 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Paul Hoffman In-Reply-To: Date: Mon, 10 Jun 2013 13:47:57 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "json@ietf.org" X-Mailer: Apple Mail (2.1508) Subject: Re: [Json] Proposed change to the title of the spec - LAST CHANCE ON PROPOSALS X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 10 Jun 2013 20:48:00 -0000 On Jun 10, 2013, at 1:34 PM, Tim Bray wrote: > I'm OK on #2 or #3 Wait, stop. That's *not* what Matt asked. This is not a consensus call, = it is a request for proposals. Please respond if you cannot live with any of the proposal Matt listed = *and* you have one you think you could live with. --Paul Hoffman= From stefan@drees.name Mon Jun 10 13:58:08 2013 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 98B9621F997D for ; Mon, 10 Jun 2013 13:58:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.102 X-Spam-Level: X-Spam-Status: No, score=-2.102 tagged_above=-999 required=5 tests=[AWL=0.147, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 83oLUrAZ6Kv3 for ; Mon, 10 Jun 2013 13:58:02 -0700 (PDT) Received: from mout.web.de (mout.web.de [212.227.17.12]) by ietfa.amsl.com (Postfix) with ESMTP id 0E65021F9631 for ; Mon, 10 Jun 2013 13:58:01 -0700 (PDT) Received: from newyork.local.box ([93.129.126.10]) by smtp.web.de (mrweb102) with ESMTPSA (Nemesis) id 0MbyIM-1V2A6l3G0U-00JHqj; Mon, 10 Jun 2013 22:57:51 +0200 Message-ID: <51B63DCE.3010207@drees.name> Date: Mon, 10 Jun 2013 22:57:50 +0200 From: Stefan Drees User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Carsten Bormann References: <255B9BB34FB7D647A506DC292726F6E1151B21F79E@WSMSG3153V.srv.dir.telstra.com> <255B9BB34FB7D647A506DC292726F6E1151B21F8CA@WSMSG3153V.srv.dir.telstra.com> <51B17E54.9030107@drees.name> <51B19672.8040706@it.aoyama.ac.jp> <403AD068-4C78-4DB1-B8D4-30267B98C831@tzi.org> In-Reply-To: <403AD068-4C78-4DB1-B8D4-30267B98C831@tzi.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Provags-ID: V02:K0:JDnQuZ+tMKl9IN00wNX63tSqgxpcyy4owzSUdN8NOtq MFphgsRoetiIp8AmEEdIzfP+8A2zLrEnYkil0MENGaHC/+BuBq V4b3X+8EYVuTl3DnF7sId++D366y7h4onN5fhlek1ajxpZYF5/ 9T6hxIW3G8pjT8qnUjujFmvIO6mboiV68wNgf4lFfPYw1ejXaX 9GBeld9PeX0SLHVyd67tg== Cc: =?ISO-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= , "Manger, James H" , "Joe Hildebrand \(jhildebr\)" , "json@ietf.org" Subject: Re: [Json] ABNF nits X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stefan@drees.name List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jun 2013 20:58:08 -0000 On 2013-06-10 22:09 CEST, Carsten Bormann wrote: > On Jun 7, 2013, at 10:14, Martin J. Dürst ... wrote: > >> Another way to do this is to just note that you are using ABNF >> *except that literals are case-sensitive*. I'm sure there's an RFC or >> two which have done so. > > And, for your merriment, here is the right way to do this (RFC 4997): > > ; case-sensitive literals > C = %d67 > COMPRESSED = %d67.79.77.80.82.69.83.83.69.68 > CONTROL = %d67.79.78.84.82.79.76 > DEFAULT = %d68.69.70.65.85.76.84 > ENFORCE = %d69.78.70.79.82.67.69 > INITIAL = %d73.78.73.84.73.65.76 > LENGTH = %d76.69.78.71.84.72 > THIS = %d84.72.73.83 > U = %d85 > UNCOMPRESSED = %d85.78.67.79.77.80.82.69.83.83.69.68 > VALUE = %d86.65.76.85.69 > VARIABLE = %d86.65.82.73.65.66.76.69 > false = %d102.97.108.115.101 > true = %d116.114.117.101 > > (Yes, I automatically generated that ABNF from the list of literals.) shouldn't it say instead in productions 3 - 6: CONTROL = %d73.78.73.84.73.65.76 DEFAULT = %d67.79.78.84.82.79.76 ENFORCE = %d68.69.70.65.85.76.84 INITIAL = %d69.78.70.79.82.67.69 No, only joking, I feel quite cheerful now :-) Stefan. From nico@cryptonector.com Mon Jun 10 14:03:32 2013 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 A16BC21F8206 for ; Mon, 10 Jun 2013 14:03:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.959 X-Spam-Level: X-Spam-Status: No, score=-1.959 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YgVzsrk+EvQQ for ; Mon, 10 Jun 2013 14:03:27 -0700 (PDT) Received: from homiemail-a54.g.dreamhost.com (caiajhbdcagg.dreamhost.com [208.97.132.66]) by ietfa.amsl.com (Postfix) with ESMTP id 54CBA21F8618 for ; Mon, 10 Jun 2013 14:03:25 -0700 (PDT) Received: from homiemail-a54.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a54.g.dreamhost.com (Postfix) with ESMTP id 41E9E40122425 for ; Mon, 10 Jun 2013 14:03:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=udKlo4UN2rzW6rSvOPnw lk1MjH0=; b=T3ONcMHEsMFyoQ0CzSah8R6JjnzdJ6nRBv+rbn/1484jgPpObvAR DhUtG2GLwepA8gDhDEQUWz5oPgIq8LnOLpgWF0fGqubP6LoOSjGsRzzXZXmLsSHS mK2+MyxLE7cGNOKO+7ArLxMLOwsiZdcylZko30VUa67QLcJ0MsppdUo= Received: from mail-wg0-f53.google.com (mail-wg0-f53.google.com [74.125.82.53]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a54.g.dreamhost.com (Postfix) with ESMTPSA id DE41F40122422 for ; Mon, 10 Jun 2013 14:03:18 -0700 (PDT) Received: by mail-wg0-f53.google.com with SMTP id y10so2871433wgg.20 for ; Mon, 10 Jun 2013 14:03:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=nPxLYGhbSTPvZ9CiJJKEgQJhATpwx6cA1gxusMpOolg=; b=SFMuFAoKx3N5c7g7ONqo2e9O0o3o9w8THuJRObH4UWwf5xXvI3WUz257nXXZD8xXau SXH1zDCwV5rhf37vZ7RcQIwFnuVWRLVY2n+amvg9HqIKKv9Tjpw5DIxQvATRl/dkXW00 MrfVdz8ljoqDh47U5aoF1JuQgG63TMSL91nhCPgogV8/fJrYoFBqbPEvhiKfOVY3aL5R w+bcWEuR37VZPJSlMkjMGbpQExW4Sf3EbPs2ufzKQvOm5EWTtOw2Z+hI3kbCgFPAVdWd hYBkF6dWCvqY4pVm4VZ8Jz0dK58/goq/5GF48YGaB+vdOpaNRzT9YVdmZjdpeoRcl6XB lOaQ== MIME-Version: 1.0 X-Received: by 10.180.90.164 with SMTP id bx4mr5672433wib.13.1370898197317; Mon, 10 Jun 2013 14:03:17 -0700 (PDT) Received: by 10.216.63.136 with HTTP; Mon, 10 Jun 2013 14:03:17 -0700 (PDT) In-Reply-To: <51B63979.40601@drees.name> References: <51B63979.40601@drees.name> Date: Mon, 10 Jun 2013 16:03:17 -0500 Message-ID: From: Nico Williams To: stefan@drees.name Content-Type: text/plain; charset=UTF-8 Cc: "json@ietf.org" , "Matt Miller \(mamille2\)" Subject: Re: [Json] Proposed change to the title of the spec - LAST CHANCE ON PROPOSALS X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 10 Jun 2013 21:03:32 -0000 On Mon, Jun 10, 2013 at 3:39 PM, Stefan Drees wrote: > I thus hereby propose as new title: > > NEW: > """ > > The JSON Text Format > > """ I would object. It is conceivable to have a binary encoding (like the recently proposed CBOR) that could (or a subset of which could) represent the same data as JSON. And it might even be possible to update the UTF detection logic to support the such an encoding. The new thing could be equivalent to JSON and a reasonable transformation of it, but it wouldn't be text. I like Matt's #2 and #3. I have no other proposals to add. I think Matt's #1, #2, and #3 about cover all the choices we should consider, but maybe my imagination fails me. Nico -- From cabo@tzi.org Mon Jun 10 14:15:17 2013 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 37C4C21F96DF for ; Mon, 10 Jun 2013 14:15:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.121 X-Spam-Level: X-Spam-Status: No, score=-106.121 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hdFKsoweE2OG for ; Mon, 10 Jun 2013 14:15:12 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 17C7C21F8FA1 for ; Mon, 10 Jun 2013 14:15:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r5ALF8jA008043 for ; Mon, 10 Jun 2013 23:15:08 +0200 (CEST) Received: from [192.168.217.105] (p54893267.dip0.t-ipconnect.de [84.137.50.103]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 4E2E13FE3; Mon, 10 Jun 2013 23:15:08 +0200 (CEST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Carsten Bormann In-Reply-To: Date: Mon, 10 Jun 2013 23:15:07 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "json@ietf.org" X-Mailer: Apple Mail (2.1508) Subject: Re: [Json] ABNF nits X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 10 Jun 2013 21:15:17 -0000 Joe was kind enough to check in an extracted and completed version of = the ABNF at: > http://svn.tools.ietf.org/svn/wg/json/abnf/json.abnf I just generated 10000 random instances of that grammar using Jutta = Degener's brilliant abnfgen tool and checked them against the Ruby JSON = parser. 10 of the random instances didn't pass because the random generator = managed to generate escapes for unpaired surrogates... (It is unlikely that we want to address any of this at the ABNF level, = so that is not a bug.) So we have passed a first test indicating that the grammar doesn't seem = to generate a superset of the language. If you want to repeat this test against your favorite JSON parser, I can = send you the 10000 random instances or you can run abnfgen yourself = (after changing the %x10FFFF to %x7E, as abnfgen is not Unicode-savvy). Now I would like to run a test whether the things we consider JSON = documents are all parsed by the grammar. If anyone has a corpus of JSON texts, or a way to generate random JSON = texts, I would like to check them against the ABNF. Please contact me = off-list. Gr=FC=DFe, Carsten From tsaloranta@gmail.com Mon Jun 10 14:25:12 2013 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 72FC421F9A3A for ; Mon, 10 Jun 2013 14:25:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.421 X-Spam-Level: X-Spam-Status: No, score=-2.421 tagged_above=-999 required=5 tests=[AWL=0.178, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9uJCHK4siNv2 for ; Mon, 10 Jun 2013 14:25:11 -0700 (PDT) Received: from mail-we0-x22b.google.com (mail-we0-x22b.google.com [IPv6:2a00:1450:400c:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 213CF21F9A38 for ; Mon, 10 Jun 2013 14:25:10 -0700 (PDT) Received: by mail-we0-f171.google.com with SMTP id m46so5359221wev.30 for ; Mon, 10 Jun 2013 14:25:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=fewToqIDzAsvvJu2L5NdhmUAS/k7F30CpF4USQj3wAU=; b=tq2KnJKme0ON52whGlyMeJ0QhcqY3feieeB3ErlwQNumwPbZNq0TJEiqNk+cdRZk5Z G0XYz8+xm/1VboUaIOMWH9LgLLbo7ZXL3Cxl4DKRDg7tzq2hk1GYSQ1xG/OSE3PYnCoH EgY0I03vQpOw+TL6DOpzmxfpRLZPkOKKNVJxbp74PxN7UNwNaxv3gSgKB6spMOf0Ds3w fW6ABoRdImElecX18AIxhT+OuiuuYRhXiHlw8iJD7tM1hUCxq/N7ZPcqvV/azoLXxlpg sojr4ag29fmQ5BepXUvmDQAZHxt+cEQbaPiI9mUHindLGFD/H9wWGuw+lMYyUzf90vrj 5g7w== MIME-Version: 1.0 X-Received: by 10.180.185.44 with SMTP id ez12mr5730926wic.7.1370899509899; Mon, 10 Jun 2013 14:25:09 -0700 (PDT) Received: by 10.227.72.74 with HTTP; Mon, 10 Jun 2013 14:25:09 -0700 (PDT) In-Reply-To: References: <51B63979.40601@drees.name> Date: Mon, 10 Jun 2013 14:25:09 -0700 Message-ID: From: Tatu Saloranta To: Nico Williams Content-Type: multipart/alternative; boundary=001a11c225744f793904ded36ad1 Cc: "Matt Miller \(mamille2\)" , stefan@drees.name, "json@ietf.org" Subject: Re: [Json] Proposed change to the title of the spec - LAST CHANCE ON PROPOSALS X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 10 Jun 2013 21:25:13 -0000 --001a11c225744f793904ded36ad1 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Jun 10, 2013 at 2:03 PM, Nico Williams wrote: > On Mon, Jun 10, 2013 at 3:39 PM, Stefan Drees wrote: > > I thus hereby propose as new title: > > > > NEW: > > """ > > > > The JSON Text Format > > > > """ > > I would object. It is conceivable to have a binary encoding (like the > recently proposed CBOR) that could (or a subset of which could) > represent the same data as JSON. And it might even be possible to > update the UTF detection logic to support the such an encoding. The > new thing could be equivalent to JSON and a reasonable transformation > of it, but it wouldn't be text. Not just could but there already exist multiple, like Smile ( http://wiki.fasterxml.com/SmileFormatSpec) and ubjson (http://ubjson.org/). Smile supports auto-detection just as you suggested, to allow seamless detection. And indeed, the idea of logical JSON model and one or more matching physical serializations is simple, powerful and useful thing (similar to binary infosets for xml). Then again, _this_ specification does define details of textual serialization of logical model, so existence of binary serialization does not in itself invalidate use of "text" in title. -+ Tatu +- --001a11c225744f793904ded36ad1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Mon, Jun 10, 2013 at 2:03 PM, Nico Williams <nic= o@cryptonector.com> wrote:
On Mon, Jun 10, 2013 at 3:39 PM, Stefan = Drees <stefan@drees.name> wr= ote:
> I thus hereby propose as new title:
>
> NEW:
> """
>
> =A0 =A0 =A0 =A0 The JSON Text Format
>
> """

I would object. =A0It is conceivable to have a binary encoding (like = the
recently proposed CBOR) that could (or a subset of which could)
represent the same data as JSON. =A0And it might even be possible to
update the UTF detection logic to support the such an encoding. =A0The
new thing could be equivalent to JSON and a reasonable transformation
of it, but it wouldn't be text.
=A0
No= t just could but there already exist multiple, like Smile (http://wiki.fasterxml.com/SmileFormat= Spec) and ubjson (http://ubjson.org/= ).
Smile supports auto-detection just as you suggested, to allow se= amless detection.
And indeed, the idea of logical JSON mode= l and one or more matching physical serializations is simple, powerful and = useful thing (similar to binary infosets for xml).

Then again, _this_ specification does defin= e details of textual serialization of logical model, so existence of binary= serialization does not in itself invalidate use of "text" in tit= le.

-+ Tatu +-

=
--001a11c225744f793904ded36ad1-- From cromis@gmail.com Mon Jun 10 14:36:50 2013 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 3097321F99B8 for ; Mon, 10 Jun 2013 14:36:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5kzGYG3Wyfwc for ; Mon, 10 Jun 2013 14:36:45 -0700 (PDT) Received: from mail-qe0-f53.google.com (mail-qe0-f53.google.com [209.85.128.53]) by ietfa.amsl.com (Postfix) with ESMTP id 077E521F9A63 for ; Mon, 10 Jun 2013 14:36:44 -0700 (PDT) Received: by mail-qe0-f53.google.com with SMTP id 1so4331770qee.26 for ; Mon, 10 Jun 2013 14:36:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=4bwobnnubrprP5r5v0v/u6Kop12PTS52J/ekBwCyZbk=; b=KAcYWePbXnQbUrlrVBtP/FdXFjpDbwGOskuvr0LzGFkJh9PU2T1afLJlSvPAP68Mlx zgr53XsYT7mh+I9JpNhFlKb9RGL0t4uEnPBXo2kQ0MWsbjNkuju2v7uOM0RAY4gIkc6X EGvGWptlKQ1k8qOdfj0Gy8nXZUHng+MELzu7odrk2fgxw1wH7u6LVE5Vjl+TrWJSphZQ 4GSRWMrKrD1R+F4D3VgLpGiPXtWgTW2qKoBl9phRHi799UETBi/dSXlrG/ldFq67PYhW 83NOl5eKvWv9y/0L7LWPf9LRWdTsCpxacSiIFmlV+LBeuex+QQvcIXUsc7bkSTKCP9mD F8rQ== X-Received: by 10.224.11.199 with SMTP id u7mr15509749qau.76.1370900204465; Mon, 10 Jun 2013 14:36:44 -0700 (PDT) MIME-Version: 1.0 Sender: cromis@gmail.com Received: by 10.49.106.228 with HTTP; Mon, 10 Jun 2013 14:36:24 -0700 (PDT) In-Reply-To: <20130610201746.GC1057@mercury.ccil.org> References: <51b23e6d.6196420a.0b15.4245SMTPIN_ADDED_BROKEN@mx.google.com> <51b4dbbe.64da440a.1fc2.6dd2SMTPIN_ADDED_BROKEN@mx.google.com> <51b4ec44.ea05420a.7c73.ffffa487SMTPIN_ADDED_BROKEN@mx.google.com> <51b507b1.c686e00a.3a7e.ffffa0adSMTPIN_ADDED_BROKEN@mx.google.com> <20130610201746.GC1057@mercury.ccil.org> From: Jacob Davies Date: Mon, 10 Jun 2013 14:36:24 -0700 X-Google-Sender-Auth: orKWWHLCjJCk21HPaH0vfZ_W6Aw Message-ID: To: John Cowan Content-Type: text/plain; charset=ISO-8859-1 Cc: Markus Lanthaler , "json@ietf.org" Subject: Re: [Json] Allow any JSON value at the top level X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 10 Jun 2013 21:36:50 -0000 On Mon, Jun 10, 2013 at 1:17 PM, John Cowan wrote: > Jacob Davies scripsit: >> The original specification has an asymmetry in what values may be sent >> at the top level motivated by an encoding-detection scheme that is now >> obsolete. > > How do we know what the motivation is? I think the self-delimiting nature > is more important. The encoding-detection is the only motivation mentioned in the RFC, and then only implicitly: "Since the first two characters of a JSON text will always be ASCII characters [RFC0020], it is possible to determine whether an octet stream is UTF-8, UTF-16 (BE or LE), or UTF -32 (BE or LE) by looking at the pattern of nulls in the first four octets." Of course there can be other notable benefits or drawbacks regardless of the stated motivation. Self-delimiting is a benefit, it appears. The fact that a sub-part of a valid JSON text is not also a valid JSON text is a drawback in an otherwise symmetric data model. > In any case, even if numbers, strings, booleans, and null were allowed at > the top level, all application/json entity bodies would still begin with > a non-null ASCII character, which is sufficient for encoding detection. Good to know. From ietf@augustcellars.com Mon Jun 10 14:55:20 2013 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 C72D021F9AB9 for ; Mon, 10 Jun 2013 14:55:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lpgBGUWhs-0I for ; Mon, 10 Jun 2013 14:55:15 -0700 (PDT) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by ietfa.amsl.com (Postfix) with ESMTP id 4342E21F9AA3 for ; Mon, 10 Jun 2013 14:55:11 -0700 (PDT) Received: from Philemon (mail.augustcellars.com [50.34.17.238]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp1.pacifier.net (Postfix) with ESMTPSA id D732B2CA1F for ; Mon, 10 Jun 2013 14:55:10 -0700 (PDT) From: "Jim Schaad" To: Date: Mon, 10 Jun 2013 14:54:19 -0700 Message-ID: <06c101ce6625$0f891bf0$2e9b53d0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac5mIupHFvoeUrtwQTulCaqwQck6sA== Content-Language: en-us Subject: [Json] Leading and trailing whitespace X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 10 Jun 2013 21:55:20 -0000 The current specification allows for arbitrary whitespace to occur before and after an array or object. I would like to know if this is what was intended to begin with or not. There are two different things that could be done about this (one of which would potentially be necessary if you allowed all values in a JSON-text. 1. Some of the ABNF could be cleaned up to eliminate situations where you end up with two ws non-terminals in a row. Thus the ABNF could be modified from JSON-text = object / array begin-array = ws %x5B ws ; [ left square bracket begin-object = ws %x7B ws ; { left curly bracket end-array = ws %x5D ws ; ] right square bracket end-object = ws %x7D ws ; } right curly bracket name-separator = ws %x3A ws ; : colon value-separator = ws %x2C ws ; , comma object = begin-object [ member *( value-separator member ) ] end-object member = string name-separator value array = begin-array [ value *( value-separator value ) ] end-array to JSON-text = object / array begin-array = %x5B ws ; [ left square bracket begin-object = %x7B ws ; { left curly brace end-array = ws %5D ; ] right square bracket end-object = ws %7D ; } right curly brace name-separator = ws %x3A ws ; : colon value-separator = ws %x2C ws ; , comma If needed then JSON-text would become either JSON-text = ws value ws Or JSON-text = ws object ws / ws array ws 2. There is nothing in the current parser or generator text which says what to do if you come across a string which either has leading/trailing white space or a string which has a complete JSON-text string followed by non-white space characters. I would hope that the second case should cause either an error or some other indicator that the entire string was not consumed. I am slightly agnostic about the first case but would kind of like to eliminate leading and trailing whitespace. Jim From paul.hoffman@vpnc.org Mon Jun 10 15:04:41 2013 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 C2DE821F9994 for ; Mon, 10 Jun 2013 15:04:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.423 X-Spam-Level: X-Spam-Status: No, score=-102.423 tagged_above=-999 required=5 tests=[AWL=0.176, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hBeHQIonIY0a for ; Mon, 10 Jun 2013 15:04:39 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id CC86021F962B for ; Mon, 10 Jun 2013 15:04:39 -0700 (PDT) Received: from [10.20.30.90] (50-0-66-165.dsl.dynamic.sonic.net [50.0.66.165]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r5AM4FHd054731 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 10 Jun 2013 15:04:16 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Paul Hoffman In-Reply-To: <06c101ce6625$0f891bf0$2e9b53d0$@augustcellars.com> Date: Mon, 10 Jun 2013 15:04:15 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <379266A1-82C1-4FF5-BD7C-EE657F1FD41F@vpnc.org> References: <06c101ce6625$0f891bf0$2e9b53d0$@augustcellars.com> To: "Jim Schaad" X-Mailer: Apple Mail (2.1508) Cc: json@ietf.org Subject: Re: [Json] Leading and trailing whitespace X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 10 Jun 2013 22:04:41 -0000 On Jun 10, 2013, at 2:54 PM, "Jim Schaad" = wrote: > The current specification allows for arbitrary whitespace to occur = before > and after an array or object. I would like to know if this is what = was > intended to begin with or not. Why is the "intention" important? > There are two different things that could be done about this (one of = which > would potentially be necessary if you allowed all values in a = JSON-text. Why should something "be done about this"? I think you are leading into = canonicalization, but that's not part of RFC 4627, so introducing it = seems like a pretty massive change. Having said that, knowing your intention would be useful here. --Paul Hoffman= From nico@cryptonector.com Mon Jun 10 15:18:25 2013 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 C8E1321F9A13 for ; Mon, 10 Jun 2013 15:18:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.96 X-Spam-Level: X-Spam-Status: No, score=-1.96 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aBn8lDfCtARy for ; Mon, 10 Jun 2013 15:18:20 -0700 (PDT) Received: from homiemail-a89.g.dreamhost.com (caiajhbdcbbj.dreamhost.com [208.97.132.119]) by ietfa.amsl.com (Postfix) with ESMTP id B995321F99F4 for ; Mon, 10 Jun 2013 15:18:20 -0700 (PDT) Received: from homiemail-a89.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a89.g.dreamhost.com (Postfix) with ESMTP id BDF3D318074 for ; Mon, 10 Jun 2013 15:18:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=CpUjPq+nwW6kMmxXhPig TmOEdWs=; b=aqlvjsnDAOwILvR+HY5OHZqcsUJ4/sVfKohwIm5gnK0+iEWfrAFM 1O2eY5beYi6kQMXZ1BZSOiSblwOBXAbuuYFIu9UVn2CAlEH2DlDhFH7x7exXm1hh UVkKJQa+JUr5GxfRuhJ69ryb7Gklg+2VUppRP4H7orce7SBiY0Eif7c= Received: from mail-we0-f176.google.com (mail-we0-f176.google.com [74.125.82.176]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a89.g.dreamhost.com (Postfix) with ESMTPSA id 654BA318072 for ; Mon, 10 Jun 2013 15:18:19 -0700 (PDT) Received: by mail-we0-f176.google.com with SMTP id t56so5194394wes.7 for ; Mon, 10 Jun 2013 15:18:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=t6MHj+HG4mx4QOqYcAOd7yEPst5Tz7ahmR3gKYHkTaM=; b=GKgwFUeCuB8S4NIxb7AdGLmmKi9C6UhYuDzbhmo+5M9ZuDwlRdnjZQScplaAUqyuQd 9o7gt5bRvmCAmd8wyKWGWT6RWDoghnc7ttc5jF+GyjWnV4utmrV2L3S7K37uhRg48PeM 8JAKeW57LXlUXphXdxP/t0PUPoYarq8d832g2A6dzgstAGfaUZnSdWkiMIxQGUXz2sTb 0fM7xosIoz0br556XOmwvzfakh9MLYTuFEh7/ToDv0dsVUiOof3IgCx/SCO+5hV1BWTT BUSNjJCt1kK33EFD4pTEEXOHLnVlfEjpfSIUlk1+wAbYcuebKo7Mqerzsazs/ku/GWkq v6nA== MIME-Version: 1.0 X-Received: by 10.180.198.194 with SMTP id je2mr4282244wic.36.1370902698009; Mon, 10 Jun 2013 15:18:18 -0700 (PDT) Received: by 10.216.63.136 with HTTP; Mon, 10 Jun 2013 15:18:17 -0700 (PDT) In-Reply-To: References: <51b23e6d.6196420a.0b15.4245SMTPIN_ADDED_BROKEN@mx.google.com> <51b4dbbe.64da440a.1fc2.6dd2SMTPIN_ADDED_BROKEN@mx.google.com> <51b4ec44.ea05420a.7c73.ffffa487SMTPIN_ADDED_BROKEN@mx.google.com> <51b507b1.c686e00a.3a7e.ffffa0adSMTPIN_ADDED_BROKEN@mx.google.com> <20130610201746.GC1057@mercury.ccil.org> Date: Mon, 10 Jun 2013 17:18:17 -0500 Message-ID: From: Nico Williams To: Jacob Davies Content-Type: text/plain; charset=UTF-8 Cc: John Cowan , Markus Lanthaler , "json@ietf.org" Subject: Re: [Json] Allow any JSON value at the top level X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 10 Jun 2013 22:18:25 -0000 On Mon, Jun 10, 2013 at 4:36 PM, Jacob Davies wrote: > On Mon, Jun 10, 2013 at 1:17 PM, John Cowan wrote: > Of course there can be other notable benefits or drawbacks regardless > of the stated motivation. Self-delimiting is a benefit, it appears. > The fact that a sub-part of a valid JSON text is not also a valid JSON > text is a drawback in an otherwise symmetric data model. All JSON values are self-delimited regardless of whether at the top-level or not. That is, we always know how to find the end of the value (if it is in the message). Lengths of values are always indefinite (i.e., the parser has to scan forward to find the end of the value). >> In any case, even if numbers, strings, booleans, and null were allowed at >> the top level, all application/json entity bodies would still begin with >> a non-null ASCII character, which is sufficient for encoding detection. > > Good to know. Right. We can have one-character values (must be numeric) or two-or-more-character values (strings, boolean, null). The second character in the string case might not be ASCII though, but it still works out as long as \u0000 is always escaped, and this is what we end up with Two or more characters: 00 00 00 xx UTF-32BE 00 xx xx xx UTF-16BE xx 00 00 00 UTF-32LE xx 00 xx xx UTF-16LE xx xx xx xx UTF-8 One-character numeric top-level values: 00 00 00 xx UTF-32BE 00 xx UTF-16BE xx 00 00 00 UTF-32LE xx 00 UTF-16LE xx UTF-8 So the section 3 text would have to be updated to include the above patterns, which can be further compacted to: 00 00 00 xx UTF-32BE xx 00 00 00 UTF-32LE 00 xx .. .. UTF-16BE xx 00 .. .. UTF-16LE xx .. .. .. UTF-8 If the parser checks for these patterns in order (other orders are also possible). Here '..' means "any or no byte values". Nico -- From cowan@ccil.org Mon Jun 10 15:29:22 2013 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 D567921F99E2 for ; Mon, 10 Jun 2013 15:29:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.409 X-Spam-Level: X-Spam-Status: No, score=-3.409 tagged_above=-999 required=5 tests=[AWL=0.190, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dm2uBMKDyFe7 for ; Mon, 10 Jun 2013 15:29:18 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id 851F921F99E1 for ; Mon, 10 Jun 2013 15:29:18 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1UmAaP-0004Rj-GP; Mon, 10 Jun 2013 18:29:13 -0400 Date: Mon, 10 Jun 2013 18:29:13 -0400 From: John Cowan To: Nico Williams Message-ID: <20130610222913.GD1057@mercury.ccil.org> References: <51b4dbbe.64da440a.1fc2.6dd2SMTPIN_ADDED_BROKEN@mx.google.com> <51b4ec44.ea05420a.7c73.ffffa487SMTPIN_ADDED_BROKEN@mx.google.com> <51b507b1.c686e00a.3a7e.ffffa0adSMTPIN_ADDED_BROKEN@mx.google.com> <20130610201746.GC1057@mercury.ccil.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Cc: Jacob Davies , Markus Lanthaler , "json@ietf.org" Subject: Re: [Json] Allow any JSON value at the top level X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 10 Jun 2013 22:29:23 -0000 Nico Williams scripsit: > All JSON values are self-delimited regardless of whether at the > top-level or not. That is, we always know how to find the end of the > value (if it is in the message). Lengths of values are always > indefinite (i.e., the parser has to scan forward to find the end of > the value). What I meant was that if the message is truncated within an object, array, boolean, or null, it is detectable: not so if it is truncated within a top-level number. -- John Cowan cowan@ccil.org http://ccil.org/~cowan Nobody expects the RESTifarian Inquisition! Our chief weapon is surprise ... surprise and tedium ... tedium and surprise .... Our two weapons are tedium and surprise ... and ruthless disregard for unpleasant facts.... Our three weapons are tedium, surprise, and ruthless disregard ... and an almost fanatical devotion to Roy Fielding.... From jorge@jorgechamorro.com Mon Jun 10 15:53:17 2013 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 D7CC021F960D for ; Mon, 10 Jun 2013 15:53:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.032 X-Spam-Level: X-Spam-Status: No, score=-3.032 tagged_above=-999 required=5 tests=[AWL=-0.432, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vkQgI26DW5ac for ; Mon, 10 Jun 2013 15:53:17 -0700 (PDT) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) by ietfa.amsl.com (Postfix) with ESMTP id A36F521F9928 for ; Mon, 10 Jun 2013 15:53:14 -0700 (PDT) Received: by mail-wi0-f181.google.com with SMTP id hq4so1367262wib.8 for ; Mon, 10 Jun 2013 15:53:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=rfKqVHaCPrLAFu9smorrM90l7SQM7K39ZVXGYhIOYeA=; b=Sy9i5u85G1dDOdkJNznp9IF5tooD3WUm16HBVI0L5Y1Gd0TWy2vm+m+hYp/Gu0Ep6Q JmqdEqy5xYqi1xTdT2/slQ2ollYHw5v9AJB4eOtbMTwGh6S+Mu3n8QX+rMRo8wcWLY5U wKPYUGMn4WlPJiTJrPPHarKpyUsIDyl65N0A4eGXZV9Rltt7WzG7+nhyTw8JY0Kcq0Pz iafddauFn9j5fyuFtKpR83zvVaDbaPVPLhx3dWYT7yJxPNwLOK2sVIWPD7pMzDyiOqdg O3Q9L2LapLD5S9BYGrV8jNrxEXgJvlJRIl03k9t8xHJSJ18ah0PTfl2peKGvHNneZVJl FeVA== X-Received: by 10.180.187.17 with SMTP id fo17mr5842424wic.60.1370904793671; Mon, 10 Jun 2013 15:53:13 -0700 (PDT) Received: from [192.168.10.50] (2.Red-88-0-218.dynamicIP.rima-tde.net. [88.0.218.2]) by mx.google.com with ESMTPSA id eq15sm66269wic.4.2013.06.10.15.53.12 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 10 Jun 2013 15:53:13 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Jorge In-Reply-To: Date: Tue, 11 Jun 2013 00:53:10 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <3CE20E15-8F9E-4727-BBE7-FBB06F7CAC24@jorgechamorro.com> References: <51b23e6d.6196420a.0b15.4245SMTPIN_ADDED_BROKEN@mx.google.com> <51b4dbbe.64da440a.1fc2.6dd2SMTPIN_ADDED_BROKEN@mx.google.com> <51b4ec44.ea05420a.7c73.ffffa487SMTPIN_ADDED_BROKEN@mx.google.com> <51b507b1.c686e00a.3a7e.ffffa0adSMTPIN_ADDED_BROKEN@mx.google.com> <20130610201746.GC1057@mercury.ccil.org> To: Jacob Davies X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQmxOT829pDb5ih16/mrwEdk/OQrJX8b73kO61RpKVZcXj9BgCv+S7l0W3k5VCh5Y0chbOKn Cc: John Cowan , Markus Lanthaler , "json@ietf.org" Subject: Re: [Json] Allow any JSON value at the top level X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 10 Jun 2013 22:53:18 -0000 It seems to me that top-level JSON values are a problem *only* for = *streaming* parsers. A streaming parser can't tell whether the stream 333 was 3 separate = threes or three-hundred-thirty-three, or even part of an incomplete = 333445, or (chop it as you like). Parsing a stream with the other data types (strings, null, booleans): = e.g. say, this stream: = "string"truenullfalse"anotherstring"null"string"true"etc. etc." doesn't = seem to be so much a problem (unless it gets out of sync!). But non-streaming parsers (such as the ones in EcmaScript 5) haven't any = of these problems because they expect to receive a complete JSON payload = containing a single JSON value (structured or not) and that's easy to = parse unambiguously. --=20 ( Jorge )();= From cromis@gmail.com Mon Jun 10 15:55:03 2013 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 2C4BF21F96D9 for ; Mon, 10 Jun 2013 15:55:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w3qyQ02tXcGf for ; Mon, 10 Jun 2013 15:55:02 -0700 (PDT) Received: from mail-qc0-x233.google.com (mail-qc0-x233.google.com [IPv6:2607:f8b0:400d:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id 1FD6621F96C2 for ; Mon, 10 Jun 2013 15:55:02 -0700 (PDT) Received: by mail-qc0-f179.google.com with SMTP id e1so4038029qcx.10 for ; Mon, 10 Jun 2013 15:55:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:from:date:x-google-sender-auth:message-id :subject:to:content-type:content-transfer-encoding; bh=s9VKfSgsi3UbzbAsh79IFiPaPc1/GWzp5S1ZYAVpjbI=; b=iawuVPeCP0arc+W2aZQHtaf8JjtSQLBzd1V0fSzHRNjO0+iD9LiSHzOkaFMCjchrQM iFGgYU51QiN+t3XR5qrNVWIUK1yftmOhqB+pCBMiXpjCt/Ok2+0Z1dzhrPpTqTobAyok lNxykQ3Is6wNJYXd2m+q6l/aRwy89x1vFBI9yXaxmN1zjd3Xva3+PVz2gpAImIMVqXBg i67KPlkdiEP3CIIP4QTQLdSNYui2OC4uc0O5lRDuXOEXM9C72F/EPpRj5cx8554CZqPn NigFsT7AUtqzfQ2JG2ABIocVwWGqnDEYv3mzkRUcLLRO0mZu0ssy8OedhnbA9L7li++b b+Iw== X-Received: by 10.229.124.80 with SMTP id t16mr4525581qcr.93.1370904901543; Mon, 10 Jun 2013 15:55:01 -0700 (PDT) MIME-Version: 1.0 Sender: cromis@gmail.com Received: by 10.49.106.228 with HTTP; Mon, 10 Jun 2013 15:54:41 -0700 (PDT) From: Jacob Davies Date: Mon, 10 Jun 2013 15:54:41 -0700 X-Google-Sender-Auth: upThZMcNOiaSTd42xn_3yy-mBDY Message-ID: To: "json@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [Json] "Generators SHOULD escape all Unicode whitespace characters"? X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 10 Jun 2013 22:55:03 -0000 I'm curious if anyone else thinks this is worth suggesting to implementors. There are a number of non-ASCII Unicode whitespace and control characters that are not required to be escaped right now. I think generators SHOULD escape them. Obviously parsers must continue to accept them unescaped regardless. The set is fairly small and could be enumerated in the document (it might expand in future, but this would be a good start): http://en.wikipedia.org/wiki/Space_(punctuation)#Spaces_in_Unicode "Whitespace smuggling" is a mild security concern and, from experience, can be quite hard to debug if non-0x20 spaces are not escaped. There is a small overhead of a couple of characters in doing so. Everything else in JSON's text serialization uses either printing characters, insignificant ASCII whitespace between values, or plain spaces in strings. Of course some printing Unicode characters are doppelg=E4ngers so perhaps people feel it is not worth worrying about whitespace either. From nico@cryptonector.com Mon Jun 10 16:26:14 2013 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 22AE121F9A79 for ; Mon, 10 Jun 2013 16:26:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.961 X-Spam-Level: X-Spam-Status: No, score=-1.961 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2y6itQA7UX8d for ; Mon, 10 Jun 2013 16:26:09 -0700 (PDT) Received: from homiemail-a65.g.dreamhost.com (caiajhbdccac.dreamhost.com [208.97.132.202]) by ietfa.amsl.com (Postfix) with ESMTP id 368EE21F9A76 for ; Mon, 10 Jun 2013 16:26:09 -0700 (PDT) Received: from homiemail-a65.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a65.g.dreamhost.com (Postfix) with ESMTP id C8A7C7E4065 for ; Mon, 10 Jun 2013 16:26:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=nnNCrU6cim3+7lJUTNJy i8yejhw=; b=GnwAu01aGao2dYgrfi5AePyIrRIpi6DR8HgqhcROY/Y+KWE6kD9c /GM5y/ANmadx8fsKcKZaR537oSyFwNUIWtuWaW/Syv/zHp76FEFpmValMhbMAoXO jNVuBMrgDfDm0THfbvdG+612Lwy4oQ1boGIA7TxGXW19BMr1iGUjKMM= Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a65.g.dreamhost.com (Postfix) with ESMTPSA id 7AB9E7E4062 for ; Mon, 10 Jun 2013 16:26:08 -0700 (PDT) Received: by mail-wg0-f50.google.com with SMTP id k13so5329171wgh.17 for ; Mon, 10 Jun 2013 16:26:06 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=P3PEFiO6ShNOCenwto1tp/r07237+2usJJPX+OkYADs=; b=d0XXNHmnVfTNvI/1MxegMFDJiOooxwfRW+Q+OPBe3Ks62i3GaKHIbcWIOtlseKubMK wNsA4DWTzIVxywxbKRO+s9Bgeyb6MO2OVivrLVaEx/chKvCUFEfEfOnMw64i0tOCXbhR HEIdj4p/Sg6vjytEwdee1MNnx00MFiecfUdBN7jlDwdsk8hxg69ilUZleEM1m/xLHUjf lczwgAK/i/yF0GZ2odqEflJ7jsB4lAhw5SsQC8jlZWvlg3QbjeG4l3IzK87z7p+ycisk ztDAulsKXG8EEHeBQsRJtjePKt8TJ7Zhy/4Te6ZOptWW7jJjDw2wkeQQBH8AZUlr2/bj fSSQ== MIME-Version: 1.0 X-Received: by 10.194.63.46 with SMTP id d14mr4242674wjs.81.1370906766910; Mon, 10 Jun 2013 16:26:06 -0700 (PDT) Received: by 10.216.63.136 with HTTP; Mon, 10 Jun 2013 16:26:06 -0700 (PDT) In-Reply-To: <3CE20E15-8F9E-4727-BBE7-FBB06F7CAC24@jorgechamorro.com> References: <51b23e6d.6196420a.0b15.4245SMTPIN_ADDED_BROKEN@mx.google.com> <51b4dbbe.64da440a.1fc2.6dd2SMTPIN_ADDED_BROKEN@mx.google.com> <51b4ec44.ea05420a.7c73.ffffa487SMTPIN_ADDED_BROKEN@mx.google.com> <51b507b1.c686e00a.3a7e.ffffa0adSMTPIN_ADDED_BROKEN@mx.google.com> <20130610201746.GC1057@mercury.ccil.org> <3CE20E15-8F9E-4727-BBE7-FBB06F7CAC24@jorgechamorro.com> Date: Mon, 10 Jun 2013 18:26:06 -0500 Message-ID: From: Nico Williams To: Jorge Content-Type: text/plain; charset=UTF-8 Cc: John Cowan , Jacob Davies , Markus Lanthaler , "json@ietf.org" Subject: Re: [Json] Allow any JSON value at the top level X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 10 Jun 2013 23:26:14 -0000 On Mon, Jun 10, 2013 at 5:53 PM, Jorge wrote: > It seems to me that top-level JSON values are a problem *only* for *streaming* parsers. > > A streaming parser can't tell whether the stream 333 was 3 separate threes or three-hundred-thirty-three, or even part of an incomplete 333445, or (chop it as you like). Ahhh. > Parsing a stream with the other data types (strings, null, booleans): e.g. say, this stream: "string"truenullfalse"anotherstring"null"string"true"etc. etc." doesn't seem to be so much a problem (unless it gets out of sync!). > > But non-streaming parsers (such as the ones in EcmaScript 5) haven't any of these problems because they expect to receive a complete JSON payload containing a single JSON value (structured or not) and that's easy to parse unambiguously. We could require that numeric top-level values be followed by one or more space characters. From johnl@iecc.com Mon Jun 10 16:41:30 2013 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 2F0FB21E8091 for ; Mon, 10 Jun 2013 16:41:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.199 X-Spam-Level: X-Spam-Status: No, score=-111.199 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u-NzFUQKlddE for ; Mon, 10 Jun 2013 16:41:26 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id B92C621F9619 for ; Mon, 10 Jun 2013 16:41:25 -0700 (PDT) Received: (qmail 10650 invoked from network); 10 Jun 2013 23:41:24 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 10 Jun 2013 23:41:24 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=51b66424.xn--btvx9d.k1306; i=johnl@user.iecc.com; bh=lL3cjvg0HgeKaRgibIhbzlC/UX4V91jKneYanZCzAfo=; b=vcL2l2suBy9MyU/2/zHhmdERqi5HoAYaMFZOQliboxM/USvMhaJP1n7F1WOr4j6NDjhkxIWs8ODnkO9NDRnBwr9GKcnZLwf9+wKylDHg9hKjPwWuFBPyQy9LjytSm90gQemTgzzZN0Y1GBkgFAdLhGMK3Ei0THGhkL4tLP8ispCSlmw6YyMiBfmojcit0MdUIxH4H+w2pTN+caWSwBaRIKuUdT3qiBoUja4mJH6NvZGSE0KeiQ8T4uUJOXD23XjD DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=51b66424.xn--btvx9d.k1306; olt=johnl@user.iecc.com; bh=lL3cjvg0HgeKaRgibIhbzlC/UX4V91jKneYanZCzAfo=; b=vjvYvt2jnWxbhRo2hpJms15Yy8+kCkZne109lR1yZ/aRELmX0UFj36BgW9SHiJU9GfZNZWtVlDj7eg8hE7Gg30brZZ4s2Uu9hI6NmnQNO/4k2LuDMQm9/PliePnOfDJXMSMJIQXcGWG3znH0CxNZfLmIUciY7YdjtT14wa4wH43IFsH5LsgHLuwth7cmDZMja9WFlKHTd0P3OTrF9ET3c5Am/Z4ifoIttPIkQr0KF+4Kxiq00NxiHgD4ilPTi4tE Date: 10 Jun 2013 23:41:01 -0000 Message-ID: <20130610234101.73051.qmail@joyce.lan> From: "John Levine" To: json@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Cc: stephen.dolan@cl.cam.ac.uk Subject: Re: [Json] The names within an object SHOULD be unique. X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 10 Jun 2013 23:41:30 -0000 >I propose that it be invalid to consider that document >indistinguishable from {a: true}. Parsers are free to accept or reject >it, and if they accept it they are free to return either one or two >"a" entries, but if they only return one it must be {a: false}. That would rule out streaming parsers, or at least require that a parser have access to arbitrarily large storage to buffer up large JSON objects, or store all of the names or hash them or otherwise add signficant processing that existing streaming parsers don't do. Given that their current behavior is presumably adequate for their current applications, it seems unlikely that the programmers will add all that extra code just because we say to. This strikes me as an issue that we need to document, not one that we can legislate away, e.g. "Parsers that do not create a single in-memory structure for a parsed object probably will not detect duplicate names." From tsaloranta@gmail.com Mon Jun 10 16:49:07 2013 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 6AD3821F99DB for ; Mon, 10 Jun 2013 16:49:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[AWL=0.164, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rv5RMtMJVqnO for ; Mon, 10 Jun 2013 16:49:06 -0700 (PDT) Received: from mail-we0-x22c.google.com (mail-we0-x22c.google.com [IPv6:2a00:1450:400c:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 6326421F99D6 for ; Mon, 10 Jun 2013 16:49:06 -0700 (PDT) Received: by mail-we0-f172.google.com with SMTP id q56so5334256wes.17 for ; Mon, 10 Jun 2013 16:49:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=8RPXJP4VhsU3qp7OYmpktBkunJ/cBpKl3Iefy6x6jUs=; b=0nX+4pCh6iuTxlyoD9l8B/0UQacLEJ6HqvdP8r51jX/PKcHWD45KMYWNYOKXMKPR51 6EAlyJcWdZx6pIqzAItqSnmyrlN4iSFo/uTFXXWBK8+xlzGn6UmscuToOMc38TlCjW6f nwKUhg0RiXpb4Pvkt+54MEiMgDf2hGOpaABGfb+kEPvTotvqDcXDMS83wEyhpaH3FYQo BBGx57fUD9XsqY1GacT8PJAM9xQeBdV6vYb7Obs4SfR4QCJ29b9e28BNGk466pnTWcEx GlTHe6wbbmfmSpYVZXP/skm7bp9fLuiqDXP1P7LAmaZHFODJhVXp8VPsGvMycsAIcMOC VZBw== MIME-Version: 1.0 X-Received: by 10.194.179.129 with SMTP id dg1mr2674681wjc.38.1370908145333; Mon, 10 Jun 2013 16:49:05 -0700 (PDT) Received: by 10.227.72.74 with HTTP; Mon, 10 Jun 2013 16:49:05 -0700 (PDT) In-Reply-To: <3CE20E15-8F9E-4727-BBE7-FBB06F7CAC24@jorgechamorro.com> References: <51b23e6d.6196420a.0b15.4245SMTPIN_ADDED_BROKEN@mx.google.com> <51b4dbbe.64da440a.1fc2.6dd2SMTPIN_ADDED_BROKEN@mx.google.com> <51b4ec44.ea05420a.7c73.ffffa487SMTPIN_ADDED_BROKEN@mx.google.com> <51b507b1.c686e00a.3a7e.ffffa0adSMTPIN_ADDED_BROKEN@mx.google.com> <20130610201746.GC1057@mercury.ccil.org> <3CE20E15-8F9E-4727-BBE7-FBB06F7CAC24@jorgechamorro.com> Date: Mon, 10 Jun 2013 16:49:05 -0700 Message-ID: From: Tatu Saloranta To: Jorge Content-Type: multipart/alternative; boundary=089e013d194e05bce504ded56d2f Cc: John Cowan , Jacob Davies , Markus Lanthaler , "json@ietf.org" Subject: Re: [Json] Allow any JSON value at the top level X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 10 Jun 2013 23:49:07 -0000 --089e013d194e05bce504ded56d2f Content-Type: text/plain; charset=ISO-8859-1 On Mon, Jun 10, 2013 at 3:53 PM, Jorge wrote: > It seems to me that top-level JSON values are a problem *only* for > *streaming* parsers. > > A streaming parser can't tell whether the stream 333 was 3 separate threes > or three-hundred-thirty-three, or even part of an incomplete 333445, or > (chop it as you like). > > Parsing a stream with the other data types (strings, null, booleans): e.g. > say, this stream: "string"truenullfalse"anotherstring"null"string"true"etc. > etc." doesn't seem to be so much a problem (unless it gets out of sync!). > > But non-streaming parsers (such as the ones in EcmaScript 5) haven't any > of these problems because they expect to receive a complete JSON payload > containing a single JSON value (structured or not) and that's easy to parse > unambiguously. > FWIW, streaming parsers I have been involved with expect separating white-space and have no problem telling these cases apart; although it does require a lookup to detect a white-space or end-of-stream. Although there is no support from specification (since non-structured root values are not specified as acceptable), this seems intuitive from user perspective based on feedback I have gotten on this. This despite there being theoretical problems (like: should commas be allowed or required, for "implicit array" approach). But what John C pointed out -- truncation of '333' from full '333445' -- is actually an interesting and valid potential issue. -+ Tatu +- --089e013d194e05bce504ded56d2f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Mon, Jun 10, 2013 at 3:53 PM, Jorge &= lt;jorge@jorge= chamorro.com> wrote:
It seems to me that top-level JSON values ar= e a problem *only* for *streaming* parsers.

A streaming parser can't tell whether the stream 333 was 3 separate thr= ees or three-hundred-thirty-three, or even part of an incomplete 333445, or= (chop it as you like).

Parsing a stream with the other data types (strings, null, booleans): e.g. = say, this stream: "string"truenullfalse"anotherstring"n= ull"string"true"etc. etc." doesn't seem to be so mu= ch a problem (unless it gets out of sync!).

But non-streaming parsers (such as the ones in EcmaScript 5) haven't an= y of these problems because they expect to receive a complete JSON payload = containing a single JSON value (structured or not) and that's easy to p= arse unambiguously.

FWIW, streaming parsers I have been = involved with expect separating white-space and have no problem telling the= se cases apart; although it does require a lookup to detect a white-space o= r end-of-stream.
Although there is no support from specification (since non-struc= tured root values are not specified as acceptable), this seems intuitive fr= om user perspective based on feedback I have gotten on this. This despite t= here being theoretical problems (like: should commas be allowed or required= , for "implicit array" approach).

But what John C pointed out -- trunca= tion of '333' from full '333445' -- is actually an interest= ing and valid potential issue.

-+ Tatu= +-

=A0
--089e013d194e05bce504ded56d2f-- From paul.hoffman@vpnc.org Mon Jun 10 16:56:37 2013 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 8CC3821F99DB for ; Mon, 10 Jun 2013 16:56:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.427 X-Spam-Level: X-Spam-Status: No, score=-102.427 tagged_above=-999 required=5 tests=[AWL=0.172, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fXWVUrCwX+BK for ; Mon, 10 Jun 2013 16:56:37 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 29CF721F99CF for ; Mon, 10 Jun 2013 16:56:37 -0700 (PDT) Received: from [10.20.30.90] (50-0-66-165.dsl.dynamic.sonic.net [50.0.66.165]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r5ANuZDV057632 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 10 Jun 2013 16:56:36 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Paul Hoffman In-Reply-To: Date: Mon, 10 Jun 2013 16:56:35 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <51b23e6d.6196420a.0b15.4245SMTPIN_ADDED_BROKEN@mx.google.com> <51b4dbbe.64da440a.1fc2.6dd2SMTPIN_ADDED_BROKEN@mx.google.com> <51b4ec44.ea05420a.7c73.ffffa487SMTPIN_ADDED_BROKEN@mx.google.com> <51b507b1.c686e00a.3a7e.ffffa0adSMTPIN_ADDED_BROKEN@mx.google.com> <20130610201746.GC1057@mercury.ccil.org> <3CE20E15-8F9E-4727-BBE7-FBB06F7CAC24@jorgechamorro.com> To: json@ietf.org X-Mailer: Apple Mail (2.1508) Subject: Re: [Json] Allow any JSON value at the top level X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 10 Jun 2013 23:56:37 -0000 Although I earlier supported the idea of any JSON value at the top = level, a bunch of recent posts show that this is probably a significant = revision to the RFC because it would take a lot of extra requirements as = well. I now support leaving the requirement in the -bis document as it = is now. If we want to add a new MIME type for "any JSON item", that is clearly a = significant addition to the RFC. It can wait until the WG recharters. --Paul Hoffman= From ietf@augustcellars.com Mon Jun 10 17:17:32 2013 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 51C5521F934B for ; Mon, 10 Jun 2013 17:17:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vmLdKAcQ8E2A for ; Mon, 10 Jun 2013 17:17:26 -0700 (PDT) Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) by ietfa.amsl.com (Postfix) with ESMTP id 74AEF21F9412 for ; Mon, 10 Jun 2013 17:17:26 -0700 (PDT) Received: from Philemon (mail.augustcellars.com [50.34.17.238]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp3.pacifier.net (Postfix) with ESMTPSA id 342D238EF2; Mon, 10 Jun 2013 17:17:16 -0700 (PDT) From: "Jim Schaad" To: "'Paul Hoffman'" References: <06c101ce6625$0f891bf0$2e9b53d0$@augustcellars.com> <379266A1-82C1-4FF5-BD7C-EE657F1FD41F@vpnc.org> In-Reply-To: <379266A1-82C1-4FF5-BD7C-EE657F1FD41F@vpnc.org> Date: Mon, 10 Jun 2013 17:16:24 -0700 Message-ID: <06e901ce6638$e8f27a90$bad76fb0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIjA7ejHysocqIyb9p/XvW1gI4I3gIdfG2fmHV8G1A= Content-Language: en-us Cc: json@ietf.org Subject: Re: [Json] Leading and trailing whitespace X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 11 Jun 2013 00:17:32 -0000 My intention here has nothing to do with canonicalization and everything to do with what constitutes a valid string from a parsing perspective. Consider for example the case of a text file which consists of a JSON text string with a trailing CRLF in the file. If trailing whitespace is allowed then the entire text file is a legal JSON text string. If the trailing whitespace is not allowed then it is not a legal JSON text string. I am just trying to clarify which is true. This makes a difference with the argument about moving all of the values to the top level since then the string (ignore the quotes) " true \r\n" cannot be matched if you just want to say it is a Boolean literal (i.e. the non-terminator true). Instead you need to say that it can have whitespace on either side of it. I will agree that the original intention probably is just a question of academic interest. The real question I should have asked would be are people taking advantage of the fact. That is the question of what about normal whitespace. I think there is a question about parsers that would accept the string {"a":"b"}A As I believe there are some that will (stop when you get to the end of the object) and some that will not. Jim > -----Original Message----- > From: Paul Hoffman [mailto:paul.hoffman@vpnc.org] > Sent: Monday, June 10, 2013 3:04 PM > To: Jim Schaad > Cc: json@ietf.org > Subject: Re: [Json] Leading and trailing whitespace > > > > On Jun 10, 2013, at 2:54 PM, "Jim Schaad" wrote: > > > The current specification allows for arbitrary whitespace to occur > > before and after an array or object. I would like to know if this is > > what was intended to begin with or not. > > Why is the "intention" important? > > > There are two different things that could be done about this (one of > > which would potentially be necessary if you allowed all values in a JSON- > text. > > Why should something "be done about this"? I think you are leading into > canonicalization, but that's not part of RFC 4627, so introducing it seems like a > pretty massive change. > > Having said that, knowing your intention would be useful here. > > --Paul Hoffman= From sayrer@gmail.com Mon Jun 10 17:18:06 2013 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 3C03621F9928 for ; Mon, 10 Jun 2013 17:18:06 -0700 (PDT) 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=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ACpw9-p1mToK for ; Mon, 10 Jun 2013 17:18:05 -0700 (PDT) Received: from mail-wg0-x22d.google.com (mail-wg0-x22d.google.com [IPv6:2a00:1450:400c:c00::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 20D2521F9926 for ; Mon, 10 Jun 2013 17:18:04 -0700 (PDT) Received: by mail-wg0-f45.google.com with SMTP id j13so56328wgh.0 for ; Mon, 10 Jun 2013 17:18:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=QEvKJMFX2/Of+OnDHj5PtDOUk0AQ2128KVr8PC8/Ngs=; b=R43Q33l27eH4cihNknqE4VQmv8G36faFXz8UToHlft5+DUebebMv8FGOXOd4icXpbF kFYPkbifN/wkX+XSHYoHpacX8DYrOfaT2Worrogv1mxBygVlqWBMmXAbVxbQDE5qS/nr QQIztZp0L7ifQcySqEqZa/VTSM+O/6uHmHHUjsPFlob4mqHZF8F7ytSksDKl8fyBrO9r LlY8PgSRDgZ0ocDBYZQNXrQ75TJMAQ4RYqLVIDn4cZdq49m3foJjfNFqHF3Z8XDaa6bR oD5ws3HSzMaK1/G5EI3AM7BO53AaEVM0hNODlkLEwAQvfDgYRWX1puwZW+SK0gtboAWW KxcQ== MIME-Version: 1.0 X-Received: by 10.194.58.239 with SMTP id u15mr6811992wjq.87.1370909884259; Mon, 10 Jun 2013 17:18:04 -0700 (PDT) Received: by 10.194.83.35 with HTTP; Mon, 10 Jun 2013 17:18:04 -0700 (PDT) In-Reply-To: References: <51b23e6d.6196420a.0b15.4245SMTPIN_ADDED_BROKEN@mx.google.com> <51b4dbbe.64da440a.1fc2.6dd2SMTPIN_ADDED_BROKEN@mx.google.com> <51b4ec44.ea05420a.7c73.ffffa487SMTPIN_ADDED_BROKEN@mx.google.com> <51b507b1.c686e00a.3a7e.ffffa0adSMTPIN_ADDED_BROKEN@mx.google.com> <20130610201746.GC1057@mercury.ccil.org> <3CE20E15-8F9E-4727-BBE7-FBB06F7CAC24@jorgechamorro.com> Date: Mon, 10 Jun 2013 17:18:04 -0700 Message-ID: From: R S To: Paul Hoffman Content-Type: multipart/alternative; boundary=047d7ba97b94aba4f604ded5d41a Cc: "json@ietf.org" Subject: Re: [Json] Allow any JSON value at the top level X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 11 Jun 2013 00:18:06 -0000 --047d7ba97b94aba4f604ded5d41a Content-Type: text/plain; charset=ISO-8859-1 On Mon, Jun 10, 2013 at 4:56 PM, Paul Hoffman wrote: > > > Although I earlier supported the idea of any JSON value at the top level, > a bunch of recent posts show that this is probably a significant revision > to the RFC because it would take a lot of extra requirements as well. I now > support leaving the requirement in the -bis document as it is now. > Leaving the document as-is does not seem to be an option per the charter: "It is acknowledged that there are differences between RFC 4627 and the ECMAScript specification in the rules for parsing JSON. Any changes that break compatibility with existing implementations of either RFC 4627 or the ECMAScript specification will need to have very strong justification and broad support. All differences between RFC 4627 or the current ECMAScript specification will be documented in the new RFC." > If we want to add a new MIME type for "any JSON item", that is clearly a > significant addition to the RFC. It can wait until the WG recharters. A new media type would solve any problem that I'm aware of. - Rob --047d7ba97b94aba4f604ded5d41a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Mon, Jun 10, 2013 at 4:56 PM, Paul Hoffman <paul.h= offman@vpnc.org> wrote:
<no hat>

Although I earlier supported the idea of any JSON value at the top level, a= bunch of recent posts show that this is probably a significant revision to= the RFC because it would take a lot of extra requirements as well. I now s= upport leaving the requirement in the -bis document as it is now.

Leaving the document as-is does not = seem to be an option per the charter:

= "It is acknowledged that there are = differences between RFC 4627 and the
ECMAScript specification in the rules fo= r parsing JSON. Any changes that
break compatibility with existing implem= entations of either RFC 4627 or
the ECMAScript specification will need t= o have very strong justification
and broad support. All differences betwe= en RFC 4627 or the current
ECMAScript specification will be documen= ted in the new RFC."

=A0
If we want to add a new MIME type for "any JSON item", that is cl= early a significant addition to the RFC. It can wait until the WG recharter= s.

A new media type would solve any p= roblem that I'm aware of.

- Rob
--047d7ba97b94aba4f604ded5d41a-- From nico@cryptonector.com Mon Jun 10 17:30:22 2013 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 CC73811E80AE for ; Mon, 10 Jun 2013 17:30:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.962 X-Spam-Level: X-Spam-Status: No, score=-1.962 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hwI08vTssnA4 for ; Mon, 10 Jun 2013 17:30:17 -0700 (PDT) Received: from homiemail-a90.g.dreamhost.com (caiajhbdcbhh.dreamhost.com [208.97.132.177]) by ietfa.amsl.com (Postfix) with ESMTP id CC5DB11E80A5 for ; Mon, 10 Jun 2013 17:30:17 -0700 (PDT) Received: from homiemail-a90.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a90.g.dreamhost.com (Postfix) with ESMTP id 500D52AC005 for ; Mon, 10 Jun 2013 17:30:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=50D6QRiX3BTML5wlKqz1skPOTxM=; b=SyMxBn3vJ+x 6k8qdR3HZ/mgT8Nmrymbyr5z9QomSM8X3NmYj/3kgBL0jDQ9D0hKkW+U3M+HzJxF BsVxqVC5NYiSKLR5DUqoGXLC/tAumBRRgIcY8zwq8+KKd8emeqUuRcLBah+U3bSF mNL7oFKji7gElUuimzstJ0nhzKYEhybs= Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a90.g.dreamhost.com (Postfix) with ESMTPSA id 026302AC023 for ; Mon, 10 Jun 2013 17:30:16 -0700 (PDT) Received: by mail-we0-f172.google.com with SMTP id q56so5350409wes.17 for ; Mon, 10 Jun 2013 17:30:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=ZMprh2FyNDY5kAq9Dmm/ZtfDZTjr7ZGc3CBGFYfHy3I=; b=EqVC4mwPUIvYw/hCmw/chrWwKid6hq3/S3IIRLAXTOu/xMM+LkVNq4KpOiS/jqFULO abd4yW5R8mibz9DWLF23Pf4brtwCxqEmWw3DNSJOtOm9bF1I2nXhqWK39ZgeixC2Orau QJxvajhtX1aSxdQW3ncMcdyOw0+lhS02YkjHdyMUeWh4uYucs5U5/QVC1SNFsMLCA1KM P7tbOEDWoiP4epZtS8SaG0WLHd3nQfPNmE2osRNgGGGV9Ii0gJLVl/N4JorXOiWtpO9h 6mCLtsTSplIapi5w5f0V7/ZdV4qBGPayA2Ib9j52OmxMm5XA4idwWMfKb5KLN+4fRNM1 Wecw== MIME-Version: 1.0 X-Received: by 10.194.158.69 with SMTP id ws5mr5812402wjb.84.1370910615647; Mon, 10 Jun 2013 17:30:15 -0700 (PDT) Received: by 10.216.63.136 with HTTP; Mon, 10 Jun 2013 17:30:15 -0700 (PDT) In-Reply-To: References: <51b23e6d.6196420a.0b15.4245SMTPIN_ADDED_BROKEN@mx.google.com> <51b4dbbe.64da440a.1fc2.6dd2SMTPIN_ADDED_BROKEN@mx.google.com> <51b4ec44.ea05420a.7c73.ffffa487SMTPIN_ADDED_BROKEN@mx.google.com> <51b507b1.c686e00a.3a7e.ffffa0adSMTPIN_ADDED_BROKEN@mx.google.com> <20130610201746.GC1057@mercury.ccil.org> <3CE20E15-8F9E-4727-BBE7-FBB06F7CAC24@jorgechamorro.com> Date: Mon, 10 Jun 2013 19:30:15 -0500 Message-ID: From: Nico Williams To: Paul Hoffman Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: json@ietf.org Subject: Re: [Json] Allow any JSON value at the top level X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 11 Jun 2013 00:30:22 -0000 On Mon, Jun 10, 2013 at 6:56 PM, Paul Hoffman wrote= : > > > Although I earlier supported the idea of any JSON value at the top level,= a bunch of recent posts show that this is probably a significant revision = to the RFC because it would take a lot of extra requirements as well. I now= support leaving the requirement in the -bis document as it is now. > > If we want to add a new MIME type for "any JSON item", that is clearly a = significant addition to the RFC. It can wait until the WG recharters. I see no reason [yet... the way these threads have been going...] why we couldn't recommend that parsers be able to parse any top-level value, with the only interesting note being that end-of-message termination of numeric top-level values must not be accidentally confused with premature EOF. Also, we could just allow any non-numeric top-level value. With a similar recommendation for encoders. Nico -- From paul.hoffman@vpnc.org Mon Jun 10 19:02:15 2013 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 2879221E809B for ; Mon, 10 Jun 2013 19:02:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.432 X-Spam-Level: X-Spam-Status: No, score=-102.432 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r-+nhds9bPCl for ; Mon, 10 Jun 2013 19:02:10 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id B0CAF21E8099 for ; Mon, 10 Jun 2013 19:02:09 -0700 (PDT) Received: from [10.20.30.90] (50-0-66-165.dsl.dynamic.sonic.net [50.0.66.165]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r5B21f1x061237 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 10 Jun 2013 19:01:42 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Paul Hoffman In-Reply-To: <06e901ce6638$e8f27a90$bad76fb0$@augustcellars.com> Date: Mon, 10 Jun 2013 19:01:41 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <51DE7E41-D682-4340-A234-7F7CFE513C10@vpnc.org> References: <06c101ce6625$0f891bf0$2e9b53d0$@augustcellars.com> <379266A1-82C1-4FF5-BD7C-EE657F1FD41F@vpnc.org> <06e901ce6638$e8f27a90$bad76fb0$@augustcellars.com> To: Jim Schaad X-Mailer: Apple Mail (2.1508) Cc: json@ietf.org Subject: Re: [Json] Leading and trailing whitespace X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 11 Jun 2013 02:02:15 -0000 On Jun 10, 2013, at 5:16 PM, Jim Schaad wrote: > My intention here has nothing to do with canonicalization and = everything to > do with what constitutes a valid string from a parsing perspective. >=20 > Consider for example the case of a text file which consists of a JSON = text > string with a trailing CRLF in the file. If trailing whitespace is = allowed > then the entire text file is a legal JSON text string. If the = trailing > whitespace is not allowed then it is not a legal JSON text string. I = am > just trying to clarify which is true. The "JSON text string" (called a "string" in RFC 4627) starts and ends = with a quotation mark: string =3D quotation-mark *char quotation-mark There is no "ws" anywhere there, but there sure are quotation marks. > This makes a difference with the argument about moving all of the = values to > the top level since then the string (ignore the quotes) " true \r\n" > cannot be matched if you just want to say it is a Boolean literal = (i.e. the > non-terminator true). Instead you need to say that it can have = whitespace > on either side of it. The current grammar does not allow whitespace around "true" for that = boolean value. > I will agree that the original intention probably is just a question = of > academic interest. The real question I should have asked would be are > people taking advantage of the fact. >=20 > That is the question of what about normal whitespace. I would be interested if anyone sees anything in the document that = disagrees with the above. > I think there is a question about parsers that would accept the string >=20 > {"a":"b"}A >=20 > As I believe there are some that will (stop when you get to the end of = the > object) and some that will not. If that is meant to be a JSON text, I cannot imagine how that is valid, = but maybe I'm not creative enough. --Paul Hoffman= From paul.hoffman@vpnc.org Mon Jun 10 19:05:57 2013 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 1FD9C21F9942 for ; Mon, 10 Jun 2013 19:05:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.436 X-Spam-Level: X-Spam-Status: No, score=-102.436 tagged_above=-999 required=5 tests=[AWL=0.163, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Orbupepb7JeH for ; Mon, 10 Jun 2013 19:05:54 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 54FF521F972C for ; Mon, 10 Jun 2013 19:05:54 -0700 (PDT) Received: from [10.20.30.90] (50-0-66-165.dsl.dynamic.sonic.net [50.0.66.165]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r5B25p5V061298 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 10 Jun 2013 19:05:52 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Paul Hoffman In-Reply-To: Date: Mon, 10 Jun 2013 19:05:51 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <29C7B970-C97D-47E2-9C91-272B2C18E3D1@vpnc.org> References: <51b23e6d.6196420a.0b15.4245SMTPIN_ADDED_BROKEN@mx.google.com> <51b4dbbe.64da440a.1fc2.6dd2SMTPIN_ADDED_BROKEN@mx.google.com> <51b4ec44.ea05420a.7c73.ffffa487SMTPIN_ADDED_BROKEN@mx.google.com> <51b507b1.c686e00a.3a7e.ffffa0adSMTPIN_ADDED_BROKEN@mx.google.com> <20130610201746.GC1057@mercury.ccil.org> <3CE20E15-8F9E-4727-BBE7-FBB06F7CAC24@jorgechamorro.com> To: Nico Williams X-Mailer: Apple Mail (2.1508) Cc: json@ietf.org Subject: Re: [Json] Allow any JSON value at the top level X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 11 Jun 2013 02:05:58 -0000 On Jun 10, 2013, at 5:30 PM, Nico Williams = wrote: > On Mon, Jun 10, 2013 at 6:56 PM, Paul Hoffman = wrote: >> >>=20 >> Although I earlier supported the idea of any JSON value at the top = level, a bunch of recent posts show that this is probably a significant = revision to the RFC because it would take a lot of extra requirements as = well. I now support leaving the requirement in the -bis document as it = is now. >>=20 >> If we want to add a new MIME type for "any JSON item", that is = clearly a significant addition to the RFC. It can wait until the WG = recharters. >=20 > I see no reason [yet... the way these threads have been going...] why > we couldn't recommend that parsers be able to parse any top-level > value, with the only interesting note being that end-of-message > termination of numeric top-level values must not be accidentally > confused with premature EOF. Also, we could just allow any > non-numeric top-level value. With a similar recommendation for > encoders. Why add any recommendation for parsers for that case? The current doc = already has: A JSON parser MAY accept non-JSON forms or extensions. --Paul Hoffman From cowan@ccil.org Mon Jun 10 19:11:21 2013 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 460B421F9954 for ; Mon, 10 Jun 2013 19:11:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.415 X-Spam-Level: X-Spam-Status: No, score=-3.415 tagged_above=-999 required=5 tests=[AWL=0.184, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 47o+GOTUI7KW for ; Mon, 10 Jun 2013 19:11:16 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id CABDF21F9953 for ; Mon, 10 Jun 2013 19:11:16 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1UmE3A-0001tl-M1; Mon, 10 Jun 2013 22:11:08 -0400 Date: Mon, 10 Jun 2013 22:11:08 -0400 From: John Cowan To: Paul Hoffman Message-ID: <20130611021108.GE1057@mercury.ccil.org> References: <51b507b1.c686e00a.3a7e.ffffa0adSMTPIN_ADDED_BROKEN@mx.google.com> <20130610201746.GC1057@mercury.ccil.org> <3CE20E15-8F9E-4727-BBE7-FBB06F7CAC24@jorgechamorro.com> <29C7B970-C97D-47E2-9C91-272B2C18E3D1@vpnc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <29C7B970-C97D-47E2-9C91-272B2C18E3D1@vpnc.org> User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Cc: Nico Williams , json@ietf.org Subject: Re: [Json] Allow any JSON value at the top level X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 11 Jun 2013 02:11:21 -0000 Paul Hoffman scripsit: > Why add any recommendation for parsers for that case? The current doc > already has: > > A JSON parser MAY accept non-JSON forms or extensions. That combined with the lack of a data model, or any requirements on parsers to report anything, means that `cat` counts as a JSON parser currently: it will not reject any legal JSON, it accepts non-JSON forms (to wit, anything), and it reports its input exactly. Is it in scope to fix that? That would mean some kind of data model and reporting requirements in section 4. -- Babies are born as a result of the John Cowan mating between men and women, and most http://www.ccil.org/~cowan men and women enjoy mating. cowan@ccil.org --Isaac Asimov in Earth: Our Crowded Spaceship From jsontest@yahoo.com Mon Jun 10 19:19:27 2013 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 7C7C721F9953 for ; Mon, 10 Jun 2013 19:19:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.397 X-Spam-Level: X-Spam-Status: No, score=0.397 tagged_above=-999 required=5 tests=[AWL=1.600, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BZSpmrhvGvQz for ; Mon, 10 Jun 2013 19:19:21 -0700 (PDT) Received: from nm20-vm5.bullet.mail.ne1.yahoo.com (nm20-vm5.bullet.mail.ne1.yahoo.com [98.138.91.242]) by ietfa.amsl.com (Postfix) with ESMTP id 8474521F9950 for ; Mon, 10 Jun 2013 19:19:21 -0700 (PDT) Received: from [98.138.90.50] by nm20.bullet.mail.ne1.yahoo.com with NNFMP; 11 Jun 2013 02:19:20 -0000 Received: from [98.138.226.126] by tm3.bullet.mail.ne1.yahoo.com with NNFMP; 11 Jun 2013 02:19:20 -0000 Received: from [127.0.0.1] by smtp205.mail.ne1.yahoo.com with NNFMP; 11 Jun 2013 02:19:20 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1370917160; bh=7va2TCDBGg4bqKT0ykBxvn09nYRsWQSdmXvnVxje5Gs=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:References:In-Reply-To:Mime-Version:Content-Type:Content-Transfer-Encoding:Message-Id:Cc:X-Mailer:From:Subject:Date:To; b=Oq4w/yArJ0+xkz1+1YiWvf+KL1xDc92AiybIh59Xr9xndz9ScceW2bU6+I5XNykKnSXC7EuDL/2wYvtWpeThT5iEiZj+V+a0Fo1naeHCSLFaYxon9wYomDobgY7faK0MZ7ACEO9zvbP4/9emIIgKRlYi9aCnJOn41GNP2ht2Eks= X-Yahoo-Newman-Id: 547209.11739.bm@smtp205.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: hoKTbIwVM1nPUAgBD4b2yh1VpXazBSiaAHrUW.pQb1MpXAt icQCez1yTH2TXfFFGF_VCItl3eSoo_fhPNkr1NKQZZyNEcnGbfPdxLPWP8E4 9B.6sBIGGxMALDvtMCGvKDW8lRNze6Uip7vk.jBi8fxPKhn8wVc7_f0HczQT jt2sjbROhDgBhpwVF6HcCcfoE53RZuFpWzhYbKFbvFqTMYyeVd4r9FwMiLpk Q6tFDaRWt4esmHgQMNqTw9m_B4XDZ1GffKvBDon1tQ.yF3cKkXmMSRvHNIaP r.NYyxan4cocRH8SX0nsl4H3GthGWoZr5bfeEK8gAEU3j_IpZuSRC2ylOOoy fiiZbVqF98RzAqVjv7Rmyuw1AXt5cwQr0ihigj7vtPu5fC_b9vFuF8C.38HR 2EEOd528VQNFXrkNWPA04d01q9XY26ftCiYDRvY4jPNxlPLntDjwKifLX.XN Qk9P83iImVkLP3eFsFusoWIac5Lcs3tbdV4BAMUt4SELlyMf6RyVKcPL9DBk xfmdoVEKiwM.wrmLR358HH0Rg X-Yahoo-SMTP: indQcmSswBC8IKsm6t4aCAPskK3T X-Rocket-Received: from [192.168.0.102] (jsontest@76.29.100.42 with ) by smtp205.mail.ne1.yahoo.com with SMTP; 10 Jun 2013 19:19:20 -0700 PDT References: <51B58261.5040808@drees.name> <8512D965-C32C-4C69-A709-350333C925A0@vpnc.org> In-Reply-To: <8512D965-C32C-4C69-A709-350333C925A0@vpnc.org> Mime-Version: 1.0 (1.0) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <79A6DD85-1BBF-4F78-903D-8CD76641F4C0@yahoo.com> X-Mailer: iPod Mail (9B206) From: Vinny A Date: Mon, 10 Jun 2013 21:19:18 -0500 To: Paul Hoffman Cc: "stefan@drees.name" , "json@ietf.org" Subject: Re: [Json] Generators X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 11 Jun 2013 02:19:27 -0000 On Jun 10, 2013, at 12:35 PM, Paul Hoffman wrote: >> Generators MUST NOT duplicate names in objects if they can avoid or >> detect such duplication. >=20 > +1 to the others who have said "yuck" to the poor use of 2119 MUST here. Fu= rther, this is a significant change from both RFC 4726 and ECMAScript. Propo= sed new wording: >=20 > Generators SHOULD NOT create objects that have duplicate names because obj= ects with duplicate names can be interpreted in different ways by conformant= JSON parsers. +1 Mr. Crockford and others have already stated that a SHOULD is mandatory in r= egards to duplicate keys - there's so many implementation and archive headac= hes with parsers that a MUST or MUST NOT is never going to fly. ----------------- Vinny www.jsontest.com From ietf@augustcellars.com Mon Jun 10 19:33:25 2013 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 AD55021E80A0 for ; Mon, 10 Jun 2013 19:33:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IQ8CE5SO-otW for ; Mon, 10 Jun 2013 19:33:19 -0700 (PDT) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by ietfa.amsl.com (Postfix) with ESMTP id C154021E805A for ; Mon, 10 Jun 2013 19:33:19 -0700 (PDT) Received: from Philemon (mail.augustcellars.com [50.34.17.238]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id 9E9C72C9F8; Mon, 10 Jun 2013 19:33:11 -0700 (PDT) From: "Jim Schaad" To: "'Paul Hoffman'" References: <06c101ce6625$0f891bf0$2e9b53d0$@augustcellars.com> <379266A1-82C1-4FF5-BD7C-EE657F1FD41F@vpnc.org> <06e901ce6638$e8f27a90$bad76fb0$@augustcellars.com> <51DE7E41-D682-4340-A234-7F7CFE513C10@vpnc.org> In-Reply-To: <51DE7E41-D682-4340-A234-7F7CFE513C10@vpnc.org> Date: Mon, 10 Jun 2013 19:32:19 -0700 Message-ID: <070b01ce664b$e5e0ac10$b1a20430$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIjA7ejHysocqIyb9p/XvW1gI4I3gIdfG2fAXcnW3oCcTmHLZhWYFCA Content-Language: en-us Cc: json@ietf.org Subject: Re: [Json] Leading and trailing whitespace X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 11 Jun 2013 02:33:25 -0000 > -----Original Message----- > From: Paul Hoffman [mailto:paul.hoffman@vpnc.org] > Sent: Monday, June 10, 2013 7:02 PM > To: Jim Schaad > Cc: json@ietf.org > Subject: Re: [Json] Leading and trailing whitespace > > On Jun 10, 2013, at 5:16 PM, Jim Schaad wrote: > > > My intention here has nothing to do with canonicalization and > > everything to do with what constitutes a valid string from a parsing > perspective. > > > > Consider for example the case of a text file which consists of a JSON > > text string with a trailing CRLF in the file. If trailing whitespace > > is allowed then the entire text file is a legal JSON text string. If > > the trailing whitespace is not allowed then it is not a legal JSON > > text string. I am just trying to clarify which is true. > > The "JSON text string" (called a "string" in RFC 4627) starts and ends with a > quotation mark: > string = quotation-mark *char quotation-mark There is no "ws" anywhere > there, but there sure are quotation marks. > Ok - I used the wrong term - I need to get them clearer, I still am trying to learn - Please read JSON text for JSON text string. I was not using string as a value in this location. > > This makes a difference with the argument about moving all of the values > to > > the top level since then the string (ignore the quotes) " true \r\n" > > cannot be matched if you just want to say it is a Boolean literal > > (i.e. the non-terminator true). Instead you need to say that it can > > have whitespace on either side of it. > > The current grammar does not allow whitespace around "true" for that > boolean value. Actually it does, but the whitespace comes from the container it is in. The current grammar does not allow true at the top level and if that does not change then the above remains a moot point. Note that the text was talking about moving all values to the top level. > > > I will agree that the original intention probably is just a question > > of academic interest. The real question I should have asked would be > > are people taking advantage of the fact. > > > > That is the question of what about normal whitespace. > > I would be interested if anyone sees anything in the document that > disagrees with the above. > > > I think there is a question about parsers that would accept the string > > > > {"a":"b"}A > > > > As I believe there are some that will (stop when you get to the end of > > the > > object) and some that will not. > > If that is meant to be a JSON text, I cannot imagine how that is valid, but > maybe I'm not creative enough. Yes -but what I am saying is that there are (probably) parsers which stop before the string has been fully consumed. Thus they would accept the string as valid. Jim > > --Paul Hoffman= From tbray@textuality.com Mon Jun 10 19:44:04 2013 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 E4F8121F9702 for ; Mon, 10 Jun 2013 19:44:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.561 X-Spam-Level: X-Spam-Status: No, score=-1.561 tagged_above=-999 required=5 tests=[AWL=1.415, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uGxo2tp7yj7b for ; Mon, 10 Jun 2013 19:44:00 -0700 (PDT) Received: from mail-vc0-f181.google.com (mail-vc0-f181.google.com [209.85.220.181]) by ietfa.amsl.com (Postfix) with ESMTP id F265721F96DF for ; Mon, 10 Jun 2013 19:43:59 -0700 (PDT) Received: by mail-vc0-f181.google.com with SMTP id lf11so4141523vcb.26 for ; Mon, 10 Jun 2013 19:43:59 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=77HV8HdB+ln7KqhRe5CxwVztiNMJUBCkYPYVpNeAQ6k=; b=jCFRn6bqSSyZ/lLsaBBpO5qBrt8DgHmv6x9WswoXiSNvUhEOxRwb6WN3FwsIyoNYR6 MCdgizG6jg3SwqFPL0J7LV1/npIdwXbF2ova+7NQQqXkrZQjMtBFeLvDB5d6GiMMfbae 3zImkv4JtvaXJ9Yg/sQfKAG9VvzTHD0XOG/HwqYrGdNkscUEPuFXoUi5oKt8IJvbPSCU 5IkHGcEC5LY5/l5wC4L5gfgO2l7Dz7/qn+6h174QzDss5vAl668ZcO9T8O0gYCnBedLY cM9KO6+kTWH4FvdU2cGkyX6bcOte3PgzAIfkUrFzc57j+SrwvegrZorguX9reM7DFg4a WRAg== MIME-Version: 1.0 X-Received: by 10.58.40.42 with SMTP id u10mr2540028vek.39.1370918639406; Mon, 10 Jun 2013 19:43:59 -0700 (PDT) Received: by 10.220.25.199 with HTTP; Mon, 10 Jun 2013 19:43:59 -0700 (PDT) X-Originating-IP: [24.84.235.32] In-Reply-To: References: <51b23e6d.6196420a.0b15.4245SMTPIN_ADDED_BROKEN@mx.google.com> <51b4dbbe.64da440a.1fc2.6dd2SMTPIN_ADDED_BROKEN@mx.google.com> <51b4ec44.ea05420a.7c73.ffffa487SMTPIN_ADDED_BROKEN@mx.google.com> <51b507b1.c686e00a.3a7e.ffffa0adSMTPIN_ADDED_BROKEN@mx.google.com> <20130610201746.GC1057@mercury.ccil.org> <3CE20E15-8F9E-4727-BBE7-FBB06F7CAC24@jorgechamorro.com> Date: Mon, 10 Jun 2013 19:43:59 -0700 Message-ID: From: Tim Bray To: R S Content-Type: multipart/alternative; boundary=089e0129420c84a40004ded7de2c X-Gm-Message-State: ALoCoQmkNw3tBguNnFcmVlcnz5w9u/lrYLhQsbkisS3UGO6dqzMInbDukpfdA9g2vAtIp0WS094/ Cc: Paul Hoffman , "json@ietf.org" Subject: Re: [Json] Allow any JSON value at the top level X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 11 Jun 2013 02:44:05 -0000 --089e0129420c84a40004ded7de2c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Rob, just to make sure I understand, you=E2=80=99re saying that because ECM= A doesn=E2=80=99t impose the 4627 restriction that a top-level object has to = be a composite, 4627bis has to be changed to acknowledge that? -T On Mon, Jun 10, 2013 at 5:18 PM, R S wrote: > On Mon, Jun 10, 2013 at 4:56 PM, Paul Hoffman wrot= e: > >> >> >> Although I earlier supported the idea of any JSON value at the top level= , >> a bunch of recent posts show that this is probably a significant revisio= n >> to the RFC because it would take a lot of extra requirements as well. I = now >> support leaving the requirement in the -bis document as it is now. >> > > Leaving the document as-is does not seem to be an option per the charter: > > "It is acknowledged that there are differences between RFC 4627 and the > ECMAScript specification in the rules for parsing JSON. Any changes that > break compatibility with existing implementations of either RFC 4627 or > the ECMAScript specification will need to have very strong justification > and broad support. All differences between RFC 4627 or the current > ECMAScript specification will be documented in the new RFC." > > > >> If we want to add a new MIME type for "any JSON item", that is clearly a >> significant addition to the RFC. It can wait until the WG recharters. > > > A new media type would solve any problem that I'm aware of. > > - Rob > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > > --089e0129420c84a40004ded7de2c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Rob, just to make sure I understand, you=E2=80=99re saying= that because ECMA doesn=E2=80=99t impose the 4627 restriction that a top-l= evel object has to be a composite, 4627bis has to be changed to acknowledge= that?=C2=A0 -T



On Mon, Jun 10, 2013 at 5:18 PM, R S <sayrer@gmail= .com> wrote:
On Mon, J= un 10, 2013 at 4:56 PM, Paul Hoffman <paul.hoffman@vpnc.org> wrote:
<no hat>

Although I earlier supported the idea of any JSON value at the top level, a= bunch of recent posts show that this is probably a significant revision to= the RFC because it would take a lot of extra requirements as well. I now s= upport leaving the requirement in the -bis document as it is now.

Leaving the document as-is does not = seem to be an option per the charter:

"It is acknowledged that there are differences between RFC 4627= and the
ECMAScript specification in the rules for parsing JSON. A= ny changes that
break compatibility with existing implementations of eith= er RFC 4627 or
the ECMAScript specification will need to have very stron= g justification
and broad support. All differences between RFC 4627 or th= e current
ECMAScript specification will be documented in the new RF= C."

=C2=A0
=
If we want to add a new MIME type for "any JSON item", that is cl= early a significant addition to the RFC. It can wait until the WG recharter= s.

A new media type would solve any p= roblem that I'm aware of.

- Rob

_______________________________________________
json mailing list
json@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/json


--089e0129420c84a40004ded7de2c-- From paul.hoffman@vpnc.org Mon Jun 10 19:54:00 2013 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 C2AA821F8808 for ; Mon, 10 Jun 2013 19:53:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.44 X-Spam-Level: X-Spam-Status: No, score=-102.44 tagged_above=-999 required=5 tests=[AWL=0.159, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9XAHZCtaxmWf for ; Mon, 10 Jun 2013 19:53:51 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 0758021F86C0 for ; Mon, 10 Jun 2013 19:53:49 -0700 (PDT) Received: from [10.20.30.90] (50-0-66-165.dsl.dynamic.sonic.net [50.0.66.165]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r5B2rPxO062696 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 10 Jun 2013 19:53:26 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Paul Hoffman In-Reply-To: <070b01ce664b$e5e0ac10$b1a20430$@augustcellars.com> Date: Mon, 10 Jun 2013 19:53:25 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <6E03D281-D6BA-424D-A30A-3DA18E61A051@vpnc.org> References: <06c101ce6625$0f891bf0$2e9b53d0$@augustcellars.com> <379266A1-82C1-4FF5-BD7C-EE657F1FD41F@vpnc.org> <06e901ce6638$e8f27a90$bad76fb0$@augustcellars.com> <51DE7E41-D682-4340-A234-7F7CFE513C10@vpnc.org> <070b01ce664b$e5e0ac10$b1a20430$@augustcellars.com> To: "Jim Schaad" X-Mailer: Apple Mail (2.1508) Cc: json@ietf.org Subject: Re: [Json] Leading and trailing whitespace X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 11 Jun 2013 02:54:09 -0000 On Jun 10, 2013, at 7:32 PM, "Jim Schaad" = wrote: > Ok - I used the wrong term - I need to get them clearer, I still am = trying > to learn - Please read JSON text for JSON text string. I was not = using > string as a value in this location. You can't ask that question because the current doc only allows arrays = and objects at the top level, and the starting character for each of = those allow for white space. You might be asking "if we allow other JSON items at the top level, will = we also allow optional whitespace before and after". But that's a = supposition, not a question about what is in the document now. >>> This makes a difference with the argument about moving all of the = values >> to >>> the top level since then the string (ignore the quotes) " true = \r\n" >>> cannot be matched if you just want to say it is a Boolean literal >>> (i.e. the non-terminator true). Instead you need to say that it can >>> have whitespace on either side of it. >>=20 >> The current grammar does not allow whitespace around "true" for that >> boolean value. >=20 > Actually it does, but the whitespace comes from the container it is = in. =20 You have changed the subject of the question, then. You were asking = about the top level, without a container. I claim my answer is correct = for the question you asked. > The > current grammar does not allow true at the top level and if that does = not > change then the above remains a moot point. Note that the text was = talking > about moving all values to the top level. None of the objects other than arrays and objects have optional = whitespace. None. > Yes -but what I am saying is that there are (probably) parsers which = stop > before the string has been fully consumed. Thus they would accept the > string as valid. There are (probably) parsers that do all sorts of stupid, non-conformant = things. Why is that relevant here? --Paul Hoffman= From paul.hoffman@vpnc.org Mon Jun 10 19:57:43 2013 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 7B89321E804E for ; Mon, 10 Jun 2013 19:57:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.443 X-Spam-Level: X-Spam-Status: No, score=-102.443 tagged_above=-999 required=5 tests=[AWL=0.156, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PD4dDkoEbTvu for ; Mon, 10 Jun 2013 19:57:43 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id E26B611E80BA for ; Mon, 10 Jun 2013 19:57:42 -0700 (PDT) Received: from [10.20.30.90] (50-0-66-165.dsl.dynamic.sonic.net [50.0.66.165]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r5B2venx062787 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 10 Jun 2013 19:57:41 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Paul Hoffman In-Reply-To: Date: Mon, 10 Jun 2013 19:57:40 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <51b23e6d.6196420a.0b15.4245SMTPIN_ADDED_BROKEN@mx.google.com> <51b4dbbe.64da440a.1fc2.6dd2SMTPIN_ADDED_BROKEN@mx.google.com> <51b4ec44.ea05420a.7c73.ffffa487SMTPIN_ADDED_BROKEN@mx.google.com> <51b507b1.c686e00a.3a7e.ffffa0adSMTPIN_ADDED_BROKEN@mx.google.com> <20130610201746.GC1057@mercury.ccil.org> <3CE20E15-8F9E-4727-BBE7-FBB06F7CAC24@jorgechamorro.com> To: R S X-Mailer: Apple Mail (2.1508) Cc: "" Subject: Re: [Json] Allow any JSON value at the top level X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 11 Jun 2013 02:57:43 -0000 On Jun 10, 2013, at 7:38 PM, R S wrote: > On Mon, Jun 10, 2013 at 7:04 PM, Paul Hoffman = wrote: >=20 > Good catch. When I said "as-is", I meant "don't change the current = text". We need to add a point to the differences section for = 4627-ECMAScript, and would need to duplicate that in the section for the = current-doc-ECMAScript section. >=20 > Wouldn't that be a section that amounts to "here's what you need to do = to interoperate with browsers and most other popular implementations"? Oh gopod no. I certainly hope the WG find that defining "browser" and = "most" and "popular" is out of scope. > Many endpoints only accept specific root elements. For example, = json-patch only accepts arrays. In other words, no one will notice if = your JSON parser only accepts objects and arrays.=20 >=20 > What is the benefit of preserving RFC 4627 requirements? I don't = understand the rationale accompanying your opinion. The charter mandates = that the WG document top-level primitive parsing, no matter what. Fully agree on the last part. But "document" does not mean "change the = requirements". We can say "the requirement is X" and "X differs from = 4627 and/or ECMAScript", at least in my reading of the charter. --Paul Hoffman= From ietf@augustcellars.com Mon Jun 10 20:02:36 2013 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 C457111E80D5 for ; Mon, 10 Jun 2013 20:02:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qUP8Ws7Mqs23 for ; Mon, 10 Jun 2013 20:02:26 -0700 (PDT) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by ietfa.amsl.com (Postfix) with ESMTP id 4239E11E80CC for ; Mon, 10 Jun 2013 20:02:26 -0700 (PDT) Received: from Philemon (mail.augustcellars.com [50.34.17.238]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp1.pacifier.net (Postfix) with ESMTPSA id ADEA22C9F4; Mon, 10 Jun 2013 20:02:25 -0700 (PDT) From: "Jim Schaad" To: "'Paul Hoffman'" References: <06c101ce6625$0f891bf0$2e9b53d0$@augustcellars.com> <379266A1-82C1-4FF5-BD7C-EE657F1FD41F@vpnc.org> <06e901ce6638$e8f27a90$bad76fb0$@augustcellars.com> <51DE7E41-D682-4340-A234-7F7CFE513C10@vpnc.org> <070b01ce664b$e5e0ac10$b1a20430$@augustcellars.com> <6E03D281-D6BA-424D-A30A-3DA18E61A051@vpnc.org> In-Reply-To: <6E03D281-D6BA-424D-A30A-3DA18E61A051@vpnc.org> Date: Mon, 10 Jun 2013 20:01:33 -0700 Message-ID: <071201ce664f$fb885af0$f29910d0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIjA7ejHysocqIyb9p/XvW1gI4I3gIdfG2fAXcnW3oCcTmHLQEVs18kAL9FaTSYR8EgoA== Content-Language: en-us Cc: json@ietf.org Subject: Re: [Json] Leading and trailing whitespace X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 11 Jun 2013 03:02:36 -0000 > -----Original Message----- > From: Paul Hoffman [mailto:paul.hoffman@vpnc.org] > Sent: Monday, June 10, 2013 7:53 PM > To: Jim Schaad > Cc: json@ietf.org > Subject: Re: [Json] Leading and trailing whitespace > > On Jun 10, 2013, at 7:32 PM, "Jim Schaad" wrote: > > > Ok - I used the wrong term - I need to get them clearer, I still am > > trying to learn - Please read JSON text for JSON text string. I was > > not using string as a value in this location. > > You can't ask that question because the current doc only allows arrays and > objects at the top level, and the starting character for each of those allow for > white space. > > You might be asking "if we allow other JSON items at the top level, will we > also allow optional whitespace before and after". But that's a supposition, > not a question about what is in the document now. That must mean I still don't have the correct term I have not changed the subject here. {"a":"b"}\r\n Is that legal and should it be legal - the current ABNF says yes. What do current parsers say? > > > >>> This makes a difference with the argument about moving all of the > >>> values > >> to > >>> the top level since then the string (ignore the quotes) " true \r\n" > >>> cannot be matched if you just want to say it is a Boolean literal > >>> (i.e. the non-terminator true). Instead you need to say that it can > >>> have whitespace on either side of it. > >> > >> The current grammar does not allow whitespace around "true" for that > >> boolean value. > > > > Actually it does, but the whitespace comes from the container it is in. > > You have changed the subject of the question, then. You were asking about > the top level, without a container. I claim my answer is correct for the > question you asked. > > > The > > current grammar does not allow true at the top level and if that does > > not change then the above remains a moot point. Note that the text > > was talking about moving all values to the top level. > > None of the objects other than arrays and objects have optional whitespace. > None. > > > Yes -but what I am saying is that there are (probably) parsers which > > stop before the string has been fully consumed. Thus they would > > accept the string as valid. > > There are (probably) parsers that do all sorts of stupid, non-conformant > things. Why is that relevant here? We made some explicit decisions in the JOSE working group based on some of the above issues. I was just verifying that we had the correct assumptions in making those decisions. > > --Paul Hoffman= From sayrer@gmail.com Mon Jun 10 20:06:21 2013 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 98C7721E80AE for ; Mon, 10 Jun 2013 20:06:21 -0700 (PDT) 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=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5-elFd8CTiXQ for ; Mon, 10 Jun 2013 20:06:20 -0700 (PDT) Received: from mail-wg0-x234.google.com (mail-wg0-x234.google.com [IPv6:2a00:1450:400c:c00::234]) by ietfa.amsl.com (Postfix) with ESMTP id 7244621E80AD for ; Mon, 10 Jun 2013 20:06:20 -0700 (PDT) Received: by mail-wg0-f52.google.com with SMTP id z12so4829601wgg.19 for ; Mon, 10 Jun 2013 20:06:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=J963Po/3Mg56F4opOXGxodlizGkxpEbFbk46QmZp3cI=; b=JEVaBQgWGLQvmJ6xrHrlC8G2nfj9p/QyOv3MStTBJQ6sKU9oc5DXEMTcz2OzY5l41h hAoRmCXWP4QFLfnaFhbBXJzHt5ObDvgc7DE3hlSevfBzKwpo5dR0PviET4oRw7DPXmo0 R7yl0kHSVjTLE65OcE3gFaA3QHdwwDmX8gJDwHP0+xqb7sGlWt7Y1pQbhXW0NBVQWHfL jknrnhUK7meJxXUz85jbSfH1Aixx+dPerHi0Aa8rBZ+GncP3fuRE+j8tpOtohaOxEDvK mt2V1BVbz4DjbiThkxllT2TPwVI8ooPV9FS/VEKBE3Epl0ovkHUbWqZZ4eOBHu+/NapI kUdQ== MIME-Version: 1.0 X-Received: by 10.194.63.229 with SMTP id j5mr6991585wjs.79.1370919978327; Mon, 10 Jun 2013 20:06:18 -0700 (PDT) Received: by 10.194.83.35 with HTTP; Mon, 10 Jun 2013 20:06:18 -0700 (PDT) In-Reply-To: References: <51b23e6d.6196420a.0b15.4245SMTPIN_ADDED_BROKEN@mx.google.com> <51b4dbbe.64da440a.1fc2.6dd2SMTPIN_ADDED_BROKEN@mx.google.com> <51b4ec44.ea05420a.7c73.ffffa487SMTPIN_ADDED_BROKEN@mx.google.com> <51b507b1.c686e00a.3a7e.ffffa0adSMTPIN_ADDED_BROKEN@mx.google.com> <20130610201746.GC1057@mercury.ccil.org> <3CE20E15-8F9E-4727-BBE7-FBB06F7CAC24@jorgechamorro.com> Date: Mon, 10 Jun 2013 20:06:18 -0700 Message-ID: From: R S To: Tim Bray Content-Type: multipart/alternative; boundary=047d7ba97518532c3604ded82e8f Cc: Paul Hoffman , "json@ietf.org" Subject: Re: [Json] Allow any JSON value at the top level X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 11 Jun 2013 03:06:21 -0000 --047d7ba97518532c3604ded82e8f Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Mon, Jun 10, 2013 at 7:43 PM, Tim Bray wrote: > Rob, just to make sure I understand, you=92re saying that because ECMA > doesn=92t impose the 4627 restriction that a top-level object has to be a > composite, 4627bis has to be changed to acknowledge that? -T > I think the charter obligates the WG to document the difference. Whether that takes the form of a normative requirement is another matter. On a practical level, I'm not sure what the value of an informational section rather than a requirement would be. It would be great if someone could give a rationale for that. I think there's value in having the Standards-Track RFC be an accurate description of requirements for interoperability. What good does it do us to have a non-normative section that is actually required to interoperate with browsers and most other implementations? Speaking as someone that updated a widely-used implementation to support primitive root values, - Rob > > On Mon, Jun 10, 2013 at 5:18 PM, R S wrote: > >> On Mon, Jun 10, 2013 at 4:56 PM, Paul Hoffman wro= te: >> >>> >>> >>> Although I earlier supported the idea of any JSON value at the top >>> level, a bunch of recent posts show that this is probably a significant >>> revision to the RFC because it would take a lot of extra requirements a= s >>> well. I now support leaving the requirement in the -bis document as it = is >>> now. >>> >> >> Leaving the document as-is does not seem to be an option per the charter= : >> >> "It is acknowledged that there are differences between RFC 4627 and the >> ECMAScript specification in the rules for parsing JSON. Any changes that >> break compatibility with existing implementations of either RFC 4627 or >> the ECMAScript specification will need to have very strong justification >> and broad support. All differences between RFC 4627 or the current >> ECMAScript specification will be documented in the new RFC." >> >> >> >>> If we want to add a new MIME type for "any JSON item", that is clearly = a >>> significant addition to the RFC. It can wait until the WG recharters. >> >> >> A new media type would solve any problem that I'm aware of. >> >> - Rob >> >> _______________________________________________ >> json mailing list >> json@ietf.org >> https://www.ietf.org/mailman/listinfo/json >> >> > --047d7ba97518532c3604ded82e8f Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
On Mon, Jun 10, 2013 at 7:43 PM, Tim Bray <tbray@textu= ality.com> wrote:
Rob, just to make sure I un= derstand, you=92re saying that because ECMA doesn=92t impose the 4627 restr= iction that a top-level object has to be a composite, 4627bis has to be cha= nged to acknowledge that?=A0 -T

I think the charter obligates the WG= to document the difference. Whether that takes the form of a normative req= uirement is another matter.

On a pract= ical level, I'm not sure what the value of an informational section rat= her than a requirement would be. It would be great if someone could give a = rationale for that.

I think there's value in having the Sta= ndards-Track RFC be an accurate description of requirements for interoperab= ility. What good does it do us to have a non-normative section that is actu= ally required to interoperate with browsers and most other implementations?=

Speaking as someone that updated a widely-u= sed implementation to support primitive root values,

- Rob

=A0

On Mon, Jun 1= 0, 2013 at 5:18 PM, R S <sayrer@gmail.com> wrote:
On Mon, Jun 10, 2013 at 4:56 PM, Paul Hoffman <paul.hoff= man@vpnc.org> wrote:
<no hat>

Although I earlier supported the idea of any JSON value at the top level, a= bunch of recent posts show that this is probably a significant revision to= the RFC because it would take a lot of extra requirements as well. I now s= upport leaving the requirement in the -bis document as it is now.

Leaving the document as-is does not = seem to be an option per the charter:

"It is acknowledged that there are differences between RFC 4627= and the
ECMAScript specification in the rules for parsing JSON. A= ny changes that
break compatibility with existing implementations of eith= er RFC 4627 or
the ECMAScript specification will need to have very stron= g justification
and broad support. All differences between RFC 4627 or th= e current
ECMAScript specification will be documented in the new RF= C."

=A0
If we want to add a new MIME type for "any JSON item", that is cl= early a significant addition to the RFC. It can wait until the WG recharter= s.

A new media type would solve any p= roblem that I'm aware of.

- Rob

_________________________________________= ______
json mailing list
json@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/json



--047d7ba97518532c3604ded82e8f-- From jsontest@yahoo.com Mon Jun 10 20:07:23 2013 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 6A47F11E80D7 for ; Mon, 10 Jun 2013 20:07:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.355 X-Spam-Level: X-Spam-Status: No, score=0.355 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_05=-1.11, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r2fpYZZ4UyaN for ; Mon, 10 Jun 2013 20:07:18 -0700 (PDT) Received: from nm2-vm1.bullet.mail.bf1.yahoo.com (nm2-vm1.bullet.mail.bf1.yahoo.com [98.139.213.158]) by ietfa.amsl.com (Postfix) with ESMTP id 30D9821F9949 for ; Mon, 10 Jun 2013 20:07:14 -0700 (PDT) Received: from [98.139.212.145] by nm2.bullet.mail.bf1.yahoo.com with NNFMP; 11 Jun 2013 03:07:14 -0000 Received: from [98.139.213.3] by tm2.bullet.mail.bf1.yahoo.com with NNFMP; 11 Jun 2013 03:07:14 -0000 Received: from [127.0.0.1] by smtp103.mail.bf1.yahoo.com with NNFMP; 11 Jun 2013 03:07:14 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1370920034; bh=gUU79MZ15WNcH+xyMryK6GYUfAPiPHicIwDQWQ1AZvQ=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:References:In-Reply-To:Mime-Version:Content-Transfer-Encoding:Content-Type:Message-Id:Cc:X-Mailer:From:Subject:Date:To; b=TUw0YVdJd3TFPufKU/3xE3Sl875ks/r+q/MqpLSPVHEfD/wQzXmtKUxFELIlkDlobVOeO/TJsZs9Rc2gG9PlNumBejJ6S2iy0xGr0lLOo8LRJRDhb+pntc/rUfiz9IfnfhGrH8QQho8FBPntUujJla0RTG36Epn2qQVNJgfvqLk= X-Yahoo-Newman-Id: 348806.8453.bm@smtp103.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: LZFdz_cVM1kmQb_cssKo14vy2ZpJFX0gJ1PzUf559GlhE2q NM3jBn8ErJQE4H0yLy1qnT9hNDGaARv1567yoaAcS1_78t45EqrbI48GH.Df x32s3utsU7pFkKdTo83O2uOUnno7LwGAUBn1r8u2e8zwo04HdNlJago1eQwT SNni1.mb8D6v6flNwN5O9PaDlsMhBVfXSN_hzQZhViHTmSUMQdCLnf5yIDBI v13gl4E3hXBpp2Z_UWZOfXk1R3cmrcrCKWlffyum0hh4ElQkLIVyO7kErxYX QM9eUqu_OXe6rz.PbuJdjI.zg1rkNgPeT0FkgyhaWxrBAe_TfJHU88jQC1wp hSAMHGH369KIr3Zo5YWs8VeTXwy7aS62FiK8jkHW8CSJ_NlCvHy_WjBVm60o vfeTZS.q2l4ZCc6klYLucDlz6ix86DIvkLTRdNPytfvBG5aBA9XgIKUWTaBr jP5_kEU_TgJ5YERjBUzO9pjxwxk4zB_ZRO69t9DYmOQZmlDxnoS1d4K6wm6V ygOSC7h22tfEkLR4HJymiznEt X-Yahoo-SMTP: indQcmSswBC8IKsm6t4aCAPskK3T X-Rocket-Received: from [192.168.0.102] (jsontest@76.29.100.42 with ) by smtp103.mail.bf1.yahoo.com with SMTP; 10 Jun 2013 20:07:14 -0700 PDT References: <06c101ce6625$0f891bf0$2e9b53d0$@augustcellars.com> <379266A1-82C1-4FF5-BD7C-EE657F1FD41F@vpnc.org> <06e901ce6638$e8f27a90$bad76fb0$@augustcellars.com> <51DE7E41-D682-4340-A234-7F7CFE513C10@vpnc.org> <070b01ce664b$e5e0ac10$b1a20430$@augustcellars.com> In-Reply-To: <070b01ce664b$e5e0ac10$b1a20430$@augustcellars.com> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPod Mail (9B206) From: Vinny A Date: Mon, 10 Jun 2013 22:07:11 -0500 To: Jim Schaad Cc: Paul Hoffman , "json@ietf.org" Subject: Re: [Json] Leading and trailing whitespace X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 11 Jun 2013 03:07:23 -0000 On Jun 10, 2013, at 9:32 PM, "Jim Schaad" wrote: > Yes -but what I am saying is that there are (probably) parsers which stop > before the string has been fully consumed. Thus they would accept the > string as valid. There may be parsers that stop parsing at the end }, but (IMO) that sounds l= ike a lazy parser. I just tested the Golang encoding/JSON default package an= d it rejects your JSON as invalid. It sounds to me that you're trying to make the larger point of "what text, i= f any, is valid outside of the JSON braces." Whitespace - to me - is syntact= ic sugar. Even leading and trailing whitespace is helpful: it provides space= for future comments, for example. ----------------- Vinny www.jsontest.com= From nico@cryptonector.com Mon Jun 10 20:42:29 2013 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 A2C9111E80D5 for ; Mon, 10 Jun 2013 20:42:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vuvmc4n+0DNR for ; Mon, 10 Jun 2013 20:42:24 -0700 (PDT) Received: from homiemail-a29.g.dreamhost.com (caiajhbdcbbj.dreamhost.com [208.97.132.119]) by ietfa.amsl.com (Postfix) with ESMTP id A8A2E11E80CC for ; Mon, 10 Jun 2013 20:42:24 -0700 (PDT) Received: from homiemail-a29.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a29.g.dreamhost.com (Postfix) with ESMTP id 9D110674059 for ; Mon, 10 Jun 2013 20:42:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=8fhHvgavCvFz7jw4g9Xw z50A+J4=; b=gRB6j8ufnHvhLpuWMovgMOYLJaXmG2JnKug0gsrNJHMyS//LfYSg DqbIqwqmmsTku4y6Cs0LXiGvR/P+t7R/8o7hX/j9d0APCXiskyrJE/gRVS5+G8rp mDjAeBe0BwVnmTjUvhu4rCJi5g4bSMs8DqZ+jF20GPWLk5p1LsHKiSk= Received: from mail-wi0-f181.google.com (mail-wi0-f181.google.com [209.85.212.181]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a29.g.dreamhost.com (Postfix) with ESMTPSA id 4E733674057 for ; Mon, 10 Jun 2013 20:42:23 -0700 (PDT) Received: by mail-wi0-f181.google.com with SMTP id hq4so1483730wib.14 for ; Mon, 10 Jun 2013 20:42:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=51uoy5VQ6omAc4HKsTb5xYXPoTBqPVFEYvkwmowXUkI=; b=fNAk8olijZhDFaExFnt4QTK/B58jeMPYSte3rcFDbGe+iVuEStPdYQD8iLbPtfxy9s UGzbD1VSPqg0Ik35TqKcO9AB+4tQuWhV1VkbsZCDAkPXL1zAGEOiNYPjkImXscs8JHxp nxDfYZUyud2KfbfAqjaiUx2dmd2unP3CzH5p1BSuFtQhgLig360RZSfOh4oD9GiT6Dqx nG4LXAYbYYkiTKOZ4PKxG581U+MwFaw6nOO2ELUuDeNP/olw6q3Nu6W5Ef6QdTmV2Sgu Z/DKlKuCRtpt+VKKNEy/FxhY0vqILSOkRCi08tD18SEEv0KvM+KYBFByTPdJkFGKDswX vvUw== MIME-Version: 1.0 X-Received: by 10.194.8.163 with SMTP id s3mr7231744wja.41.1370922142008; Mon, 10 Jun 2013 20:42:22 -0700 (PDT) Received: by 10.216.63.136 with HTTP; Mon, 10 Jun 2013 20:42:21 -0700 (PDT) In-Reply-To: <6E03D281-D6BA-424D-A30A-3DA18E61A051@vpnc.org> References: <06c101ce6625$0f891bf0$2e9b53d0$@augustcellars.com> <379266A1-82C1-4FF5-BD7C-EE657F1FD41F@vpnc.org> <06e901ce6638$e8f27a90$bad76fb0$@augustcellars.com> <51DE7E41-D682-4340-A234-7F7CFE513C10@vpnc.org> <070b01ce664b$e5e0ac10$b1a20430$@augustcellars.com> <6E03D281-D6BA-424D-A30A-3DA18E61A051@vpnc.org> Date: Mon, 10 Jun 2013 22:42:21 -0500 Message-ID: From: Nico Williams To: Paul Hoffman Content-Type: text/plain; charset=UTF-8 Cc: Jim Schaad , json@ietf.org Subject: Re: [Json] Leading and trailing whitespace X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 11 Jun 2013 03:42:29 -0000 On Mon, Jun 10, 2013 at 9:53 PM, Paul Hoffman wrote: > On Jun 10, 2013, at 7:32 PM, "Jim Schaad" wrote: > > You might be asking "if we allow other JSON items at the top level, will we also allow optional whitespace before and after". But that's a supposition, not a question about what is in the document now. Sure, but since we're full-out having the any value type at the top-level discussion (and it looks like we'll at least have to have informational text acknowledging that ECMAScript will allow them) this becomes relevant. Do implementations that allow any value type at the top-level allow leading and/or trailing whitespace? *Should* they? IMO the intuitive answer to the last should be "yes", that arbitrary amounts of whitespace can surround any value regardless of where it appears. But my intuition could be wrong. > You have changed the subject of the question, then. You were asking about the top level, without a container. I claim my answer is correct for the question you asked. Well, that's what happens when people have discussions... :) > None of the objects other than arrays and objects have optional whitespace. None. Indeed. But that might need to change with the top-level value type discussion. Or if not "need", we might want it to anyways. >> Yes -but what I am saying is that there are (probably) parsers which stop >> before the string has been fully consumed. Thus they would accept the >> string as valid. > > There are (probably) parsers that do all sorts of stupid, non-conformant things. Why is that relevant here? Actually, that seems very relevant for the Security Considerations section. What should parsers do with any content left over after parsing the end of a top-level value? Trailing whitespace would allow parsers to delimit top-level numeric values when end-of-message might be hard to distinguish from a TCP RST. Trailing content might allow smuggling of data past a JSON parser, where it could do damage (e.g., get past deep packet inspectors). Perhaps the simplest thing to do would be to allow just one space to trail top-level values. Nico -- From James.H.Manger@team.telstra.com Mon Jun 10 21:19:37 2013 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 75A8921F9921 for ; Mon, 10 Jun 2013 21:19:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.633 X-Spam-Level: X-Spam-Status: No, score=-0.633 tagged_above=-999 required=5 tests=[AWL=0.268, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 50JoeDRBEuMo for ; Mon, 10 Jun 2013 21:19:31 -0700 (PDT) Received: from ipxcvo.tcif.telstra.com.au (ipxcvo.tcif.telstra.com.au [203.35.135.208]) by ietfa.amsl.com (Postfix) with ESMTP id 8B6F921F9700 for ; Mon, 10 Jun 2013 21:19:26 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.87,842,1363093200"; d="scan'208";a="140733448" Received: from unknown (HELO ipcdvi.tcif.telstra.com.au) ([10.97.217.212]) by ipocvi.tcif.telstra.com.au with ESMTP; 11 Jun 2013 14:19:25 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,7102"; a="137315258" Received: from wsmsg3705.srv.dir.telstra.com ([172.49.40.203]) by ipcdvi.tcif.telstra.com.au with ESMTP; 11 Jun 2013 14:19:25 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3705.srv.dir.telstra.com ([172.49.40.203]) with mapi; Tue, 11 Jun 2013 14:19:24 +1000 From: "Manger, James H" To: R S , "json@ietf.org" Date: Tue, 11 Jun 2013 14:19:23 +1000 Thread-Topic: [Json] Allow any JSON value at the top level Thread-Index: Ac5mULKLQ1pHZ2x2QMGWG9pFN4Uw4wAACxzg Message-ID: <255B9BB34FB7D647A506DC292726F6E1151B430DAD@WSMSG3153V.srv.dir.telstra.com> References: <51b23e6d.6196420a.0b15.4245SMTPIN_ADDED_BROKEN@mx.google.com> <51b4dbbe.64da440a.1fc2.6dd2SMTPIN_ADDED_BROKEN@mx.google.com> <51b4ec44.ea05420a.7c73.ffffa487SMTPIN_ADDED_BROKEN@mx.google.com> <51b507b1.c686e00a.3a7e.ffffa0adSMTPIN_ADDED_BROKEN@mx.google.com> <20130610201746.GC1057@mercury.ccil.org> <3CE20E15-8F9E-4727-BBE7-FBB06F7CAC24@jorgechamorro.com> In-Reply-To: Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [Json] Allow any JSON value at the top level X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 11 Jun 2013 04:19:37 -0000 PiBBIG5ldyBtZWRpYSB0eXBlIHdvdWxkIHNvbHZlIGFueSBwcm9ibGVtIHRoYXQgSSdtIGF3YXJl IG9mLg0KDQpBIG5ldyBtZWRpYSB0eXBlIGZvciBhbnkgSlNPTiB2YWx1ZSAobm90IGp1c3Qgb2Jq ZWN0IG9yIGFycmF5KSBjb3VsZCB3b3JrIGluIHRoZW9yeSwgYnV0IEkgZG91YnQgaXQgY2FuIHdv cmsgaW4gcHJhY3RpY2UuDQoNCkl0IHdvdWxkIHNpZ25pZmljYW50bHkgY29tcGxpY2F0ZSBjb252 ZXJzYXRpb25zIGFib3V0IEpTT04uIE1lbnRpb25zIG9mIEpTT04gaW4gQVBJcywgcHJvdG9jb2xz LCBzcGVjcyBldGMgd291bGQgaGF2ZSB0byBxdWFsaWZ5IHdoZXRoZXIgb3Igbm90IHRoZXkgc3Vw cG9ydCBib3RoLCBvciBqdXN0IG9uZSwgb2YgdGhlIG1lZGlhIHR5cGVzLiBUd28gbWVkaWEgdHlw ZXMgcHJvYmFibHkgbmVlZCB0byBiZSBhZHZlcnRpc2VkIGluIEhUVFAgQWNjZXB0IGhlYWRlcnMu IFRoZXJlIHdvdWxkIGJlIHR3byBjaG9pY2VzIGZvciBtZWRpYSB0eXBlIHdoZW4gc2VuZGluZyBh IEpTT04gb2JqZWN0IG9yIGFycmF5LCB3aGljaCB3b3VsZCBwcm9kdWNlIGRpZmZlcmVudCBiZWhh dmlvdXIgaW4gc29tZSBjYXNlcyAoZWcgIm9sZCIgc3lzdGVtcyB0aGF0IGRvbid0IGtub3cgYWJv dXQgdGhlIG5ldyB0eXBlKS4NCg0KV291bGQgbWVkaWEgdHlwZXMgd2l0aCBhICtqc29uIHN1ZmZp eCBhbGxvdyBhbnkgSlNPTiB2YWx1ZXM/IE9yIHdvdWxkIHdlIG5lZWQgYSBzZWNvbmQgc3VmZml4 IGFzIHdlbGw/DQoNCkl0IHdvdWxkIGJlIGJldHRlciB0byBhbGxvdyBhbnkgSlNPTiB2YWx1ZSB3 aXRoIHRoZSBleGlzdGluZyBtZWRpYSB0eXBlIGFuZCBzdWZmaXguDQoNCg0KQSB0b3AtbGV2ZWwg SlNPTiB2YWx1ZSB3b3VsZCBubyBsb25nZXIgbmVjZXNzYXJpbHkgYmUgc2VsZi1kZWxpbWl0aW5n LiBJIGRvdWJ0IHRoaXMgaXMgdGhhdCBjcnVjaWFsLiBNYW55IG1lZGlhIHR5cGVzIGFyZSBub3Qg c2VsZi1kZWxpbWl0aW5nLiBFdmVuIEpTT04gb2JqZWN0cyBhbmQgYXJyYXlzIGFyZSBub3Qgc3Ry aWN0bHkgc2VsZi1kZWxpbWl0aW5nIGFzIHRoZXkgYWxsb3cgbGVhZGluZyBhbmQgdHJhaWxpbmcg d2hpdGVzcGFjZS4gQXBwZW5kaW5nIHdoaXRlc3BhY2UgdG8gYSBKU09OIHZhbHVlIHdvdWxkIG1h a2UgYXMgc2VsZi1kZWxpbWl0aW5nIGFnYWluIOKAkyByZXN0b3JpbmcgdGhpcyBwcm9wZXJ0eSB3 aGVyZSBuZWVkZWQgKGFsbG93aW5nIHdoaXRlc3BhY2UgYXJvdW5kIG5vbi1vYmplY3Qtbm9uLWFy cmF5IHRvcC1sZXZlbCB2YWx1ZXMgd291bGQgYmUgYSBzZW5zaWJsZSBwYXJ0IG9mIHRoZSBjaGFu Z2UpLg0KDQotLQ0KSmFtZXMgTWFuZ2VyDQo= From sayrer@gmail.com Mon Jun 10 21:20:31 2013 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 7620421E80B5 for ; Mon, 10 Jun 2013 21:20:31 -0700 (PDT) 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=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UBX9y578DmZN for ; Mon, 10 Jun 2013 21:20:30 -0700 (PDT) Received: from mail-we0-x22b.google.com (mail-we0-x22b.google.com [IPv6:2a00:1450:400c:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id EC36821E80B3 for ; Mon, 10 Jun 2013 21:20:29 -0700 (PDT) Received: by mail-we0-f171.google.com with SMTP id m46so5458665wev.16 for ; Mon, 10 Jun 2013 21:20:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=mt23oX7vMQvCN5fNKYTKbLIlOb61a8H+PnXGmhyC12E=; b=yG6nIcI/+RTusZtRLB/9TboXVpltsBtwP9eI0GzsvyCWWX/xNlmRwKwuqTyMT+u4QB cR49L407xEWDcMpM/7eqTr0NPjPkvA9qzxtbX3YkS+EcJPjBHkleGfOWjBbnXRpQhikY ZUB8wRSPqpVRzoSIyMVpGj7aSRcelHh4o4I52JTYt/Ov7uSWysgibPcux6zJcG4/eSMD d2jZ5nBQNfpOAz+EwspNKexw8TZmstpl6tB6gzpQR7JMlUmbNzRvrpQ8ZJadDXmeFG17 8BXjjM74aeh3ECnG54enwHy0BV5r7GsGHXvZjkzxzbv5hsWXMLbkfz/7bzgrM8CQSqqH DvVg== MIME-Version: 1.0 X-Received: by 10.194.86.106 with SMTP id o10mr7058466wjz.93.1370924429134; Mon, 10 Jun 2013 21:20:29 -0700 (PDT) Received: by 10.194.83.35 with HTTP; Mon, 10 Jun 2013 21:20:28 -0700 (PDT) In-Reply-To: <255B9BB34FB7D647A506DC292726F6E1151B430DAD@WSMSG3153V.srv.dir.telstra.com> References: <51b23e6d.6196420a.0b15.4245SMTPIN_ADDED_BROKEN@mx.google.com> <51b4dbbe.64da440a.1fc2.6dd2SMTPIN_ADDED_BROKEN@mx.google.com> <51b4ec44.ea05420a.7c73.ffffa487SMTPIN_ADDED_BROKEN@mx.google.com> <51b507b1.c686e00a.3a7e.ffffa0adSMTPIN_ADDED_BROKEN@mx.google.com> <20130610201746.GC1057@mercury.ccil.org> <3CE20E15-8F9E-4727-BBE7-FBB06F7CAC24@jorgechamorro.com> <255B9BB34FB7D647A506DC292726F6E1151B430DAD@WSMSG3153V.srv.dir.telstra.com> Date: Mon, 10 Jun 2013 21:20:28 -0700 Message-ID: From: R S To: "Manger, James H" Content-Type: multipart/alternative; boundary=089e0102e0dc9cd1bd04ded9374f Cc: "json@ietf.org" Subject: Re: [Json] Allow any JSON value at the top level X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 11 Jun 2013 04:20:31 -0000 --089e0102e0dc9cd1bd04ded9374f Content-Type: text/plain; charset=ISO-8859-1 On Mon, Jun 10, 2013 at 9:19 PM, Manger, James H < James.H.Manger@team.telstra.com> wrote: > > A new media type would solve any problem that I'm aware of. > > A new media type for any JSON value (not just object or array) could work > in theory, but I doubt it can work in practice. Oh, yikes, I meant "would /not/ solve any problem that I'm aware of." - Rob --089e0102e0dc9cd1bd04ded9374f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Mon, Jun 10, 2013 at 9:19 PM, Manger, James H <James.H.Manger@team.telstra.com> wrote:
> A new me= dia type would solve any problem that I'm aware of.

A new media type for any JSON value (not just object or array) could = work in theory, but I doubt it can work in practice.

<= /div>
Oh, yikes, I meant "would /not/ solve=A0any problem that I'm aware of."

<= span style=3D"color:rgb(80,0,80)">- Rob
--089e0102e0dc9cd1bd04ded9374f-- From sayrer@gmail.com Mon Jun 10 21:27:44 2013 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 5E13D21F998B for ; Mon, 10 Jun 2013 21:27:44 -0700 (PDT) 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=[AWL=0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f9EA6PFXMgaf for ; Mon, 10 Jun 2013 21:27:43 -0700 (PDT) Received: from mail-we0-x234.google.com (mail-we0-x234.google.com [IPv6:2a00:1450:400c:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id 42C5B21F9974 for ; Mon, 10 Jun 2013 21:27:42 -0700 (PDT) Received: by mail-we0-f180.google.com with SMTP id w56so5528425wes.11 for ; Mon, 10 Jun 2013 21:27:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=GRb4vzVgLuEFnKn4LPllTOiM6Xes5s8lD1uhWJ94SRI=; b=Y7QXjUTJlEHDX8AAgiUEPHpIH53KPZU+qKltnTAImfZ3N3PM8BlUIG+gJHcINJ99YT /8h/5KbP09zwYwYkP50J9rNv/PWLORJdRJtguiAV5YP7oAJNcZqNxztBHuQ4MvT682q4 bx/DgXmNaJNt5NxN9LRm9BOxH/ixfPPVECd4Qx1HGyxA+fF7h7+XGXMRRhzSSnUUWW7P dQyW094Q+Oudylf5bftMiePPj/Yu8d4g6f9EYCIVpRMaTxaHmL8AEhSBHxQm2dxd8rrB 4WzM9lQvYONH+CzAWhuEcEEZ8HoQjXwxkGN08BtaTJ/qX7ehPu/Z4t30Odh1hSJGrxIe 8d8w== MIME-Version: 1.0 X-Received: by 10.180.185.84 with SMTP id fa20mr46131wic.49.1370924862353; Mon, 10 Jun 2013 21:27:42 -0700 (PDT) Received: by 10.194.83.35 with HTTP; Mon, 10 Jun 2013 21:27:42 -0700 (PDT) In-Reply-To: References: <51b23e6d.6196420a.0b15.4245SMTPIN_ADDED_BROKEN@mx.google.com> <51b4dbbe.64da440a.1fc2.6dd2SMTPIN_ADDED_BROKEN@mx.google.com> <51b4ec44.ea05420a.7c73.ffffa487SMTPIN_ADDED_BROKEN@mx.google.com> <51b507b1.c686e00a.3a7e.ffffa0adSMTPIN_ADDED_BROKEN@mx.google.com> <20130610201746.GC1057@mercury.ccil.org> <3CE20E15-8F9E-4727-BBE7-FBB06F7CAC24@jorgechamorro.com> Date: Mon, 10 Jun 2013 21:27:42 -0700 Message-ID: From: R S To: Paul Hoffman Content-Type: multipart/alternative; boundary=001a11c2404c6f372804ded9516b Cc: "" Subject: Re: [Json] Allow any JSON value at the top level X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 11 Jun 2013 04:27:44 -0000 --001a11c2404c6f372804ded9516b Content-Type: text/plain; charset=ISO-8859-1 On Mon, Jun 10, 2013 at 7:57 PM, Paul Hoffman wrote: > > ...I certainly hope the WG find that defining "browser" and "most" and > "popular" is out of scope. That is not a very charitable interpretation of what I wrote. For my part, I certainly hope the WG doesn't stick its head in the sand and say "only objects and arrays are JSON, because we say so". > > Many endpoints only accept specific root elements. For example, > json-patch only accepts arrays. In other words, no one will notice if your > JSON parser only accepts objects and arrays. > > > > What is the benefit of preserving RFC 4627 requirements? I don't > understand the rationale accompanying your opinion. The charter mandates > that the WG document top-level primitive parsing, no matter what. > > Fully agree on the last part. But "document" does not mean "change the > requirements". We can say "the requirement is X" and "X differs from 4627 > and/or ECMAScript", at least in my reading of the charter. I agree with that. But ECMAScript is the better JSON parsing document, and RFC 4627 is a now-obsolete Informational RFC. - Rob --001a11c2404c6f372804ded9516b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Mon, Jun 10, 2013 at 7:57 PM, Paul Hoffman <paul.h= offman@vpnc.org> wrote:

...I certainly hope the WG find that defining "browser" and= "most" and "popular" is out of scope.

That is not a very charitable interpretation of what = I wrote. For my part, I certainly hope the WG doesn't stick its head in= the sand and say "only objects and arrays are JSON, because we say so= ".

=A0
> Many endpoints only accept specific root elements. For example, json-p= atch only accepts arrays. In other words, no one will notice if your JSON p= arser only accepts objects and arrays.
>
> What is the benefit of preserving RFC 4627 requirements? I don't u= nderstand the rationale accompanying your opinion. The charter mandates tha= t the WG document top-level primitive parsing, no matter what.

Fully agree on the last part. But "document" does not mean = "change the requirements". We can say "the requirement is X&= quot; and "X differs from 4627 and/or ECMAScript", at least in my= reading of the charter.

I agree with that. But ECMAScript is the better J= SON parsing document, and RFC 4627 is a now-obsolete Informational RFC.

- Rob

=A0
--001a11c2404c6f372804ded9516b-- From cabo@tzi.org Mon Jun 10 22:15:25 2013 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 EFEE721F9AC5 for ; Mon, 10 Jun 2013 22:15:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.131 X-Spam-Level: X-Spam-Status: No, score=-106.131 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gOl012okI2Uo for ; Mon, 10 Jun 2013 22:15:02 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 5724C21F9AC4 for ; Mon, 10 Jun 2013 22:15:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r5B5EQXu015692; Tue, 11 Jun 2013 07:14:27 +0200 (CEST) Received: from [192.168.217.105] (p54893004.dip0.t-ipconnect.de [84.137.48.4]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 841323053; Tue, 11 Jun 2013 07:14:26 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: Date: Tue, 11 Jun 2013 07:14:25 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <06c101ce6625$0f891bf0$2e9b53d0$@augustcellars.com> <379266A1-82C1-4FF5-BD7C-EE657F1FD41F@vpnc.org> <06e901ce6638$e8f27a90$bad76fb0$@augustcellars.com> <51DE7E41-D682-4340-A234-7F7CFE513C10@vpnc.org> <070b01ce664b$e5e0ac10$b1a20430$@augustcellars.com> <6E03D281-D6BA-424D-A30A-3DA18E61A051@vpnc.org> To: Nico Williams X-Mailer: Apple Mail (2.1508) Cc: Jim Schaad , Paul Hoffman , json@ietf.org Subject: Re: [Json] Leading and trailing whitespace X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 11 Jun 2013 05:15:25 -0000 On Jun 11, 2013, at 05:42, Nico Williams wrote: > Do implementations that allow any value type at the top-level allow > leading and/or trailing whitespace? Yes. E.g., >> JSON.parse("\r\n \t 27 \r\n \t", quirks_mode: true) =3D> 27 (quirks_mode is the flag that switches on the non-coforming acceptance = of any "value".) > *Should* they? Yes. (If you are not convinced from first principles: people have argued you = can do streaming by adding whitespace, and that required being allowed = to add whitespace :-) So we will have to add a production: JSON-value =3D ws value ws That didn't seem too hard. Thanks for pointing this out, Jim. This production can be in 4627-bis or in the document that defines the = application/json-value media type, if we want to go the latter route. Gr=FC=DFe, Carsten PS.: Just to show that trailing whitespace is indeed properly parsed: >> JSON.parse("\r\n \t 27 \r\n \t 28", quirks_mode: true) JSON::ParserError: 795: unexpected token at '28' From nico@cryptonector.com Mon Jun 10 23:08:51 2013 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 9797521F880F for ; Mon, 10 Jun 2013 23:08:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.963 X-Spam-Level: X-Spam-Status: No, score=-1.963 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EaRfwWol81DC for ; Mon, 10 Jun 2013 23:08:46 -0700 (PDT) Received: from homiemail-a55.g.dreamhost.com (caiajhbdcagg.dreamhost.com [208.97.132.66]) by ietfa.amsl.com (Postfix) with ESMTP id 9655021F8628 for ; Mon, 10 Jun 2013 23:08:46 -0700 (PDT) Received: from homiemail-a55.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a55.g.dreamhost.com (Postfix) with ESMTP id D8CCA400FDB1F for ; Mon, 10 Jun 2013 23:08:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=EUazIsrR3+CcDreUTztDGvp4fhs=; b=t5z52gUC7Bu bkPfqF/S4Hv1ffdejYOkOOTeYoVU+WbeFZ5UXnR/cMpOdoFbHwxdYdPl8pCdA/4z HsIjXVSPZiY0dV8XWWJgf4F98F1QYWrUWtkIcsY8RNaEtweqwPZUYYnqqtLIkuge V53xEQQdWS7FnWKUMyoSyjfngDp74hHg= Received: from mail-wg0-f45.google.com (mail-wg0-f45.google.com [74.125.82.45]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a55.g.dreamhost.com (Postfix) with ESMTPSA id 8931F400FDB1E for ; Mon, 10 Jun 2013 23:08:45 -0700 (PDT) Received: by mail-wg0-f45.google.com with SMTP id j13so201789wgh.12 for ; Mon, 10 Jun 2013 23:08:43 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=mXublk2A/G8kl0WEpeN7auUP/4rHVYcFFqLFEsN+964=; b=aw/u5QALaqDd6SeTkLv9IjKrxn3U4pDwiZgSYEYPMFsG4i5le7n8anJ0sMNWHSGog6 2y+4YEXciuR4i1SwL1vk9Kp/esV5YPDIyUFHQTtJwApvlTqD6+Ev9rOqgh0dABL+tybE tVQ7RvIkdffPnRfsCpRU5HoMwRC7KJ/ByK7KPHkf3RyI8mX19n6uV5PxdeTqyU5ZbrBp wm6cMplPnjatDc7WLISAqoHovj5sHzsLEPxEJJPk+Xl0vfB6fOrhHNUlrOojcEnoUnM2 qT7zz/irjBDKPigTm/d40CBYuma5SpZADBKAxFrUlzNqLPAImHgjl73AQ56+mOdNJtWb pZxw== MIME-Version: 1.0 X-Received: by 10.180.90.164 with SMTP id bx4mr256132wib.13.1370930923949; Mon, 10 Jun 2013 23:08:43 -0700 (PDT) Received: by 10.216.63.136 with HTTP; Mon, 10 Jun 2013 23:08:43 -0700 (PDT) In-Reply-To: References: <06c101ce6625$0f891bf0$2e9b53d0$@augustcellars.com> <379266A1-82C1-4FF5-BD7C-EE657F1FD41F@vpnc.org> <06e901ce6638$e8f27a90$bad76fb0$@augustcellars.com> <51DE7E41-D682-4340-A234-7F7CFE513C10@vpnc.org> <070b01ce664b$e5e0ac10$b1a20430$@augustcellars.com> <6E03D281-D6BA-424D-A30A-3DA18E61A051@vpnc.org> Date: Tue, 11 Jun 2013 01:08:43 -0500 Message-ID: From: Nico Williams To: Carsten Bormann Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Jim Schaad , Paul Hoffman , json@ietf.org Subject: Re: [Json] Leading and trailing whitespace X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 11 Jun 2013 06:08:51 -0000 On Tue, Jun 11, 2013 at 12:14 AM, Carsten Bormann wrote: > On Jun 11, 2013, at 05:42, Nico Williams wrote: >> Do implementations that allow any value type at the top-level allow >> leading and/or trailing whitespace? > > Yes. E.g., > >>> JSON.parse("\r\n \t 27 \r\n \t", quirks_mode: true) > =3D> 27 > > (quirks_mode is the flag that switches on the non-coforming acceptance of= any "value".) Right. I suppose I meant "by default" :) >> *Should* they? > > Yes. > > (If you are not convinced from first principles: people have argued you c= an do streaming by adding whitespace, and that required being allowed to ad= d whitespace :-) Indeed, I've argued as much. The whitespace is only needed to distinguish end-of-message from a pemature EOF that might not otherwise be understood as such. > So we will have to add a production: > > JSON-value =3D ws value ws > > That didn't seem too hard. Do we need to remove whitespace elsewhere in the ABNF? Or is redundancy there OK? > Thanks for pointing this out, Jim. Yes, thanks! > This production can be in 4627-bis or in the document that defines the ap= plication/json-value media type, if we want to go the latter route. Sure. For now I'm still arguing for allowing any value type at the top-lev= el. > Gr=C3=BC=C3=9Fe, Carsten > > PS.: Just to show that trailing whitespace is indeed properly parsed: >>> JSON.parse("\r\n \t 27 \r\n \t 28", quirks_mode: true) > JSON::ParserError: 795: unexpected token at '28' Ah, good job. Nico -- From markus.lanthaler@gmx.net Tue Jun 11 01:09:49 2013 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 037C621F9A91 for ; Tue, 11 Jun 2013 01:09:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.15 X-Spam-Level: X-Spam-Status: No, score=-1.15 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yjc0ItQTYP8w for ; Tue, 11 Jun 2013 01:09:35 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) by ietfa.amsl.com (Postfix) with ESMTP id 2C34F21F96FE for ; Tue, 11 Jun 2013 01:09:35 -0700 (PDT) Received: from mailout-de.gmx.net ([10.1.76.19]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0MEphU-1UalyZ3W7W-00FyE7 for ; Tue, 11 Jun 2013 10:09:33 +0200 Received: (qmail invoked by alias); 11 Jun 2013 08:09:33 -0000 Received: from 84-115-182-43.dynamic.surfer.at (EHLO Vostro3500) [84.115.182.43] by mail.gmx.net (mp019) with SMTP; 11 Jun 2013 10:09:33 +0200 X-Authenticated: #419883 X-Provags-ID: V01U2FsdGVkX18WY2l9APYWQ2lOCrbCaoCncjorFs302NBmdYz5Vo rsEz+ciKq2oO06 From: "Markus Lanthaler" To: References: <51b23e6d.6196420a.0b15.4245SMTPIN_ADDED_BROKEN@mx.google.com> <51b4dbbe.64da440a.1fc2.6dd2SMTPIN_ADDED_BROKEN@mx.google.com> <51b4ec44.ea05420a.7c73.ffffa487SMTPIN_ADDED_BROKEN@mx.google.com> <51b507b1.c686e00a.3a7e.ffffa0adSMTPIN_ADDED_BROKEN@mx.google.com> In-Reply-To: Date: Tue, 11 Jun 2013 10:09:31 +0200 Message-ID: <015001ce667b$00c45340$024cf9c0$@lanthaler@gmx.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac5mEWLljQoDo5lvRKy50hj9aPPZRgAaRt1w Content-Language: de X-Y-GMX-Trusted: 0 Subject: Re: [Json] Allow any JSON value at the top level X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 11 Jun 2013 08:09:49 -0000 On Sent: Monday, June 10, 2013 9:33 PM, Jacob Davies wrote: > Lots of people do this, in my experience, including me pretty often. I was hoping for something more concrete. Something like "Facebook's, Google's and Bing's APIs are doing that. Here are the links." > The big problem with the current requirement is that arbitrary > sub-values of a JSON value cannot be sent as application/json. Of course not. How would you path a JSON object or array by just sending a number? How should that number be interpreted? > So for > instance, if you wish to implement a form of PATCH on a JSON document, > you must demand that clients wrap their new value in a JSON object or > array instead of sending raw primitive values. Are you really talking about PATCH? Looks more like a PUT to me.. PATCH requires a different media type anyway. > If you implement a > service returning an inherently primitive value (e.g. a plain-text > document server) you must wrap your responses in a JSON object or > array even though there is nothing else that could reasonably be > added. ... or you just return text/plain. That would even enable browsers to render the responses. Cheers, Markus -- Markus Lanthaler @markuslanthaler From cabo@tzi.org Tue Jun 11 01:56:42 2013 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 331F821F9A8D for ; Tue, 11 Jun 2013 01:56:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y9QmXwsSAmg3 for ; Tue, 11 Jun 2013 01:56:36 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 075F621F9A8C for ; Tue, 11 Jun 2013 01:56:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r5B8uQLx008685; Tue, 11 Jun 2013 10:56:26 +0200 (CEST) Received: from [10.0.1.4] (reingewinn.informatik.uni-bremen.de [134.102.218.123]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 03E223214; Tue, 11 Jun 2013 10:56:26 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: Date: Tue, 11 Jun 2013 10:56:25 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <1094A510-3690-483F-8E1F-325D9FEE295B@tzi.org> References: <06c101ce6625$0f891bf0$2e9b53d0$@augustcellars.com> <379266A1-82C1-4FF5-BD7C-EE657F1FD41F@vpnc.org> <06e901ce6638$e8f27a90$bad76fb0$@augustcellars.com> <51DE7E41-D682-4340-A234-7F7CFE513C10@vpnc.org> <070b01ce664b$e5e0ac10$b1a20430$@augustcellars.com> <6E03D281-D6BA-424D-A30A-3DA18E61A051@vpnc.org> To: Nico Williams X-Mailer: Apple Mail (2.1508) Cc: Jim Schaad , Paul Hoffman , json@ietf.org Subject: Re: [Json] Leading and trailing whitespace X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 11 Jun 2013 08:56:42 -0000 >>>> JSON.parse("\r\n \t 27 \r\n \t", quirks_mode: true) >> =3D> 27 >>=20 >> (quirks_mode is the flag that switches on the non-coforming = acceptance of any "value".) >=20 > Right. I suppose I meant "by default" :) Without quirks mode, the Ruby JSON parser only accepts JSON-texts (i.e., = maps and arrays),=20 so I couldn't have tested how whitespace is accepted around top-level = values. >> So we will have to add a production: >>=20 >> JSON-value =3D ws value ws >>=20 >> That didn't seem too hard. >=20 > Do we need to remove whitespace elsewhere in the ABNF? Or is > redundancy there OK? Redundant opportunities for whitespace in the ABNF are not a problem. Gr=FC=DFe, Carsten From cabo@tzi.org Tue Jun 11 02:25:56 2013 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 BB34121F960D for ; Tue, 11 Jun 2013 02:25:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fKsFIYybzSkV for ; Tue, 11 Jun 2013 02:25:40 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id A4E6D21F9619 for ; Tue, 11 Jun 2013 02:25:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r5B9PatC029676; Tue, 11 Jun 2013 11:25:36 +0200 (CEST) Received: from [10.0.1.4] (reingewinn.informatik.uni-bremen.de [134.102.218.123]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 96CA13260; Tue, 11 Jun 2013 11:25:36 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: Date: Tue, 11 Jun 2013 11:25:35 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <255B9BB34FB7D647A506DC292726F6E1151B21F9A9@WSMSG3153V.srv.dir.telstra.com> To: Tatu Saloranta X-Mailer: Apple Mail (2.1508) Cc: "Manger, James H" , "json@ietf.org" Subject: Re: [Json] Allow any JSON value at the top level X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 11 Jun 2013 09:25:56 -0000 On Jun 7, 2013, at 19:54, Tatu Saloranta wrote: >> Apart from the (intellectually nicely challenging, but practically = irrelevant) auto-detection thing, >=20 > Irrelevant based on what? I thought this is what any half-decent JSON = parser did; unless platform does not expose byte sequence as input, case = for some scripting languages. > I have written multiple parsers (json, xml) that do just this, and = know that others exist as well. It is true that there are parsers that implement autodetection. Lots of code is written that is then never exercised. > I don't know what leads to assumption of irrelevancy here, and it = should be fully spelled out. This is irrelevant in practice as JSON is used with UTF-8 in practice. The main job that the text in section 3 seems to do is to convince = people not to send a BOM in front of their UTF-8 JSON. Now that is a = good thing... Unfortunately, some JSON parsers have been "fixed" to = accept BOMs. Gr=FC=DFe, Carsten From sgbeal@googlemail.com Tue Jun 11 03:10:28 2013 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 BD1FF21F8F3E for ; Tue, 11 Jun 2013 03:10:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.625 X-Spam-Level: X-Spam-Status: No, score=-1.625 tagged_above=-999 required=5 tests=[AWL=0.352, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pIXMdEjMx4Xl for ; Tue, 11 Jun 2013 03:10:27 -0700 (PDT) Received: from mail-we0-x22b.google.com (mail-we0-x22b.google.com [IPv6:2a00:1450:400c:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 936EE21F8ECE for ; Tue, 11 Jun 2013 03:10:27 -0700 (PDT) Received: by mail-we0-f171.google.com with SMTP id m46so5658709wev.2 for ; Tue, 11 Jun 2013 03:10:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=nTQxSFYictDRZtawF6ytWEXyq7o3De8+PC9DAJXN+EM=; b=cwS+NhXEEZvJJYnIhWqLJkaH5dfwrcVaMvwvdt/S3ssIIKTgSk7qc080udniqeOa0T mKpqDSYHGkJRh8hCgFbgdbEXHb9AnmMBUchbQ8Dm7I4fe7NxP+446+sQQkHbZc8Oat6H Z4MEpo7KW8jGRyS0jUMq5CgvUnQ4K4Sx8CjMMj+3DUIMIKHcRx2YBvLH7LbX8aB0Podr 13hRs3tm4xEqpWysQRN4fwBpoWGsMY4l/8nseNWdlHkYs9GBcFjtA3rYDARtfJT+0ZXn Sgev2NWt6Kedee2NIpeTwAP4aN67t0TEdZC1Pm+mRtqRhrEJjaSAPkN8cN1dxRUuVRZf dLvQ== MIME-Version: 1.0 X-Received: by 10.180.206.180 with SMTP id lp20mr784585wic.41.1370945426752; Tue, 11 Jun 2013 03:10:26 -0700 (PDT) Received: by 10.194.42.230 with HTTP; Tue, 11 Jun 2013 03:10:26 -0700 (PDT) In-Reply-To: <070b01ce664b$e5e0ac10$b1a20430$@augustcellars.com> References: <06c101ce6625$0f891bf0$2e9b53d0$@augustcellars.com> <379266A1-82C1-4FF5-BD7C-EE657F1FD41F@vpnc.org> <06e901ce6638$e8f27a90$bad76fb0$@augustcellars.com> <51DE7E41-D682-4340-A234-7F7CFE513C10@vpnc.org> <070b01ce664b$e5e0ac10$b1a20430$@augustcellars.com> Date: Tue, 11 Jun 2013 12:10:26 +0200 Message-ID: From: Stephan Beal To: "json@ietf.org" Content-Type: multipart/alternative; boundary=001a11c380b02b0e6604dede1b00 Subject: Re: [Json] Leading and trailing whitespace X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 11 Jun 2013 10:10:28 -0000 --001a11c380b02b0e6604dede1b00 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Jun 11, 2013 at 4:32 AM, Jim Schaad wrote: > Yes -but what I am saying is that there are (probably) parsers which stop > before the string has been fully consumed. Thus they would accept the string as valid. > All of the parsers i've written or worked closely with stop processing at the top of the closing tag for the root element. It doesn't generically make sense to keep reading from a stream when you have received the virtual EOF byte (the closing tag). -- ----- stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal --001a11c380b02b0e6604dede1b00 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, Jun 11, 2013 at 4:32 AM, Jim Schaad <ietf@au= gustcellars.com> wrote:
Yes -but what I am saying is that there are (probably) parsers wh= ich stop
before the string has been fully consumed. =A0Thus they would accept the=A0=
string as valid.

All of the parsers i've written or worked closely with s= top processing at the top of the closing tag for the root element. It doesn= 't generically make sense to keep reading from a stream when you have r= eceived the virtual EOF byte (the closing tag).

--
----- stephan beal
http://wanderinghorse.net/home= /stephan/
--001a11c380b02b0e6604dede1b00-- From stedolan@stedolan.net Tue Jun 11 03:52:01 2013 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 81E4321F9622 for ; Tue, 11 Jun 2013 03:52:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.53 X-Spam-Level: X-Spam-Status: No, score=-0.53 tagged_above=-999 required=5 tests=[AWL=-0.104, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wiTo3h+XPrGL for ; Tue, 11 Jun 2013 03:51:56 -0700 (PDT) Received: from mail-la0-x22e.google.com (mail-la0-x22e.google.com [IPv6:2a00:1450:4010:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 2BA0021F90CD for ; Tue, 11 Jun 2013 03:51:55 -0700 (PDT) Received: by mail-la0-f46.google.com with SMTP id eg20so6626385lab.5 for ; Tue, 11 Jun 2013 03:51:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:x-originating-ip:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :x-gm-message-state; bh=YAFC+dt+oOkb7IqLH5wXowMU5OWq2NDObjWBIBqiQhs=; b=Ig3D+a8TxO8KTwEqKo5rAzPkbLexR2Zf+aPjEqJnDNtHremHnKL68LQ1k02JV93Bpe Gq60x+b17HoDuaWcFIHNnHWsuueq92q5UN0h6GCjohQZQlxMWtVisOX5AJ3O2X/jKC6c UHHNxyxR3Jy5ZhDpm3WMtlNMCZLXsZhjw+GzT50xiMrBKLRfS/GzgcUzEWfeMx96uGU8 7mfSqMRqkwFBVSeswGvNsVSBSVXGllQ4Fwf5zQS41hlKXx93yrjkE8XEiH1RQedf0uQr ZiozlC3vIoSsOKfRfsMsq03jMcD/h24zLhOKO5/gWKWFcAArcHlAhtFHzq6it6WOKmGJ Ld7A== MIME-Version: 1.0 X-Received: by 10.112.140.166 with SMTP id rh6mr8401806lbb.44.1370947914765; Tue, 11 Jun 2013 03:51:54 -0700 (PDT) Sender: stedolan@stedolan.net Received: by 10.114.176.231 with HTTP; Tue, 11 Jun 2013 03:51:54 -0700 (PDT) X-Originating-IP: [131.111.184.26] In-Reply-To: <20130610234101.73051.qmail@joyce.lan> References: <20130610234101.73051.qmail@joyce.lan> Date: Tue, 11 Jun 2013 11:51:54 +0100 X-Google-Sender-Auth: m9S9i1kxZ4YlZw7sU1ZthHRyMx4 Message-ID: From: Stephen Dolan To: John Levine Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQlF5YARa94Rk3PvNAhLAEifYKXBG6/l2H8vf4qO5jFc2mmH93UkTk2rCY8YQf8f4gnokkx8 Cc: "json@ietf.org" Subject: Re: [Json] The names within an object SHOULD be unique. X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 11 Jun 2013 10:52:01 -0000 On Tue, Jun 11, 2013 at 12:41 AM, John Levine wrote: >>I propose that it be invalid to consider that document >>indistinguishable from {a: true}. Parsers are free to accept or reject >>it, and if they accept it they are free to return either one or two >>"a" entries, but if they only return one it must be {a: false}. > > That would rule out streaming parsers, or at least require that a > parser have access to arbitrarily large storage to buffer up large > JSON objects, or store all of the names or hash them or otherwise add > signficant processing that existing streaming parsers don't do. Given > that their current behavior is presumably adequate for their current > applications, it seems unlikely that the programmers will add all that > extra code just because we say to. No, it wouldn't. Streaming parsers return both entries. Stephen From stedolan@stedolan.net Tue Jun 11 03:58:16 2013 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 0675121F9636 for ; Tue, 11 Jun 2013 03:58:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.788 X-Spam-Level: X-Spam-Status: No, score=-1.788 tagged_above=-999 required=5 tests=[AWL=1.189, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uO9Jmb4krZvW for ; Tue, 11 Jun 2013 03:58:11 -0700 (PDT) Received: from mail-lb0-f171.google.com (mail-lb0-f171.google.com [209.85.217.171]) by ietfa.amsl.com (Postfix) with ESMTP id 6DDA921F9458 for ; Tue, 11 Jun 2013 03:58:11 -0700 (PDT) Received: by mail-lb0-f171.google.com with SMTP id 13so4040525lba.2 for ; Tue, 11 Jun 2013 03:58:10 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:x-originating-ip:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding:x-gm-message-state; bh=Y+UI1j0Vvl6luWHnu8B0fCQS8YWeRU3vqcvahXRi3VE=; b=Dau18pIObNmcQyViXdu9sevTvZwN2vUGWYKrXOqOKrUFy813Eug/15vX60QLa6LQpV w4WL/PfQAUTyxlaEnvwFZ5g5AKF6jAYm1H2jL1GwPXrqdYCdkjDjZj4hn7B5BxMjX+Lg H5zAjro+D/OqpG3gmx3nxrdNR1K3r0Lmskt3k7do9k/9XThR2Eo1f/iWPMJXztfk8EaP FR9G34k/+dM2cSdbPoQkq7SiLPGMKhrT0tTIJ4NxqvVLODLYul13C9kmaG0HwfBzeOnM oGvfb/271kwJfG0ZnOlyDc6H797ggQZ4DxprukYS5wBmLCtoKrQidcLvxzg0Xt6bBztr 7bvg== MIME-Version: 1.0 X-Received: by 10.152.120.196 with SMTP id le4mr2321010lab.6.1370948290186; Tue, 11 Jun 2013 03:58:10 -0700 (PDT) Sender: stedolan@stedolan.net Received: by 10.114.176.231 with HTTP; Tue, 11 Jun 2013 03:58:10 -0700 (PDT) X-Originating-IP: [131.111.184.26] In-Reply-To: References: Date: Tue, 11 Jun 2013 11:58:10 +0100 X-Google-Sender-Auth: FNOhr-DvVnDGOLk4bI9Q_S4EHhE Message-ID: From: Stephen Dolan To: Jacob Davies Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQn2G9C348p/ZRpQu5/KBvEUW5qFpAN5E1iIoSbiP/ksGotWMBQa/wJW0NoQHO2lQSg3mnMZ Cc: "json@ietf.org" Subject: Re: [Json] "Generators SHOULD escape all Unicode whitespace characters"? X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 11 Jun 2013 10:58:16 -0000 On Mon, Jun 10, 2013 at 11:54 PM, Jacob Davies wrote: > I'm curious if anyone else thinks this is worth suggesting to > implementors. There are a number of non-ASCII Unicode whitespace and > control characters that are not required to be escaped right now. > > I think generators SHOULD escape them. Obviously parsers must continue > to accept them unescaped regardless. The set is fairly small and could > be enumerated in the document (it might expand in future, but this > would be a good start): > > http://en.wikipedia.org/wiki/Space_(punctuation)#Spaces_in_Unicode > > "Whitespace smuggling" is a mild security concern and, from > experience, can be quite hard to debug if non-0x20 spaces are not > escaped. There is a small overhead of a couple of characters in doing > so. > > Everything else in JSON's text serialization uses either printing > characters, insignificant ASCII whitespace between values, or plain > spaces in strings. Of course some printing Unicode characters are > doppelg=E4ngers so perhaps people feel it is not worth worrying about > whitespace either. > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json There is an interesting issue with unescaped unicode whitespace: ECMAScript does not allow U+2028 LINE SEPARATOR inside a string literal, yet JSON does (as it is not one of the listed must-always-be-escaped characters). See http://timelessrepo.com/json-isnt-a-javascript-subset Stephen From paul.hoffman@vpnc.org Tue Jun 11 09:06:14 2013 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 5B14821F8F2F for ; Tue, 11 Jun 2013 09:06:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.45 X-Spam-Level: X-Spam-Status: No, score=-102.45 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dYE9wFRcLZp1 for ; Tue, 11 Jun 2013 09:06:13 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id C810E21F8D6D for ; Tue, 11 Jun 2013 09:06:13 -0700 (PDT) Received: from [10.20.30.90] (50-0-66-165.dsl.dynamic.sonic.net [50.0.66.165]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r5BG6BFN088236 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 11 Jun 2013 09:06:12 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Paul Hoffman In-Reply-To: Date: Tue, 11 Jun 2013 09:06:11 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <51B73868-AA72-439E-B422-BF6A2B0E83ED@vpnc.org> References: <06c101ce6625$0f891bf0$2e9b53d0$@augustcellars.com> <379266A1-82C1-4FF5-BD7C-EE657F1FD41F@vpnc.org> <06e901ce6638$e8f27a90$bad76fb0$@augustcellars.com> <51DE7E41-D682-4340-A234-7F7CFE513C10@vpnc.org> <070b01ce664b$e5e0ac10$b1a20430$@augustcellars.com> <6E03D281-D6BA-424D-A30A-3DA18E61A051@vpnc.org> To: json@ietf.org X-Mailer: Apple Mail (2.1508) Subject: Re: [Json] Leading and trailing whitespace X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 11 Jun 2013 16:06:14 -0000 On Jun 10, 2013, at 10:14 PM, Carsten Bormann wrote: > On Jun 11, 2013, at 05:42, Nico Williams = wrote: >=20 >> Do implementations that allow any value type at the top-level allow >> leading and/or trailing whitespace? >=20 > Yes. E.g., >=20 >>> JSON.parse("\r\n \t 27 \r\n \t", quirks_mode: true) > =3D> 27 >=20 > (quirks_mode is the flag that switches on the non-coforming acceptance = of any "value".) >=20 >> *Should* they? >=20 > Yes. >=20 > (If you are not convinced from first principles: people have argued = you can do streaming by adding whitespace, and that required being = allowed to add whitespace :-) >=20 > So we will have to add a production: >=20 > JSON-value =3D ws value ws >=20 > That didn't seem too hard. Question: are you saying we should do that even if we don't allow all = values at the top level, or only if we add them at the top level? --Paul Hoffman= From cabo@tzi.org Tue Jun 11 09:16:52 2013 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 D06E621F8F9E for ; Tue, 11 Jun 2013 09:16:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.147 X-Spam-Level: X-Spam-Status: No, score=-106.147 tagged_above=-999 required=5 tests=[AWL=0.102, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ygr+WPsP-RFc for ; Tue, 11 Jun 2013 09:16:47 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 5B32D21F9634 for ; Tue, 11 Jun 2013 09:16:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r5BGGfBN022471; Tue, 11 Jun 2013 18:16:41 +0200 (CEST) Received: from [192.168.217.105] (p54893004.dip0.t-ipconnect.de [84.137.48.4]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 1AA433608; Tue, 11 Jun 2013 18:16:41 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <51B73868-AA72-439E-B422-BF6A2B0E83ED@vpnc.org> Date: Tue, 11 Jun 2013 18:16:40 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <9AF10493-9076-455E-97ED-C9F104A8D797@tzi.org> References: <06c101ce6625$0f891bf0$2e9b53d0$@augustcellars.com> <379266A1-82C1-4FF5-BD7C-EE657F1FD41F@vpnc.org> <06e901ce6638$e8f27a90$bad76fb0$@augustcellars.com> <51DE7E41-D682-4340-A234-7F7CFE513C10@vpnc.org> <070b01ce664b$e5e0ac10$b1a20430$@augustcellars.com> <6E03D281-D6BA-424D-A30A-3DA18E61A051@vpnc.org> <51B73868-AA72-439E-B422-BF6A2B0E83ED@vpnc.org> To: Paul Hoffman X-Mailer: Apple Mail (2.1508) Cc: json@ietf.org Subject: Re: [Json] Leading and trailing whitespace X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 11 Jun 2013 16:16:52 -0000 On Jun 11, 2013, at 18:06, Paul Hoffman wrote: >> So we will have to add a production: >>=20 >> JSON-value =3D ws value ws >>=20 >> That didn't seem too hard. >=20 > Question: are you saying we should do that even if we don't allow all = values at the top level, or only if we add them at the top level? This production does not have any effect unless we use it. The radical proposal is to replace the top-level JSON-text with it, or JSON-text =3D ws value ws My less radical, but somewhat questionable proposal is to use it as a = second "top-level", i.e., keep=20 JSON-text as is as the basis for application/json and the +json media = types, and add application/json-value referencing this new production. The less radical proposal is somewhat questionable because it is very = likely that people will keep sending around JSON-value representations = with a application/json media type even it is clarified that this one is = JSON-text only. On the other hand I haven't seen too many documented = cases of that, so maybe it is not that much of a problem. Clearly, some = thinking would need to go into how +json would handle the desire for = isolated atomic JSON values. And, some phrases as in "send it to me in = JSON" would need some recalibration, because it is no longer clear which = variant is needed. (Arguably, that hasn't really been clear for a = while.) Gr=FC=DFe, Carsten From tsaloranta@gmail.com Tue Jun 11 10:29:10 2013 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 A2E2E21F856D for ; Tue, 11 Jun 2013 10:29:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[AWL=0.152, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D89wEkPsnlOU for ; Tue, 11 Jun 2013 10:29:09 -0700 (PDT) Received: from mail-wg0-x22c.google.com (mail-wg0-x22c.google.com [IPv6:2a00:1450:400c:c00::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 4A6B121F88FB for ; Tue, 11 Jun 2013 10:29:09 -0700 (PDT) Received: by mail-wg0-f44.google.com with SMTP id m15so5077491wgh.23 for ; Tue, 11 Jun 2013 10:29:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=/pNu8dYwljLG59bK7XDWUfAbH3ya3xHHLM0K7KHrS8c=; b=ljz73L9QZAnhhON44fWo2bmiD/Pu34+vgmQA4dyEsYN41QIdGEkARohT14ZtvNApow m3kNSDvjbFVLfigSpVNjPNmLcq0vSTrD8BlPKn0DM1VRIAuc8N41zyFhTrAIrJ0fLJmx R72GVC49ZdX37R+VmEUmUueGBG4hpMdSs6rFW9mTFWUm4JZRZAnumRc8yD8fCtHbiMd/ qc9I1Cf2NwW9sK+dmPYG+Zzj8LcLNoD/lTm00tjDsc5OypVEUO0DYzVSKVOkzU+qQ94H B7238pLric9ljimh5SfUhdeB9i1nFxQox+YKkM7zcAz5camCl1qcehw4IlG+0Om/+y4n wwAw== MIME-Version: 1.0 X-Received: by 10.194.90.244 with SMTP id bz20mr9625132wjb.69.1370971748438; Tue, 11 Jun 2013 10:29:08 -0700 (PDT) Received: by 10.227.72.74 with HTTP; Tue, 11 Jun 2013 10:29:08 -0700 (PDT) In-Reply-To: References: <06c101ce6625$0f891bf0$2e9b53d0$@augustcellars.com> <379266A1-82C1-4FF5-BD7C-EE657F1FD41F@vpnc.org> <06e901ce6638$e8f27a90$bad76fb0$@augustcellars.com> <51DE7E41-D682-4340-A234-7F7CFE513C10@vpnc.org> <070b01ce664b$e5e0ac10$b1a20430$@augustcellars.com> <6E03D281-D6BA-424D-A30A-3DA18E61A051@vpnc.org> Date: Tue, 11 Jun 2013 10:29:08 -0700 Message-ID: From: Tatu Saloranta To: Nico Williams Content-Type: multipart/alternative; boundary=047d7bfd090a10187904dee43c67 Cc: Jim Schaad , Paul Hoffman , "json@ietf.org" Subject: Re: [Json] Leading and trailing whitespace X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 11 Jun 2013 17:29:10 -0000 --047d7bfd090a10187904dee43c67 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Jun 10, 2013 at 8:42 PM, Nico Williams wrote: > On Mon, Jun 10, 2013 at 9:53 PM, Paul Hoffman > wrote: > > On Jun 10, 2013, at 7:32 PM, "Jim Schaad" > wrote: > > > > You might be asking "if we allow other JSON items at the top level, will > we also allow optional whitespace before and after". But that's a > supposition, not a question about what is in the document now. > > Sure, but since we're full-out having the any value type at the > top-level discussion (and it looks like we'll at least have to have > informational text acknowledging that ECMAScript will allow them) this > becomes relevant. > > Do implementations that allow any value type at the top-level allow > leading and/or trailing whitespace? > > Yes. I was surprised to even see the question -- since white space is allowed between array and object entries, it would seem surprising if whitespace at root context behaved differently. At least I have never encountered a case where parser discarded piece of JSON due to root-level whitespace (I mostly work on java) The most practical reason is really that when humans edit JSON, trailing space after root object or array may be added by text editor. White spce is all about readability. > *Should* they? > > IMO the intuitive answer to the last should be "yes", that arbitrary > amounts of whitespace can surround any value regardless of where it > appears. But my intuition could be wrong. > I think it should be allowed unless there are actual clear reasons not to allow it. And unlike with XML limitation for no whitespace before XML declaration, there does not seem to be solid reasons, other than perhaps suggestion that since this was omitted from definition it should not be added. -+ Tatu +- --047d7bfd090a10187904dee43c67 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Mon, Jun 10, 2013 at 8:42 PM, Nico Williams <nic= o@cryptonector.com> wrote:
On Mon, Jun 10, 2013 at 9:= 53 PM, Paul Hoffman <paul.hoffm= an@vpnc.org> wrote:
> On Jun 10, 2013, at 7:32 PM, "Jim Schaad" <ietf@augustcellars.com> wrote:
>
> You might be asking "if we allow other JS= ON items at the top level, will we also allow optional whitespace before an= d after". But that's a supposition, not a question about what is i= n the document now.

Sure, but since we're full-out having the any value type at the top-level discussion (and it looks like we'll at least have to have
informational text acknowledging that ECMAScript will allow them) this
becomes relevant.

Do implementations that allow any value type at the top-level allow
leading and/or trailing whitespace?


Yes. I was surprised to even see the q= uestion -- since white space is allowed between array and object entries, i= t would seem surprising if whitespace at root context behaved differently.<= br>
At least I have never encountered a case where parser discarded = piece of JSON due to root-level whitespace (I mostly work on java)

The most practical reason is really that when humans edit JSON, t= railing space after root object or array may be added by text editor. White= spce is all about readability.

=A0
*Should* they?

IMO the intuitive answer to the last should be "yes", that arbitr= ary
amounts of whitespace can surround any value regardless of where it
appears. =A0But my intuition could be wrong.

I think it should be allowed unless there are actual clear reasons no= t to allow it.
And unlike with XML limitation for no whitespa= ce before XML declaration, there does not seem to be solid reasons, other t= han perhaps suggestion that since this was omitted from definition it shoul= d not be added.

-+ Tatu +-
=A0
--047d7bfd090a10187904dee43c67-- From paul.hoffman@vpnc.org Tue Jun 11 10:32:51 2013 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 8C6FD21F962A for ; Tue, 11 Jun 2013 10:32:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.157 X-Spam-Level: X-Spam-Status: No, score=-102.157 tagged_above=-999 required=5 tests=[AWL=-0.157, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id isPWPYnRNA-y for ; Tue, 11 Jun 2013 10:32:51 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 1D22521F960F for ; Tue, 11 Jun 2013 10:32:51 -0700 (PDT) Received: from [10.20.30.90] (50-0-66-165.dsl.dynamic.sonic.net [50.0.66.165]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r5BHWmju091653 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 11 Jun 2013 10:32:49 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) From: Paul Hoffman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <6898D31C-FF53-4B8D-9F81-5519C934E00D@vpnc.org> Date: Tue, 11 Jun 2013 10:32:48 -0700 To: "json@ietf.org" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) Subject: [Json] ABNF nits -- LAST CHANCE ON PROPOSALS X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 11 Jun 2013 17:32:51 -0000 Greetings again. We currently have one rolled-up proposal for ABNF nit = fixes for RFC 4627. If you have other nits to fix, please do so now on = this thread. The ABNF below is separated by the text sections where it = appears. Note that these are fixes that apply only to RFC 4627. Other proposals = change some of the ABNF, but those are being dealt with in their own = threads. --Paul Hoffman JSON-text =3D object / array begin-array =3D ws %x5B ws ; [ left square bracket begin-object =3D ws %x7B ws ; { left curly bracket end-array =3D ws %x5D ws ; ] right square bracket end-object =3D ws %x7D ws ; } right curly bracket name-separator =3D ws %x3A ws ; : colon value-separator =3D ws %x2C ws ; , comma ws =3D *( %x20 / ; Space %x09 / ; Horizontal tab %x0A / ; Line feed or New line %x0D ; Carriage return ) value =3D false / null / true / object / array / number / string false =3D %x66.61.6c.73.65 ; false null =3D %x6e.75.6c.6c ; null true =3D %x74.72.75.65 ; true object =3D begin-object [ member *( value-separator member ) ] end-object member =3D string name-separator value array =3D begin-array [ value *( value-separator value ) ] end-array number =3D [ minus ] int [ frac ] [ exp ] decimal-point =3D %x2E ; . digit1-9 =3D %x31-39 ; 1-9 e =3D %x65 / %x45 ; e E exp =3D e [ minus / plus ] 1*DIGIT frac =3D decimal-point 1*DIGIT int =3D zero / ( digit1-9 *DIGIT ) minus =3D %x2D ; - plus =3D %x2B ; + zero =3D %x30 ; 0 string =3D quotation-mark *char quotation-mark char =3D unescaped / escape ( %x22 / ; " quotation mark U+0022 %x5C / ; \ reverse solidus U+005C %x2F / ; / solidus U+002F %x62 / ; b backspace U+0008 %x66 / ; f form feed U+000C %x6E / ; n line feed U+000A %x72 / ; r carriage return U+000D %x74 / ; t tab U+0009 %x75 4HEXDIG ) ; uXXXX U+XXXX escape =3D %x5C ; \ quotation-mark =3D %x22 ; " unescaped =3D %x20-21 / %x23-5B / %x5D-10FFFF HEXDIG =3D DIGIT / %x41-46 / %x61-66 ; 0-9, A-F, or a-f ; HEXDIG equivalent to HEXDIG rule in [RFC5234] DIGIT =3D %x30-39 ; 0-9 ; DIGIT equivalent to DIGIT rule in [RFC5234] From paul.hoffman@vpnc.org Tue Jun 11 10:44:43 2013 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 4107E21F8904 for ; Tue, 11 Jun 2013 10:44:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.453 X-Spam-Level: X-Spam-Status: No, score=-102.453 tagged_above=-999 required=5 tests=[AWL=0.146, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tGzI4PhUMIbU for ; Tue, 11 Jun 2013 10:44:42 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 2761221F9634 for ; Tue, 11 Jun 2013 10:44:36 -0700 (PDT) Received: from [10.20.30.90] (50-0-66-165.dsl.dynamic.sonic.net [50.0.66.165]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r5BHiZF4092023 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 11 Jun 2013 10:44:35 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) From: Paul Hoffman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <0FBD58CE-748D-419A-8578-CCBF3FDF97CE@vpnc.org> Date: Tue, 11 Jun 2013 10:44:34 -0700 To: "json@ietf.org" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) Subject: [Json] String comparisons -- LAST CHANCE ON PROPOSALS X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 11 Jun 2013 17:44:43 -0000 Greetings again. The following thread has died off, with two proposals. = If none of "leave the text in the draft as-is" or the following = proposals would be acceptable to you, please propose specific text that = would be acceptable. --Paul Hoffman Proposal 1 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D In Section 2.5. Strings, immediately before the ABNF add: For purpose of establishing key equality, comparisons MUST be conducted, = after all unescaping is done, by comparing numeric character code = points. There is to be no modification of any kind to the characters in = keys, including case-changing or combining-form normalization. For example, the following four keys MUST be considered equivalent: * "\u002F" * "\u002f" * "\/" * "/" Proposal 2 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D In Section 2.5. Strings, immediately before the ABNF add: For purpose of establishing key equality, comparisons MUST be conducted, = after all unescaping is done, by comparing numeric character code = points. There MUST NOT be any modification of any kind to the characters = in keys, including change of case or change between precomposed and = decomposed forms. For example, the following four keys MUST be considered equivalent: * "\u002F" * "\u002f" * "\/" * "/" From cromis@gmail.com Tue Jun 11 10:57:01 2013 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 DA5C221F97E6 for ; Tue, 11 Jun 2013 10:56:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rKYjGrICwS6J for ; Tue, 11 Jun 2013 10:56:58 -0700 (PDT) Received: from mail-qc0-x235.google.com (mail-qc0-x235.google.com [IPv6:2607:f8b0:400d:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id 2264921F98AC for ; Tue, 11 Jun 2013 10:56:49 -0700 (PDT) Received: by mail-qc0-f181.google.com with SMTP id u12so766779qcx.40 for ; Tue, 11 Jun 2013 10:56:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=8lPUe3CdqQ7KmVlvFHzOqhg3u+K/QCtnyqFlJt0200M=; b=QdanWVCb8FcRySTQ/84ctFZu861WLW3t/DeaUZ1gLd3hXX3h2v/PyIXRWBHf38cAXk JLrMAnjF5avjEMiCfP8QY+8ztANLuWhy+adlStzqbz25VtDeHhzNHqIgh0I6InZ95NKs b5UoOKZUR3FbBdp04+lvKjETqXA6ejSVxdC0BS21mZDgteqHy3rk093xm9FFgiG1wyDp hqnIimuupfKYReqWAaiIZI+c0usz7Q//ohbjiJQlbnBb0vMLJtau5NFehp2IeLDxFcsV z+3d10XLZxv3VrogwvNGlSciLfFtKuuHFKr0CYqbm0hYckmEnQGeFCh5Jv3HJ3S0nOpk nOhA== X-Received: by 10.224.199.3 with SMTP id eq3mr20141335qab.18.1370973407210; Tue, 11 Jun 2013 10:56:47 -0700 (PDT) MIME-Version: 1.0 Sender: cromis@gmail.com Received: by 10.49.106.228 with HTTP; Tue, 11 Jun 2013 10:56:27 -0700 (PDT) In-Reply-To: References: <06c101ce6625$0f891bf0$2e9b53d0$@augustcellars.com> <379266A1-82C1-4FF5-BD7C-EE657F1FD41F@vpnc.org> <06e901ce6638$e8f27a90$bad76fb0$@augustcellars.com> <51DE7E41-D682-4340-A234-7F7CFE513C10@vpnc.org> <070b01ce664b$e5e0ac10$b1a20430$@augustcellars.com> <6E03D281-D6BA-424D-A30A-3DA18E61A051@vpnc.org> From: Jacob Davies Date: Tue, 11 Jun 2013 10:56:27 -0700 X-Google-Sender-Auth: iJI0qjhRId_8zv8NJWJNygJUP5E Message-ID: To: Tatu Saloranta Content-Type: text/plain; charset=ISO-8859-1 Cc: Nico Williams , Jim Schaad , Paul Hoffman , "json@ietf.org" Subject: Re: [Json] Leading and trailing whitespace X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 11 Jun 2013 17:57:01 -0000 On Tue, Jun 11, 2013 at 10:29 AM, Tatu Saloranta wrote: > And unlike with XML limitation for no whitespace before XML declaration, > there does not seem to be solid reasons, other than perhaps suggestion that > since this was omitted from definition it should not be added. It's clearly allowed in the RFC: JSON-text = object / array object = begin-object [ member *( value-separator member ) ] end-object begin-object = ws %x7B ws end-object = ws %x7D ws array = begin-array [ value *( value-separator value ) ] end-array begin-array = ws %x5B ws end-array = ws %x5D ws ws = *( %x20 / %x09 / %x0A / %x0D ) From stefan@drees.name Tue Jun 11 11:10:36 2013 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 E471B21F947C for ; Tue, 11 Jun 2013 11:10:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z0z3-GgIins1 for ; Tue, 11 Jun 2013 11:10:31 -0700 (PDT) Received: from mout.web.de (mout.web.de [212.227.15.4]) by ietfa.amsl.com (Postfix) with ESMTP id DA65421F9420 for ; Tue, 11 Jun 2013 11:10:30 -0700 (PDT) Received: from newyork.local.box ([77.13.213.234]) by smtp.web.de (mrweb002) with ESMTPSA (Nemesis) id 0LqlF4-1U8TdR3gjS-00eHld; Tue, 11 Jun 2013 20:10:28 +0200 Message-ID: <51B76812.6050307@drees.name> Date: Tue, 11 Jun 2013 20:10:26 +0200 From: Stefan Drees User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Paul Hoffman References: <0FBD58CE-748D-419A-8578-CCBF3FDF97CE@vpnc.org> In-Reply-To: <0FBD58CE-748D-419A-8578-CCBF3FDF97CE@vpnc.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:lSszKY351TxrHyv/qwx/7HQz+3//EPsst0FSpsTm1Z+5mgtwZ6M dxA1Uatz7bPUtOSCwLPvfdQFAcUCRpjDkmT+fXBUzhBvPIp3O6aiJzPiFu8dG/Rj4j1SjB7 EWg2ORutSxsmtVYHvEtkiOXSBDCwoJkzmRpLiQXCryAPL7AHQPbv/P88smspRAnTAzAozMA ugIDT1KTqhbvJQ94n7Zlw== Cc: "json@ietf.org" Subject: Re: [Json] String comparisons -- LAST CHANCE ON PROPOSALS X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stefan@drees.name List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jun 2013 18:10:37 -0000 On 2013-06-11 19:44 CEST, Paul Hoffman wrote: > Greetings again. The following thread has died off, with two > proposals. If none of "leave the text in the draft as-is" or the > following proposals would be acceptable to you, please propose specific > text that would be acceptable. > > --Paul Hoffman > > Proposal 1 > ========== > In Section 2.5. Strings, immediately before the ABNF add: > > For purpose of establishing key equality, comparisons MUST be > conducted, after all unescaping is done, by comparing numeric character > code points. There is to be no modification of any kind to the > characters in keys, including case-changing or combining-form normalization. > > For example, the following four keys MUST be considered equivalent: > > * "\u002F" > * "\u002f" > * "\/" > * "/" > > Proposal 2 > ========== > In Section 2.5. Strings, immediately before the ABNF add: > > For purpose of establishing key equality, comparisons MUST be > conducted, after all unescaping is done, by comparing numeric character > code points. There MUST NOT be any modification of any kind to the > characters in keys, including change of case or change between > precomposed and decomposed forms. > > For example, the following four keys MUST be considered equivalent: > > * "\u002F" > * "\u002f" > * "\/" > * "/" > I do not know what the most convenient form of the proposal I want to make in this case is: In both proposals above (1 and 2) the terms "key" and "keys" are used, where I propose to use "name" and "names" respectively instead. We had IMO a lot of "whishful thinking" lately that seemed to start by replacing the word "name" in the current JSON RFC with "key" and based on this transform some participants were trying to go further and further until maybe the paradise of uniqueness constraints finally would have been reached by all of us ;-) All two occurences of the term "key" inside the RFC 4627 are related to RFC2119 unless I overlooked something. JSON uses the term "name" for the first part of those pairs that form the members of objects. So I'll give a parametrized proposal form a try, but please advice me if there is a better way to accomplish this: Proposal 3 ========== Use either the Proposal 1 or Proposal 2 but with the paragraph beginning as "For purpose" having replaced the terms "key" and "keys" with the terms "name" and "names" respectively wherever they occur therein. All the best, Stefan. From markus.lanthaler@gmx.net Tue Jun 11 11:22:06 2013 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 DB71821F96E9 for ; Tue, 11 Jun 2013 11:22:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.15 X-Spam-Level: X-Spam-Status: No, score=-1.15 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QFNCL6olNs2c for ; Tue, 11 Jun 2013 11:22:01 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) by ietfa.amsl.com (Postfix) with ESMTP id 79CB121F9638 for ; Tue, 11 Jun 2013 11:21:51 -0700 (PDT) Received: from mailout-de.gmx.net ([10.1.76.1]) by mrigmx.server.lan (mrigmx002) with ESMTP (Nemesis) id 0Lrp0S-1UMeJ60R6E-013gtp for ; Tue, 11 Jun 2013 20:21:50 +0200 Received: (qmail invoked by alias); 11 Jun 2013 18:21:49 -0000 Received: from 84-115-182-43.dynamic.surfer.at (EHLO Vostro3500) [84.115.182.43] by mail.gmx.net (mp001) with SMTP; 11 Jun 2013 20:21:49 +0200 X-Authenticated: #419883 X-Provags-ID: V01U2FsdGVkX19ems8MgGtevjW2HTNCU9Rc+vGRxu+xKP6x0gHFUw 6GY+8T0rDEl81F From: "Markus Lanthaler" To: References: <0FBD58CE-748D-419A-8578-CCBF3FDF97CE@vpnc.org> <51B76812.6050307@drees.name> In-Reply-To: <51B76812.6050307@drees.name> Date: Tue, 11 Jun 2013 20:21:47 +0200 Message-ID: <009a01ce66d0$892afe50$9b80faf0$@lanthaler@gmx.net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac5mzvr1VlQShFFKQJifLLB7Dnq0nwAAQieA Content-Language: de X-Y-GMX-Trusted: 0 Subject: Re: [Json] String comparisons -- LAST CHANCE ON PROPOSALS X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 11 Jun 2013 18:22:07 -0000 On Tuesday, June 11, 2013 8:10 PM, Stefan Drees wrote: > I do not know what the most convenient form of the proposal I want to > make in this case is: > In both proposals above (1 and 2) the terms "key" and "keys" are used, > where I propose to use "name" and "names" respectively instead. +1, was just about to say the same.: So both proposals should be changed to For the purpose of establishing equality of names within an object... to the characters in names... -- Markus Lanthaler @markuslanthaler From paul.hoffman@vpnc.org Tue Jun 11 11:26:49 2013 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 45E3F21F90EF for ; Tue, 11 Jun 2013 11:26:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.456 X-Spam-Level: X-Spam-Status: No, score=-102.456 tagged_above=-999 required=5 tests=[AWL=0.143, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0asjq6LuwDw9 for ; Tue, 11 Jun 2013 11:26:48 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id C9D9521F9048 for ; Tue, 11 Jun 2013 11:26:48 -0700 (PDT) Received: from [10.20.30.90] (50-0-66-165.dsl.dynamic.sonic.net [50.0.66.165]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r5BIQkHO093715 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 11 Jun 2013 11:26:47 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Paul Hoffman In-Reply-To: <51B76812.6050307@drees.name> Date: Tue, 11 Jun 2013 11:26:46 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <950B73AD-4DCB-4C17-995A-723A4B8366DE@vpnc.org> References: <0FBD58CE-748D-419A-8578-CCBF3FDF97CE@vpnc.org> <51B76812.6050307@drees.name> To: stefan@drees.name X-Mailer: Apple Mail (2.1508) Cc: "json@ietf.org" Subject: Re: [Json] String comparisons -- LAST CHANCE ON PROPOSALS X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 11 Jun 2013 18:26:49 -0000 On Jun 11, 2013, at 11:10 AM, Stefan Drees wrote: > Use either the Proposal 1 or Proposal 2 but with the paragraph = beginning as "For purpose" having replaced the terms "key" and "keys" = with the terms "name" and "names" respectively wherever they occur = therein. Yipes, very good catch. --Paul Hoffman= From tsaloranta@gmail.com Tue Jun 11 11:30:16 2013 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 1B10021F97E6 for ; Tue, 11 Jun 2013 11:30:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.457 X-Spam-Level: X-Spam-Status: No, score=-2.457 tagged_above=-999 required=5 tests=[AWL=0.142, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XZxwmf-Z8yFf for ; Tue, 11 Jun 2013 11:30:15 -0700 (PDT) Received: from mail-wg0-x22e.google.com (mail-wg0-x22e.google.com [IPv6:2a00:1450:400c:c00::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 589CE21F9799 for ; Tue, 11 Jun 2013 11:30:15 -0700 (PDT) Received: by mail-wg0-f46.google.com with SMTP id c11so2685801wgh.1 for ; Tue, 11 Jun 2013 11:30:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=jIZh7+c5TDwVWRw8B16BYpQIu2FfRVbG8fYrbH6Dvmg=; b=WrSV4ciqiBHKLdiCFG4/OVJstezn9E02y0DzlpzNbVST+LwZH+4Qf8aLn7ONE1H4dy 3/VHqiWZmGZmSHzp2pEa/9gaLnMGFvTO+ju7NyG/00SwA1M2Jlmcz/oqRMTfcztqimSk VTeHKn95SKwjlWIYeH6etrgoF1Pa7yE5DMWzV2Qvdbefj1VBDCAS24Lw6Gj34Af2mS4x lqXvyT/Q4UpoW/BHmPojNm2vv/ucH8uHaVDkCEYMQvVrcUnYQjbrk7+rwlImEQZ9RKyp yZIaR1NiyV14ugSIA7JP4oJCPm3kkG9mGeG98JJeutdAbeOZ5EKBVhzVrFm3/68V5Ibt L/Iw== MIME-Version: 1.0 X-Received: by 10.180.185.44 with SMTP id ez12mr2209064wic.7.1370975414481; Tue, 11 Jun 2013 11:30:14 -0700 (PDT) Received: by 10.227.72.74 with HTTP; Tue, 11 Jun 2013 11:30:14 -0700 (PDT) In-Reply-To: References: <06c101ce6625$0f891bf0$2e9b53d0$@augustcellars.com> <379266A1-82C1-4FF5-BD7C-EE657F1FD41F@vpnc.org> <06e901ce6638$e8f27a90$bad76fb0$@augustcellars.com> <51DE7E41-D682-4340-A234-7F7CFE513C10@vpnc.org> <070b01ce664b$e5e0ac10$b1a20430$@augustcellars.com> <6E03D281-D6BA-424D-A30A-3DA18E61A051@vpnc.org> Date: Tue, 11 Jun 2013 11:30:14 -0700 Message-ID: From: Tatu Saloranta To: Jacob Davies Content-Type: multipart/alternative; boundary=001a11c22574937b3004dee516c6 Cc: Nico Williams , Jim Schaad , Paul Hoffman , "json@ietf.org" Subject: Re: [Json] Leading and trailing whitespace X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 11 Jun 2013 18:30:16 -0000 --001a11c22574937b3004dee516c6 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Jun 11, 2013 at 10:56 AM, Jacob Davies wrote: > On Tue, Jun 11, 2013 at 10:29 AM, Tatu Saloranta > wrote: > > And unlike with XML limitation for no whitespace before XML declaration, > > there does not seem to be solid reasons, other than perhaps suggestion > that > > since this was omitted from definition it should not be added. > > It's clearly allowed in the RFC: > > JSON-text = object / array > > object = begin-object [ member *( value-separator member ) ] end-object > > begin-object = ws %x7B ws > > end-object = ws %x7D ws > > array = begin-array [ value *( value-separator value ) ] end-array > > begin-array = ws %x5B ws > > end-array = ws %x5D ws > > ws = *( %x20 / %x09 / %x0A / %x0D ) > Even better -- I was assuming there was some confusion, based on discussion. Apparently not. -+ Tatu +- --001a11c22574937b3004dee516c6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, Jun 11, 2013 at 10:56 AM, Jacob Davies <jacob@well= .com> wrote:
On Tue, Jun 11, 2013 at 10:29 AM, Tatu Saloranta <tsaloranta@gmail.com> wrote:
> And unlike with XML limitation for no whitespace before XML declaratio= n,
> there does not seem to be solid reasons, other than perhaps suggestion= that
> since this was omitted from definition it should not be added.

It's clearly allowed in the RFC:

JSON-text =3D object / array

object =3D begin-object [ member *( value-separator= member ) ] end-object

begin-object =A0 =A0=3D ws %x7B ws

end-object =A0 =A0 =A0=3D ws %x7D ws

array =3D begin-array [ value *( value-separator va= lue ) ] end-array

begin-array =A0 =A0 =3D ws %x5B ws

end-array =A0 =A0 =A0 =3D ws %x5D ws

ws =3D *( %x20 / %x09 / %x0A / %x0D )


Even better -- = I was assuming there was some confusion, based on discussion.
Apparently not.
=
-+ Tatu +-


--001a11c22574937b3004dee516c6-- From tsaloranta@gmail.com Tue Jun 11 11:34:38 2013 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 53EE721F991F for ; Tue, 11 Jun 2013 11:34:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.466 X-Spam-Level: X-Spam-Status: No, score=-2.466 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SgJJnEGL-nnN for ; Tue, 11 Jun 2013 11:34:37 -0700 (PDT) Received: from mail-wg0-x22f.google.com (mail-wg0-x22f.google.com [IPv6:2a00:1450:400c:c00::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 2DC1B21F96E9 for ; Tue, 11 Jun 2013 11:34:36 -0700 (PDT) Received: by mail-wg0-f47.google.com with SMTP id l18so2746849wgh.14 for ; Tue, 11 Jun 2013 11:34:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=VkrNOEXtixp7EiBkNKbYnsBgbRQrnBHCRJXXvKL2p00=; b=bgjX+xfKozeBoC+WmmBrrW4cQOI5upbbza+1j2I0UO2DWmA3qotONzHJDW7dc7QOut 38cpI1w0Ju9pnPWb8tRFLHMntd/dq93sv/mfO+1QpOx+TrD8akz5Gn4x7k89kr4tJPt/ O89eX3d7lwGhF6bg4B10w/tRxaC+V0mchED1E7Lz/XP/yqLP5IF9aq39QwAg4TVvd4BQ 0gTGqDbubTdqGghLCvPgW556Bn/SuQdYkKgduQZXEyfHFb/ZOV26GYmjlMBDirqcfBsc bKJ3yLiWzYOsshf9konin4z49VvihVosYQJvo724o4ZeIY1YsJ5sfrd9KpIsjxynz2Mr 5iDg== MIME-Version: 1.0 X-Received: by 10.180.11.194 with SMTP id s2mr2218212wib.7.1370975676220; Tue, 11 Jun 2013 11:34:36 -0700 (PDT) Received: by 10.227.72.74 with HTTP; Tue, 11 Jun 2013 11:34:36 -0700 (PDT) In-Reply-To: <255B9BB34FB7D647A506DC292726F6E1151B430DAD@WSMSG3153V.srv.dir.telstra.com> References: <51b23e6d.6196420a.0b15.4245SMTPIN_ADDED_BROKEN@mx.google.com> <51b4dbbe.64da440a.1fc2.6dd2SMTPIN_ADDED_BROKEN@mx.google.com> <51b4ec44.ea05420a.7c73.ffffa487SMTPIN_ADDED_BROKEN@mx.google.com> <51b507b1.c686e00a.3a7e.ffffa0adSMTPIN_ADDED_BROKEN@mx.google.com> <20130610201746.GC1057@mercury.ccil.org> <3CE20E15-8F9E-4727-BBE7-FBB06F7CAC24@jorgechamorro.com> <255B9BB34FB7D647A506DC292726F6E1151B430DAD@WSMSG3153V.srv.dir.telstra.com> Date: Tue, 11 Jun 2013 11:34:36 -0700 Message-ID: From: Tatu Saloranta To: "Manger, James H" Content-Type: multipart/alternative; boundary=001a11c355a22d4e3104dee5267b Cc: "json@ietf.org" , R S Subject: Re: [Json] Allow any JSON value at the top level X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 11 Jun 2013 18:34:38 -0000 --001a11c355a22d4e3104dee5267b Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable +1 for this: although I can see why additional media type is suggested, I just do not see it as a better alternative from practical viewpoint, due to these reasons. -+ Tatu +- On Mon, Jun 10, 2013 at 9:19 PM, Manger, James H < James.H.Manger@team.telstra.com> wrote: > > A new media type would solve any problem that I'm aware of. > > A new media type for any JSON value (not just object or array) could work > in theory, but I doubt it can work in practice. > > It would significantly complicate conversations about JSON. Mentions of > JSON in APIs, protocols, specs etc would have to qualify whether or not > they support both, or just one, of the media types. Two media types > probably need to be advertised in HTTP Accept headers. There would be two > choices for media type when sending a JSON object or array, which would > produce different behaviour in some cases (eg "old" systems that don't kn= ow > about the new type). > > Would media types with a +json suffix allow any JSON values? Or would we > need a second suffix as well? > > It would be better to allow any JSON value with the existing media type > and suffix. > > > A top-level JSON value would no longer necessarily be self-delimiting. I > doubt this is that crucial. Many media types are not self-delimiting. Eve= n > JSON objects and arrays are not strictly self-delimiting as they allow > leading and trailing whitespace. Appending whitespace to a JSON value wou= ld > make as self-delimiting again =96 restoring this property where needed > (allowing whitespace around non-object-non-array top-level values would b= e > a sensible part of the change). > > -- > James Manger > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > --001a11c355a22d4e3104dee5267b Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
+1 for this: although I can see why additional media = type is suggested, I just do not see it as a better alternative from practi= cal viewpoint, due to these reasons.

-+ Tatu +-


On Mon, Jun 10, 2013 at 9:19 PM, Manger,= James H <James.H.Manger@team.telstra.com> wro= te:
> A new media type woul= d solve any problem that I'm aware of.

A new media type for any JSON value (not just object or array) could = work in theory, but I doubt it can work in practice.

It would significantly complicate conversations about JSON. Mentions of JSO= N in APIs, protocols, specs etc would have to qualify whether or not they s= upport both, or just one, of the media types. Two media types probably need= to be advertised in HTTP Accept headers. There would be two choices for me= dia type when sending a JSON object or array, which would produce different= behaviour in some cases (eg "old" systems that don't know ab= out the new type).

Would media types with a +json suffix allow any JSON values? Or would we ne= ed a second suffix as well?

It would be better to allow any JSON value with the existing media type and= suffix.


A top-level JSON value would no longer necessarily be self-delimiting. I do= ubt this is that crucial. Many media types are not self-delimiting. Even JS= ON objects and arrays are not strictly self-delimiting as they allow leadin= g and trailing whitespace. Appending whitespace to a JSON value would make = as self-delimiting again =96 restoring this property where needed (allowing= whitespace around non-object-non-array top-level values would be a sensibl= e part of the change).

--
James Manger
___________________________________= ____________
json mailing list
json@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/json

--001a11c355a22d4e3104dee5267b-- From tsaloranta@gmail.com Tue Jun 11 11:41:17 2013 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 9383521F94E1 for ; Tue, 11 Jun 2013 11:41:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.473 X-Spam-Level: X-Spam-Status: No, score=-2.473 tagged_above=-999 required=5 tests=[AWL=0.126, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eW0XNJp8qHDn for ; Tue, 11 Jun 2013 11:41:17 -0700 (PDT) Received: from mail-we0-x22c.google.com (mail-we0-x22c.google.com [IPv6:2a00:1450:400c:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 95E3D21F9476 for ; Tue, 11 Jun 2013 11:41:16 -0700 (PDT) Received: by mail-we0-f172.google.com with SMTP id q56so6262785wes.31 for ; Tue, 11 Jun 2013 11:41:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=VxYsvajAyXJopJB/ElPS2bqOgIz+Egzm7uyquIJ0AUY=; b=s3OXwEnJehodINIxgQsYRUEXCOSGnWZekWXbjk6ZmNr10y3v8mwAHzjEYP8Ut97nYF giEgop8e7nUyxC8ytmtsdi2+hVCoAJNKV/69nfrS1omwZYoM6wZ69RU3UYvrcz9mXdIP 3yl8UgjaI2JIsoFku9fbEIXO3/77tSQM7zG5c7ltSjw6M/ODOpofOfR8a7EoyRVL7ZiM m2IOP/9XxvNfXvo+1ytPZHc8WcoYxM4AbtCBSrY+K9AFGsSKW/8MtFF6ZJ0xUJBm2uw/ OZSN3FexgxMDQQk7t1Zv8oJcsiwUNi2cZau+nAjNcT/j2YcFeTLpmOj+DsRvncXN9gLa XFjw== MIME-Version: 1.0 X-Received: by 10.180.211.233 with SMTP id nf9mr1950273wic.55.1370976075738; Tue, 11 Jun 2013 11:41:15 -0700 (PDT) Received: by 10.227.72.74 with HTTP; Tue, 11 Jun 2013 11:41:15 -0700 (PDT) In-Reply-To: References: <255B9BB34FB7D647A506DC292726F6E1151B21F9A9@WSMSG3153V.srv.dir.telstra.com> Date: Tue, 11 Jun 2013 11:41:15 -0700 Message-ID: From: Tatu Saloranta To: Carsten Bormann Content-Type: multipart/alternative; boundary=001a11c338d0fda21204dee53dc9 Cc: "Manger, James H" , "json@ietf.org" Subject: Re: [Json] Allow any JSON value at the top level X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 11 Jun 2013 18:41:17 -0000 --001a11c338d0fda21204dee53dc9 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Jun 11, 2013 at 2:25 AM, Carsten Bormann wrote: > On Jun 7, 2013, at 19:54, Tatu Saloranta wrote: > > >> Apart from the (intellectually nicely challenging, but practically > irrelevant) auto-detection thing, > > > > Irrelevant based on what? I thought this is what any half-decent JSON > parser did; unless platform does not expose byte sequence as input, case > for some scripting languages. > > I have written multiple parsers (json, xml) that do just this, and know > that others exist as well. > > It is true that there are parsers that implement autodetection. > Lots of code is written that is then never exercised. > If by lots of code you mean "less than 100 lines", yes. > > > I don't know what leads to assumption of irrelevancy here, and it should > be fully spelled out. > > This is irrelevant in practice as JSON is used with UTF-8 in practice. > My main concern is with UTF-16. My understanding is that for "Big 5" languages its use make sense, from efficiency perspective. I do not have data on this; in XML space document test sets had non-trivial amount of content in various encodings. If UTF-16 is not widely used then I can see why this would be considered of little significance. > The main job that the text in section 3 seems to do is to convince people > not to send a BOM in front of their UTF-8 JSON. Now that is a good > thing... Unfortunately, some JSON parsers have been "fixed" to accept BOMs. > > Yes. That takes about 50 more lines of code to add, to work around oddities of generators by a certain big Redmond-based software company. -+ Tatu +- --001a11c338d0fda21204dee53dc9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, Jun 11, 2013 at 2:25 AM, Carsten Bormann <cabo@tzi.org= > wrote:
On Jun 7, 2013, at 19:54, Tatu Saloranta <tsaloranta@gmail.com> wrote:

>> Apart from the (intellectually nicely challenging, but practically= irrelevant) auto-detection thing,
>
> Irrelevant based on what? I thought this is what any half-decent JSON = parser did; unless platform does not expose byte sequence as input, case fo= r some scripting languages.
> I have written multiple parsers (json, xml) that do just this, and kno= w that others exist as well.

It is true that there are parsers that implement autodetection.
Lots of code is written that is then never exercised.
=
If by lots of code you mean "less than 100 lines",= yes.
=A0

> I don't know what leads to assumption of irrelevancy here, and it = should be fully spelled out.

This is irrelevant in practice as JSON is used with UTF-8 in practice= .

My main concern is with UTF-16. My un= derstanding is that for "Big 5" languages its use make sense, fro= m efficiency perspective. I do not have data on this; in XML space document= test sets had non-trivial amount of content in various encodings.

If UTF-16 is not widely used then I can see why this would b= e considered of little significance.
=A0
The main job that the text in section 3 seems to do is to convince people n= ot to send a BOM in front of their UTF-8 JSON. =A0Now that is a good thing.= .. =A0Unfortunately, some JSON parsers have been "fixed" to accep= t BOMs.


Yes. That takes about 50 more lines of= code to add, to work around oddities of generators by a certain big Redmon= d-based software company.
=A0
-+ Tatu +-

--001a11c338d0fda21204dee53dc9-- From cowan@ccil.org Tue Jun 11 12:09:55 2013 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 15C9F21F8ECB for ; Tue, 11 Jun 2013 12:09:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.42 X-Spam-Level: X-Spam-Status: No, score=-3.42 tagged_above=-999 required=5 tests=[AWL=0.179, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i1CjMhHUKUKI for ; Tue, 11 Jun 2013 12:09:50 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id 0A8F621F8607 for ; Tue, 11 Jun 2013 12:09:45 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1UmTwj-0005tC-Qv; Tue, 11 Jun 2013 15:09:33 -0400 Date: Tue, 11 Jun 2013 15:09:33 -0400 From: John Cowan To: Tatu Saloranta Message-ID: <20130611190933.GA16049@mercury.ccil.org> References: <255B9BB34FB7D647A506DC292726F6E1151B21F9A9@WSMSG3153V.srv.dir.telstra.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Cc: Carsten Bormann , "Manger, James H" , "json@ietf.org" Subject: Re: [Json] Allow any JSON value at the top level X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 11 Jun 2013 19:09:55 -0000 Tatu Saloranta scripsit: > My main concern is with UTF-16. My understanding is that for "Big 5" > languages its use make sense, from efficiency perspective. I do not > have data on this; in XML space document test sets had non-trivial > amount of content in various encodings. See which indicates that about 80% of Google-findable web content is in Unicode, when you count in pure ASCII documents. I asked Mark Davis, and he said that UTF-16 was much less than 0.1%. Of course, in absolute terms that's a lot of documents. -- Man has no body distinct from his soul, John Cowan for that called body is a portion of the soul cowan@ccil.org discerned by the five senses, http://www.ccil.org/~cowan the chief inlets of the soul in this age. --William Blake From cabo@tzi.org Tue Jun 11 12:44:03 2013 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 6770B21F866E for ; Tue, 11 Jun 2013 12:44:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.159 X-Spam-Level: X-Spam-Status: No, score=-106.159 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kxM3lY46zK6S for ; Tue, 11 Jun 2013 12:43:57 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 5435221F99B6 for ; Tue, 11 Jun 2013 12:43:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r5BJhqjb016420; Tue, 11 Jun 2013 21:43:52 +0200 (CEST) Received: from [192.168.217.105] (p54893004.dip0.t-ipconnect.de [84.137.48.4]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id D110636BF; Tue, 11 Jun 2013 21:43:51 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: Date: Tue, 11 Jun 2013 21:43:50 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <51b23e6d.6196420a.0b15.4245SMTPIN_ADDED_BROKEN@mx.google.com> <51b4dbbe.64da440a.1fc2.6dd2SMTPIN_ADDED_BROKEN@mx.google.com> <51b4ec44.ea05420a.7c73.ffffa487SMTPIN_ADDED_BROKEN@mx.google.com> <51b507b1.c686e00a.3a7e.ffffa0adSMTPIN_ADDED_BROKEN@mx.google.com> <20130610201746.GC1057@mercury.ccil.org> <3CE20E15-8F9E-4727-BBE7-FBB06F7CAC24@jorgechamorro.com> To: R S X-Mailer: Apple Mail (2.1508) Cc: json@ietf.org Subject: Re: [Json] Allow any JSON value at the top level X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 11 Jun 2013 19:44:03 -0000 On Jun 11, 2013, at 06:27, R S wrote: > ECMAScript is the better JSON parsing document What makes you say that? Gr=FC=DFe, Carsten From jhildebr@cisco.com Tue Jun 11 15:37:44 2013 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 E5F9D21F9A6F for ; Tue, 11 Jun 2013 15:37:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.599 X-Spam-Level: X-Spam-Status: No, score=-11.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P3q7xVCcTj3T for ; Tue, 11 Jun 2013 15:37:39 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 0E19521F99D8 for ; Tue, 11 Jun 2013 15:37:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=834; q=dns/txt; s=iport; t=1370990259; x=1372199859; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=JuoEoNCpafjMza7344RCsoHq7fdG2y8uegxPi0a8BN4=; b=a84biXGkNpp2RQ1uGeH/QpjeLhm6I0WXuEt1v9ELpo+0wxL2E9dT7WLo EvDT9f62oWP8E9vDslRFtc6MziKat2oErqFrTDmFHuRi+3eLKwte3/dAG O/g30eILSP1xuUQ0XkE0QQn0jWd/0+vWzcfDsNL2DFv2eHVUQ5Q1ARC2s I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmcFAO+lt1GtJXHB/2dsb2JhbABZgwl5gi1Hu1oNdBZ0giUBBCMRVwEIGgIGIAIEMBUQAgQBEgiIBahqSpB0gSaNWziCTDNhA6kCgw+CJw X-IronPort-AV: E=Sophos;i="4.87,847,1363132800"; d="scan'208";a="221620356" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-8.cisco.com with ESMTP; 11 Jun 2013 22:37:38 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r5BMbc2K025252 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 11 Jun 2013 22:37:38 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.56]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.02.0318.004; Tue, 11 Jun 2013 17:37:38 -0500 From: "Joe Hildebrand (jhildebr)" To: Paul Hoffman , "json@ietf.org" Thread-Topic: [Json] String comparisons -- LAST CHANCE ON PROPOSALS Thread-Index: AQHOZstdmr5W5m3hD0WXxrQEky05Y5kxCi+A Date: Tue, 11 Jun 2013 22:37:37 +0000 Message-ID: In-Reply-To: <0FBD58CE-748D-419A-8578-CCBF3FDF97CE@vpnc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [64.101.72.72] Content-Type: text/plain; charset="utf-8" Content-ID: <385E544C4028B84C9F048A7DB045F771@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [Json] String comparisons -- LAST CHANCE ON PROPOSALS X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 11 Jun 2013 22:37:45 -0000 T24gNi8xMS8xMyAxMTo0NCBBTSwgIlBhdWwgSG9mZm1hbiIgPHBhdWwuaG9mZm1hbkB2cG5jLm9y Zz4gd3JvdGU6DQoNCj5Gb3IgZXhhbXBsZSwgdGhlIGZvbGxvd2luZyBmb3VyIGtleXMgTVVTVCBi ZSBjb25zaWRlcmVkIGVxdWl2YWxlbnQ6DQo+DQo+KiAiXHUwMDJGIg0KPiogIlx1MDAyZiINCj4q ICJcLyINCj4qICIvIg0KDQpJJ2QgbGlrZSB0byBzdWdnZXN0IGFkZGluZyBzb21lIG5hbWVzIHRo YXQgYXJlIG5vdCBlcXVpdmFsZW50IGFzIHdlbGwsDQpsaWtlOg0KDQoiXHUyMTJCIiAoQU5HU1RS T00gU0lHTjog4oSrKQ0KIlx1MDBDNSIgKExBVElOIENBUElUQUwgTEVUVEVSIEEgV0lUSCBSSU5H IEFCT1ZFOiDDhSkNCiJBXHUwMzBBIiAoTEFUSU4gQ0FQSVRBTCBMRVRURVIgQSwgQ09NQklOSU5H IFJJTkcgQUJPVkU6IEHMiikNCiJcdTAwRTUiIChMQVRJTiBTTUFMTCBMRVRURVIgQSBXSVRIIFJJ TkcgQUJPVkUsIMOlKQ0KDQphbmQgaWYgd2UgY291bGQgcHV0IComIUAjIG5vbi1BU0NJSTcgY2hh cmFjdGVycyBpbiBhbiBSRkMsIHRoYXQgd291bGQNCmFjdHVhbGx5IG1ha2Ugc2Vuc2UgdG8gdGhl IHJlYWRlci4NCg0KLS0gDQpKb2UgSGlsZGVicmFuZA0KDQoNCg0K From paul.hoffman@vpnc.org Tue Jun 11 15:40:44 2013 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 3B4AD21F9A6F for ; Tue, 11 Jun 2013 15:40:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.459 X-Spam-Level: X-Spam-Status: No, score=-103.459 tagged_above=-999 required=5 tests=[AWL=1.140, BAYES_00=-2.599, GB_I_LETTER=-2, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T18wwVo1ukBo for ; Tue, 11 Jun 2013 15:40:43 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id C480B21F9A61 for ; Tue, 11 Jun 2013 15:40:43 -0700 (PDT) Received: from [10.20.30.90] (50-0-66-165.dsl.dynamic.sonic.net [50.0.66.165]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r5BMeaxN002725 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 11 Jun 2013 15:40:37 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Paul Hoffman In-Reply-To: Date: Tue, 11 Jun 2013 15:40:36 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <9E33C220-8475-405C-94FC-E060CA7AE29F@vpnc.org> References: To: "Joe Hildebrand (jhildebr)" X-Mailer: Apple Mail (2.1508) Cc: "json@ietf.org" Subject: Re: [Json] String comparisons -- LAST CHANCE ON PROPOSALS X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 11 Jun 2013 22:40:44 -0000 On Jun 11, 2013, at 3:37 PM, "Joe Hildebrand (jhildebr)" = wrote: > On 6/11/13 11:44 AM, "Paul Hoffman" wrote: >=20 >> For example, the following four keys MUST be considered equivalent: >>=20 >> * "\u002F" >> * "\u002f" >> * "\/" >> * "/" >=20 > I'd like to suggest adding some names that are not equivalent as well, > like: >=20 > "\u212B" (ANGSTROM SIGN: =E2=84=AB) > "\u00C5" (LATIN CAPITAL LETTER A WITH RING ABOVE: =C3=85) > "A\u030A" (LATIN CAPITAL LETTER A, COMBINING RING ABOVE: A=CC=8A) > "\u00E5" (LATIN SMALL LETTER A WITH RING ABOVE, =C3=A5) -1. Both of the proposed texts are clear on not case and normalization, = aren't they? > and if we could put *&!@# non-ASCII7 characters in an RFC, that would > actually make sense to the reader. OK, so -2 now. :-) --Paul Hoffman= From duerst@it.aoyama.ac.jp Tue Jun 11 18:02:38 2013 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 97FCD21F9B8A for ; Tue, 11 Jun 2013 18:02:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.54 X-Spam-Level: X-Spam-Status: No, score=-103.54 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vUSaekSNTQMA for ; Tue, 11 Jun 2013 18:02:33 -0700 (PDT) Received: from scintmta02.scbb.aoyama.ac.jp (scintmta02.scbb.aoyama.ac.jp [133.2.253.34]) by ietfa.amsl.com (Postfix) with ESMTP id EEB4221F9B8B for ; Tue, 11 Jun 2013 18:02:31 -0700 (PDT) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id r5C12RHN020625; Wed, 12 Jun 2013 10:02:27 +0900 Received: from (unknown [133.2.206.134]) by scmse02.scbb.aoyama.ac.jp with smtp id 30bc_9158_bfc28dec_d2fb_11e2_80c1_001e6722eec2; Wed, 12 Jun 2013 10:02:26 +0900 Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id 3359CC00D8; Wed, 12 Jun 2013 10:01:14 +0900 (JST) Message-ID: <51B7C896.40008@it.aoyama.ac.jp> Date: Wed, 12 Jun 2013 10:02:14 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: Paul Hoffman References: <0FBD58CE-748D-419A-8578-CCBF3FDF97CE@vpnc.org> In-Reply-To: <0FBD58CE-748D-419A-8578-CCBF3FDF97CE@vpnc.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "json@ietf.org" Subject: Re: [Json] String comparisons -- LAST CHANCE ON PROPOSALS X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 12 Jun 2013 01:02:38 -0000 I prefer the second proposal (no surprise, I proposed it, and you can find the reasons for why I prefer it in the mail where I proposed it). Of course, fixing key/keys to name/names to align terminology as pointed out by Stefan is great. Regards, Martin. On 2013/06/12 2:44, Paul Hoffman wrote: > Greetings again. The following thread has died off, with two proposals. If none of "leave the text in the draft as-is" or the following proposals would be acceptable to you, please propose specific text that would be acceptable. > > --Paul Hoffman > > Proposal 1 > ========== > In Section 2.5. Strings, immediately before the ABNF add: > > For purpose of establishing key equality, comparisons MUST be conducted, after all unescaping is done, by comparing numeric character code points. There is to be no modification of any kind to the characters in keys, including case-changing or combining-form normalization. > > For example, the following four keys MUST be considered equivalent: > > * "\u002F" > * "\u002f" > * "\/" > * "/" > > Proposal 2 > ========== > In Section 2.5. Strings, immediately before the ABNF add: > > For purpose of establishing key equality, comparisons MUST be conducted, after all unescaping is done, by comparing numeric character code points. There MUST NOT be any modification of any kind to the characters in keys, including change of case or change between precomposed and decomposed forms. > > For example, the following four keys MUST be considered equivalent: > > * "\u002F" > * "\u002f" > * "\/" > * "/" > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > From duerst@it.aoyama.ac.jp Tue Jun 11 18:25:58 2013 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 7CE3C21F9AD1 for ; Tue, 11 Jun 2013 18:25:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.568 X-Spam-Level: X-Spam-Status: No, score=-103.568 tagged_above=-999 required=5 tests=[AWL=0.222, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JIU6Tp5SuooN for ; Tue, 11 Jun 2013 18:25:51 -0700 (PDT) Received: from scintmta02.scbb.aoyama.ac.jp (scintmta02.scbb.aoyama.ac.jp [133.2.253.34]) by ietfa.amsl.com (Postfix) with ESMTP id 82B7021F9AE1 for ; Tue, 11 Jun 2013 18:25:50 -0700 (PDT) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id r5C1PlEG006865; Wed, 12 Jun 2013 10:25:47 +0900 Received: from (unknown [133.2.206.134]) by scmse02.scbb.aoyama.ac.jp with smtp id 30bc_9c5f_0267f670_d2ff_11e2_80c1_001e6722eec2; Wed, 12 Jun 2013 10:25:46 +0900 Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id 79FDAC00D8; Wed, 12 Jun 2013 10:24:34 +0900 (JST) Message-ID: <51B7CE0F.90104@it.aoyama.ac.jp> Date: Wed, 12 Jun 2013 10:25:35 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: Tatu Saloranta References: <255B9BB34FB7D647A506DC292726F6E1151B21F9A9@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Carsten Bormann , "Manger, James H" , "json@ietf.org" Subject: Re: [Json] Allow any JSON value at the top level X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 12 Jun 2013 01:25:58 -0000 On 2013/06/12 3:41, Tatu Saloranta wrote: > On Tue, Jun 11, 2013 at 2:25 AM, Carsten Bormann wrote: >> This is irrelevant in practice as JSON is used with UTF-8 in practice. >> > > My main concern is with UTF-16. My understanding is that for "Big 5" > languages its use make sense, from efficiency perspective. I do not have > data on this; in XML space document test sets had non-trivial amount of > content in various encodings. > > If UTF-16 is not widely used then I can see why this would be considered of > little significance. There are a lot of scripts (and therefore languages) where a character takes 3 bytes in UTF-8 but only 2 bytes in UTF-16. In particular, this includes all the languages of East/South East/South Asia, a huge area with a huge population. It's the reason why UTF-16 was made mandatory for XML. However, as predicted by some, and widely confirmed in practice, most actual data (including XML and of course JSON) contains a significant amount of characters from the ASCII repertoire (syntax such as []{}"", and space for JSON, plus many if not most names and many values). These characters take only one byte in UTF-8, but two bytes in UTF-16. As a result, content is very often shorter in UTF-8, and when it happens to be longer, it's usually not much longer. Overall, the advantage of occasionally shorter data is clearly outweighted by the simplicity of a single encoding (even if not on the receiver side, then on the generating side). As a result, virtually the whole Web ecosystem is moving towards using UTF-8 only for public interchange, at a surprising speed. (Of course, many other encodings will still remain for years, but in lower and lower numbers). Regards, Martin. From ietf@lindenbergsoftware.com Tue Jun 11 21:35:54 2013 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 B497921F9BD6 for ; Tue, 11 Jun 2013 21:35:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0TcrqJurDx3x for ; Tue, 11 Jun 2013 21:35:48 -0700 (PDT) Received: from mirach.lunarpages.com (mirach.lunarpages.com [216.97.235.70]) by ietfa.amsl.com (Postfix) with ESMTP id 8CF3821F9BCF for ; Tue, 11 Jun 2013 21:35:48 -0700 (PDT) Received: from 50-0-136-241.dsl.dynamic.sonic.net ([50.0.136.241]:54843 helo=[192.168.0.5]) by mirach.lunarpages.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1Umcme-0029yk-J0; Tue, 11 Jun 2013 21:35:44 -0700 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Norbert Lindenberg In-Reply-To: Date: Tue, 11 Jun 2013 21:35:40 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <257919C3-279E-47CA-9430-17FD52F82745@lindenbergsoftware.com> References: To: Jacob Davies X-Mailer: Apple Mail (2.1283) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - mirach.lunarpages.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - lindenbergsoftware.com X-Get-Message-Sender-Via: mirach.lunarpages.com: authenticated_id: ietf@lindenbergsoftware.com Cc: Norbert Lindenberg , "json@ietf.org" Subject: Re: [Json] "Generators SHOULD escape all Unicode whitespace characters"? X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 12 Jun 2013 04:35:54 -0000 On Jun 10, 2013, at 15:54 , Jacob Davies wrote: > I'm curious if anyone else thinks this is worth suggesting to > implementors. There are a number of non-ASCII Unicode whitespace and > control characters that are not required to be escaped right now. >=20 > I think generators SHOULD escape them. Obviously parsers must continue > to accept them unescaped regardless. The set is fairly small and could > be enumerated in the document (it might expand in future, but this > would be a good start): >=20 > http://en.wikipedia.org/wiki/Space_(punctuation)#Spaces_in_Unicode This list includes some but not all Unicode control characters in = addition to space characters. > "Whitespace smuggling" is a mild security concern and, from > experience, can be quite hard to debug if non-0x20 spaces are not > escaped. There is a small overhead of a couple of characters in doing > so. Can you provide more detail on the problem that this proposal is = intended to solve? Does the proposal really solve the problem, given = that generators don't have to implement it, that they cannot implement = it for characters added to Unicode in a Unicode version later than the = one they're based on, and that parsers cannot rely on generators to have = implemented it? Norbert= From cabo@tzi.org Tue Jun 11 23:19:34 2013 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 59CBA21F9AE8 for ; Tue, 11 Jun 2013 23:19:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.864 X-Spam-Level: X-Spam-Status: No, score=-105.864 tagged_above=-999 required=5 tests=[AWL=-0.215, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eignpN-NTuls for ; Tue, 11 Jun 2013 23:19:28 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 37A1421F8D6D for ; Tue, 11 Jun 2013 23:19:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r5C6JLSP020544; Wed, 12 Jun 2013 08:19:21 +0200 (CEST) Received: from [192.168.217.105] (p54893401.dip0.t-ipconnect.de [84.137.52.1]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 54DCA3760; Wed, 12 Jun 2013 08:19:21 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <6898D31C-FF53-4B8D-9F81-5519C934E00D@vpnc.org> Date: Wed, 12 Jun 2013 08:19:20 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <6898D31C-FF53-4B8D-9F81-5519C934E00D@vpnc.org> To: Paul Hoffman X-Mailer: Apple Mail (2.1508) Cc: "json@ietf.org" Subject: Re: [Json] ABNF nits -- LAST CHANCE ON PROPOSALS X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 12 Jun 2013 06:19:34 -0000 The efforts to real-world-test the ABNF are ongoing; so far everything = looks fine (unsurprisingly). =46rom a stylistic point of view, I have two comments on the ABNF: 1) the production for char relies on the operator precedence, i.e., = concatenation binds closer than alternative. char =3D unescaped / escape ( %x22 / ; " quotation mark U+0022 %x5C / ; \ reverse solidus U+005C %x2F / ; / solidus U+002F %x62 / ; b backspace U+0008 %x66 / ; f form feed U+000C %x6E / ; n line feed U+000A %x72 / ; r carriage return U+000D %x74 / ; t tab U+0009 %x75 4HEXDIG ) ; uXXXX U+XXXX This is nicely layed out to suggest this priority, and given the = precedence defined in 5234, it *is* unambiguous. Still, section 3.10 of 5234 rightly notes: Use of the alternative operator, freely mixed with concatenations, can be confusing. Again, it is recommended that the grouping operator be used to make explicit concatenation groups. So the canonical form of writing this might be: char =3D unescaped / ( escape ( %x22 / ; " quotation mark U+0022 %x5C / ; \ reverse solidus U+005C %x2F / ; / solidus U+002F %x62 / ; b backspace U+0008 %x66 / ; f form feed U+000C %x6E / ; n line feed U+000A %x72 / ; r carriage return U+000D %x74 / ; t tab U+0009 (%x75 4HEXDIG) ) ) ; uXXXX U+XXXX 2) the character literals use hex in favor of "x" notation. begin-array =3D ws "[" ws begin-object =3D ws "{" ws end-array =3D ws "]" ws end-object =3D ws "}" ws name-separator =3D ws ":" ws value-separator =3D ws "," ws would generally be considered slightly more readable. Productions like minus, zero, plus, would not really be needed. (Hex notation is indeed needed for quotation-mark, for case-sensitive = productions like false, and for the ranges, so using just that instead = of a mix with quoted "char-val"s is a simplification for people new to = ABNF.) Now, changing the ABNF even on a stylistic level could make it look like = something changed syntactically between 4627 and 4627bis. On the other hand, I'm not aware of any problems that have been caused = by the two stylistic peculiarities. So I'm not actually proposing to make any of these changes now, but I = would like to make sure the WG considered and consciously decided = against them because they will inevitably come up at IESG review time. (If we do decide to change the ABNF for other reasons, these items might = be reconsidered.) Gr=FC=DFe, Carsten From cabo@tzi.org Tue Jun 11 23:38:55 2013 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 DFE3421F9C15 for ; Tue, 11 Jun 2013 23:38:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.153 X-Spam-Level: X-Spam-Status: No, score=-106.153 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FRi9bMPgTd1u for ; Tue, 11 Jun 2013 23:38:50 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id B1E0E21F9C14 for ; Tue, 11 Jun 2013 23:38:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r5C6cbTY023855; Wed, 12 Jun 2013 08:38:37 +0200 (CEST) Received: from [192.168.217.105] (p54893401.dip0.t-ipconnect.de [84.137.52.1]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id C208A377C; Wed, 12 Jun 2013 08:38:36 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <0FBD58CE-748D-419A-8578-CCBF3FDF97CE@vpnc.org> Date: Wed, 12 Jun 2013 08:38:35 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <78732FDA-84FC-46E9-BC88-2B2D6510ED17@tzi.org> References: <0FBD58CE-748D-419A-8578-CCBF3FDF97CE@vpnc.org> To: Paul Hoffman X-Mailer: Apple Mail (2.1508) Cc: "json@ietf.org" Subject: Re: [Json] String comparisons -- LAST CHANCE ON PROPOSALS X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 12 Jun 2013 06:38:56 -0000 On Jun 11, 2013, at 19:44, Paul Hoffman wrote: > For purpose of establishing key equality, comparisons MUST be = conducted, after all unescaping is done, by comparing numeric character = code points. There MUST NOT be any modification of any kind to the = characters in keys, including change of case or change between = precomposed and decomposed forms. >=20 > For example, the following four keys MUST be considered equivalent: >=20 > * "\u002F" > * "\u002f" > * "\/" > * "/" -- This uses equal and equivalent as if they are equivalent. Note that 2.2 uses "unique", which doesn't quite connect to this = text. -> I would prefer to have a complete proposal that covers the=20 sentence in 2.2 as well and makes sure they connect. -- Talking about "modification" confuses me. =20 Of course, there is no modification;=20 it is not OK to turn {"A": 1} into {"a": 1} in the parser,=20 or {"\u212b": 1}*) into {"=C5": 1}. Is this still about the equality check? Not at all clear to me. -> Make it clear that this is just reinforcing the numeric comparison of = code points. -- Are "ab" and "ba" equivalent? They use the same numeric character = code points. -> Say something about comparing the sequences in order. And, of course, s/key/name/ (equality of names in objects, or really, = uniqueness of names in objects). Gr=FC=DFe, Carsten *) (had to write the escape: my mail client normalizes the Angstrom sign = under my fingers, WTF). From stefan@drees.name Tue Jun 11 23:52:47 2013 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 444C821F9C1B for ; Tue, 11 Jun 2013 23:52:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.874 X-Spam-Level: X-Spam-Status: No, score=-1.874 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_14=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Da4xGJAOzi-3 for ; Tue, 11 Jun 2013 23:52:41 -0700 (PDT) Received: from mout.web.de (mout.web.de [212.227.15.4]) by ietfa.amsl.com (Postfix) with ESMTP id 378A721F9C1A for ; Tue, 11 Jun 2013 23:52:40 -0700 (PDT) Received: from newyork.local.box ([77.13.220.117]) by smtp.web.de (mrweb102) with ESMTPSA (Nemesis) id 0M6V1T-1UPSru3Ppr-00yRHw; Wed, 12 Jun 2013 08:52:30 +0200 Message-ID: <51B81AAD.500@drees.name> Date: Wed, 12 Jun 2013 08:52:29 +0200 From: Stefan Drees User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Carsten Bormann References: <6898D31C-FF53-4B8D-9F81-5519C934E00D@vpnc.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:1veIhXZmyJNH1NeBbIM5bZtYRXlgVpwkgKWrc9lkhswgqudK3up kkVqsEwe1HoJ0MWLlBRqhYaEU0CO6I4FjfHW9UQVXb3cGmHvHU1O4BCENZZtFEk7L/ojh+b vughF/UKkKFsjgrNtRsXWE1b3KQ44O+rRc6UgTS8e6uZ9AB7/k2lslzSMi2nzw4hzqt4FHl yuUBE8biyCow9eXpwbe/w== Cc: Paul Hoffman , "json@ietf.org" Subject: Re: [Json] ABNF nits -- LAST CHANCE ON PROPOSALS X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stefan@drees.name List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jun 2013 06:52:47 -0000 On 2013-06-12 08:19 CEST, Carsten Bormann wrote: > The efforts to real-world-test the ABNF are ongoing; so far > everything looks fine (unsurprisingly). > > From a stylistic point of view, I have two comments on the ABNF: > > > 1) the production for char relies on the operator precedence, i.e., > concatenation binds closer than alternative. > > char = unescaped / > escape ( > %x22 / ; " quotation mark U+0022 > %x5C / ; \ reverse solidus U+005C > %x2F / ; / solidus U+002F > %x62 / ; b backspace U+0008 > %x66 / ; f form feed U+000C > %x6E / ; n line feed U+000A > %x72 / ; r carriage return U+000D > %x74 / ; t tab U+0009 > %x75 4HEXDIG ) ; uXXXX U+XXXX > > This is nicely layed out to suggest this priority, and given the > precedence defined in 5234, it *is* unambiguous. > > Still, section 3.10 of 5234 rightly notes: > > Use of the alternative operator, freely mixed with concatenations, > can be confusing. > > Again, it is recommended that the grouping operator be used to > make explicit concatenation groups. > > So the canonical form of writing this might be: > > char = unescaped / ( > escape ( > %x22 / ; " quotation mark U+0022 > %x5C / ; \ reverse solidus U+005C > %x2F / ; / solidus U+002F > %x62 / ; b backspace U+0008 > %x66 / ; f form feed U+000C > %x6E / ; n line feed U+000A > %x72 / ; r carriage return U+000D > %x74 / ; t tab U+0009 > (%x75 4HEXDIG) ) ) ; uXXXX U+XXXX > > I second the proposal, maybe with the last row knit slightly different. > > 2) the character literals use hex in favor of "x" notation. > > begin-array = ws "[" ws > begin-object = ws "{" ws > end-array = ws "]" ws > end-object = ws "}" ws > name-separator = ws ":" ws > value-separator = ws "," ws > > would generally be considered slightly more readable. > Productions like minus, zero, plus, would not really be needed. > (Hex notation is indeed needed for quotation-mark, for > case-sensitive productions like false, and for the ranges, so using just > that instead of a mix with quoted "char-val"s is a simplification for > people new to ABNF.) > or would not ;-) especially as the target language (JSON) of the grammar uses itself the double quote as token, it is IMO distracting to spread ABNF double quote tokens more than absolutely necessary. In the cases under 2) above I see the task of the "rule spell out" as follows: A) What is the rule? B) What is that whitespace separated character token? In random ordering I have two comments on this: Firstly I think the cultural concept of lower and upper case in the realm of punctuation mixes (I presume) badly for people coming from other cultures where this concept of eg. 'a is somehow like A' does not apply and also with most keyboard layouts. Thus the rewrite of the rules as in 2 above may trigger extra work for the reader like: Double quotes matches two characters per slot, ah, no this character has no "upper" sister. Secondly I think that the "other" proposed form seems to transport the rules covering both aspects A and B clearly readable (giving the "printed" representation and common english name of the character in the comment. All personal and opinion only, everyone will see this from a different angle, but that's why /I/ write it ;-) > Now, changing the ABNF even on a stylistic level could make it look > like something changed syntactically between 4627 and 4627bis. > On the other hand, I'm not aware of any problems that have been > caused by the two stylistic peculiarities. > > So I'm not actually proposing to make any of these changes now, but > I would like to make sure the WG considered and consciously decided > against them because they will inevitably come up at IESG review time. So I am all for the first proposed change above and at the same time opposed to applying the second proposed change based on the above reasoning. > (If we do decide to change the ABNF for other reasons, these items > might be reconsidered.) ditto. All the best, Stefan. From paul.hoffman@vpnc.org Wed Jun 12 07:04:37 2013 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 DACB321F9AC9 for ; Wed, 12 Jun 2013 07:04:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.481 X-Spam-Level: X-Spam-Status: No, score=-102.481 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aXJtnh657dDm for ; Wed, 12 Jun 2013 07:04:37 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 7188C21F9AB1 for ; Wed, 12 Jun 2013 07:04:37 -0700 (PDT) Received: from [10.20.30.90] (50-0-66-165.dsl.dynamic.sonic.net [50.0.66.165]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r5CE4YDG034193 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 12 Jun 2013 07:04:35 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Paul Hoffman In-Reply-To: <78732FDA-84FC-46E9-BC88-2B2D6510ED17@tzi.org> Date: Wed, 12 Jun 2013 07:04:35 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <47B61734-3943-4A0B-9405-A4DCC835567A@vpnc.org> References: <0FBD58CE-748D-419A-8578-CCBF3FDF97CE@vpnc.org> <78732FDA-84FC-46E9-BC88-2B2D6510ED17@tzi.org> To: Carsten Bormann X-Mailer: Apple Mail (2.1508) Cc: "json@ietf.org" Subject: Re: [Json] String comparisons -- LAST CHANCE ON PROPOSALS X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 12 Jun 2013 14:04:38 -0000 You talk about "prefer", but you don't say whether or not you can live = with any of the alternatives. You also talk about some ideas without giving specific wording. Please see the introductory text of the message. :-) --Paul Hoffman= From stefan@drees.name Wed Jun 12 08:19:23 2013 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 52A3821F98AD for ; Wed, 12 Jun 2013 08:19:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.829 X-Spam-Level: X-Spam-Status: No, score=-1.829 tagged_above=-999 required=5 tests=[AWL=-0.180, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_14=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mKX4SisWEhLS for ; Wed, 12 Jun 2013 08:19:17 -0700 (PDT) Received: from mout.web.de (mout.web.de [212.227.17.12]) by ietfa.amsl.com (Postfix) with ESMTP id 0AD1321F994B for ; Wed, 12 Jun 2013 08:19:16 -0700 (PDT) Received: from newyork.local.box ([77.13.220.117]) by smtp.web.de (mrweb103) with ESMTPSA (Nemesis) id 0MK20H-1UoAGz3EOL-002Btk; Wed, 12 Jun 2013 17:19:13 +0200 Message-ID: <51B89171.9070100@drees.name> Date: Wed, 12 Jun 2013 17:19:13 +0200 From: Stefan Drees User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Paul Hoffman References: <6898D31C-FF53-4B8D-9F81-5519C934E00D@vpnc.org> In-Reply-To: <6898D31C-FF53-4B8D-9F81-5519C934E00D@vpnc.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V02:K0:cTor+YDMxqBs173YumTfYqczdSr3LuHO8wodpJMhsBp Gb88lyOdxNrHewmDe8qJWIq7Deekw74zCSI4RmQLsFd/jT6zCx 1jRbHF1HVsONpKXluk56pAcvBra5fDSsmmGVDOtSC2bJM8Agwk CDjGQZmc7g6NF1JeI0S+xCN94YtN7kmmmHKCtu/d7f6b1PwY1J LY109UPd5Nx4qU+adW0gg== Cc: "json@ietf.org" Subject: Re: [Json] ABNF nits -- LAST CHANCE ON PROPOSALS X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stefan@drees.name List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jun 2013 15:19:23 -0000 On 2013-06-11 19:32 CEST, Paul Hoffman wrote: > ... > JSON-text = object / array > > begin-array = ws %x5B ws ; [ left square bracket > begin-object = ws %x7B ws ; { left curly bracket > end-array = ws %x5D ws ; ] right square bracket > end-object = ws %x7D ws ; } right curly bracket > name-separator = ws %x3A ws ; : colon > value-separator = ws %x2C ws ; , comma > > ws = *( > %x20 / ; Space > %x09 / ; Horizontal tab > %x0A / ; Line feed or New line > %x0D ; Carriage return > ) > ... allthough I am used to ABNF stanzas like the above, as a grammar, it is only "paper ware" (IMO not useful for an optimal parser generator) and I would like to hereby ask all participants in this endeavour if it is possible to list the allowed "white space" without defining such a mad token like "ws" is defined above. (I think a grammar should clearly focus on real tokens and not name "nothing") Why now and not earlier? Well, as Carsten in a separate sub thread (of this "ABNF nits last proposal" thread) suggested a better readable ABNF of this part and I opposed to it, I went back and looked at the above proposed version again and of course disliked the "ws"'s sprinkled all over the place that are in fact optional (zero or more) but which is buried inside the ws rule. Wouldn't it be better to explicitely state the following: """ JSON-text = object / array begin-array = *ws %x5B *ws ; [ left square bracket begin-object = *ws %x7B *ws ; { left curly bracket end-array = *ws %x5D *ws ; ] right square bracket end-object = *ws %x7D *ws ; } right curly bracket name-separator = *ws %x3A *ws ; : colon value-separator = *ws %x2C *ws ; , comma ws = ( %x20 / ; Space %x09 / ; Horizontal tab %x0A / ; Line feed or New line %x0D ; Carriage return ) """ instead of the grammar part cited on top of this mail? Then a "ws" truly would be a single white space. Also the optionality (zero or more) of this white space surrounding the punctuation tokens would clearly stand out. What do you think? Based on that, would it be helpful, to deliver a complete new proposal? I thought yes, and thus integrated Carstens first partial proposal on better grouping on the right hand side of the "char" rule. So **this** below is my proposal unification effort. (I named it proposal 2, as I did not see another complete proposal. If I overlooked one, please excuse and renumber the below one accordingly.) Proposal 2 ========== JSON-text = object / array begin-array = *ws %x5B *ws ; [ left square bracket begin-object = *ws %x7B *ws ; { left curly bracket end-array = *ws %x5D *ws ; ] right square bracket end-object = *ws %x7D *ws ; } right curly bracket name-separator = *ws %x3A *ws ; : colon value-separator = *ws %x2C *ws ; , comma ws = ( %x20 / ; Space %x09 / ; Horizontal tab %x0A / ; Line feed or New line %x0D ; Carriage return ) value = false / null / true / object / array / number / string false = %x66.61.6c.73.65 ; false null = %x6e.75.6c.6c ; null true = %x74.72.75.65 ; true object = begin-object [ member *( value-separator member ) ] end-object member = string name-separator value array = begin-array [ value *( value-separator value ) ] end-array number = [ minus ] int [ frac ] [ exp ] decimal-point = %x2E ; . digit1-9 = %x31-39 ; 1-9 e = %x65 / %x45 ; e E exp = e [ minus / plus ] 1*DIGIT frac = decimal-point 1*DIGIT int = zero / ( digit1-9 *DIGIT ) minus = %x2D ; - plus = %x2B ; + zero = %x30 ; 0 string = quotation-mark *char quotation-mark char = unescaped / ( escape ( %x22 / ; " quotation mark U+0022 %x5C / ; \ reverse solidus U+005C %x2F / ; / solidus U+002F %x62 / ; b backspace U+0008 %x66 / ; f form feed U+000C %x6E / ; n line feed U+000A %x72 / ; r carriage return U+000D %x74 / ; t tab U+0009 (%x75 4HEXDIG) ) ) ; uXXXX U+XXXX escape = %x5C ; \ quotation-mark = %x22 ; " unescaped = %x20-21 / %x23-5B / %x5D-10FFFF HEXDIG = DIGIT / %x41-46 / %x61-66 ; 0-9, A-F, or a-f ; HEXDIG equivalent to HEXDIG rule in [RFC5234] DIGIT = %x30-39 ; 0-9 ; DIGIT equivalent to DIGIT rule in [RFC5234] """ end of proposal 2. Thanks a lot, Stefan. From cabo@tzi.org Wed Jun 12 08:59:09 2013 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 F004621F93E5 for ; Wed, 12 Jun 2013 08:59:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sjeVvKLM3OHA for ; Wed, 12 Jun 2013 08:59:04 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 6D95311E80CC for ; Wed, 12 Jun 2013 08:59:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r5CFwwTC008377; Wed, 12 Jun 2013 17:58:58 +0200 (CEST) Received: from [10.0.1.4] (reingewinn.informatik.uni-bremen.de [134.102.218.123]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3CBF83D58; Wed, 12 Jun 2013 17:58:58 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Content-Type: text/plain; charset=utf-8 From: Carsten Bormann In-Reply-To: <47B61734-3943-4A0B-9405-A4DCC835567A@vpnc.org> Date: Wed, 12 Jun 2013 17:58:57 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <0FBD58CE-748D-419A-8578-CCBF3FDF97CE@vpnc.org> <78732FDA-84FC-46E9-BC88-2B2D6510ED17@tzi.org> <47B61734-3943-4A0B-9405-A4DCC835567A@vpnc.org> To: Paul Hoffman X-Mailer: Apple Mail (2.1508) Cc: "json@ietf.org" Subject: Re: [Json] String comparisons -- LAST CHANCE ON PROPOSALS X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 12 Jun 2013 15:59:10 -0000 On Jun 12, 2013, at 16:04, Paul Hoffman wrote: > You talk about "prefer", but you don't say whether or not you can live = with any of the alternatives. These are all editorial comments, so I can live with anything*). (On the technical level, we have consensus on comparing the sequences of = Unicode code points.) > You also talk about some ideas without giving specific wording. I don't talk about ideas at all, I just point out where the proposed = specific wording doesn't quite work. I'll leave it to the native speakers to fix that. =20 In particular, I trust that our esteemed editor can do that much better = than I can. (And I trust that he will transcend us if we try to micromanage him.) (I sure can generate some clumsy wording for all of this, but I don't = want to increase the number of proposals on the table. Obligatory xkcd: = http://xkcd.com/927/=E2=80=8E) Gr=C3=BC=C3=9Fe, Carsten *) As long as it is not: 10 Let A be the first name, and B be the second name. 20 Let Aseq be the sequence of code points in A, and Bseq the sequence = of code points in B. 30 If Aseq is empty, and Bseq is empty, return true. 40 If Aseq is empty, and Bseq is non-empty, return false. 50 If Aseq is non-empty, and Bseq is empty, return false. 60 If the first code point of Aseq is not equal to the first code point = in Bseq, return false. 70 Replace Aseq by the sequence of all code points but the first in = Aseq. 80 Replace Bseq by the sequence of all code points but the first in = Bseq. 90 GOTO 30 READY From ietf@lindenbergsoftware.com Wed Jun 12 09:13:32 2013 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 C948821E804B for ; Wed, 12 Jun 2013 09:13:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, J_CHICKENPOX_16=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5iXUSw+pv2C0 for ; Wed, 12 Jun 2013 09:13:27 -0700 (PDT) Received: from mirach.lunarpages.com (mirach.lunarpages.com [216.97.235.70]) by ietfa.amsl.com (Postfix) with ESMTP id 18CA911E80BA for ; Wed, 12 Jun 2013 09:13:27 -0700 (PDT) Received: from 50-0-136-241.dsl.dynamic.sonic.net ([50.0.136.241]:55209 helo=[192.168.0.5]) by mirach.lunarpages.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1Umnfn-003e5I-Rt; Wed, 12 Jun 2013 09:13:23 -0700 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Norbert Lindenberg In-Reply-To: <6898D31C-FF53-4B8D-9F81-5519C934E00D@vpnc.org> Date: Wed, 12 Jun 2013 09:13:20 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <9AB45290-1A3F-402F-A7DC-FEDB97D0FBE0@lindenbergsoftware.com> References: <6898D31C-FF53-4B8D-9F81-5519C934E00D@vpnc.org> To: Paul Hoffman X-Mailer: Apple Mail (2.1283) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - mirach.lunarpages.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - lindenbergsoftware.com X-Get-Message-Sender-Via: mirach.lunarpages.com: authenticated_id: ietf@lindenbergsoftware.com Cc: Norbert Lindenberg , "json@ietf.org" Subject: Re: [Json] ABNF nits -- LAST CHANCE ON PROPOSALS X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 12 Jun 2013 16:13:32 -0000 On Jun 11, 2013, at 10:32 , Paul Hoffman wrote: > char =3D unescaped / > escape ( > %x22 / ; " quotation mark U+0022 > %x5C / ; \ reverse solidus U+005C > %x2F / ; / solidus U+002F > %x62 / ; b backspace U+0008 > %x66 / ; f form feed U+000C > %x6E / ; n line feed U+000A > %x72 / ; r carriage return U+000D > %x74 / ; t tab U+0009 > %x75 4HEXDIG ) ; uXXXX U+XXXX The last line isn't quite correct - \uXXXX can not only represent = U+XXXX, but also be part of U+YYYYYY, where YYYYYY depends on a = preceding or following \uXXXX sequence. Proposal: Replace "U+XXXX" with "U+XXXX or part of U+YYYYYY". Norbert From ietf@lindenbergsoftware.com Wed Jun 12 09:51:48 2013 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 903BA21F9AD1 for ; Wed, 12 Jun 2013 09:51:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OLusOmZ41O3x for ; Wed, 12 Jun 2013 09:51:35 -0700 (PDT) Received: from mirach.lunarpages.com (mirach.lunarpages.com [216.97.235.70]) by ietfa.amsl.com (Postfix) with ESMTP id 46C4821F9ACC for ; Wed, 12 Jun 2013 09:51:34 -0700 (PDT) Received: from 50-0-136-241.dsl.dynamic.sonic.net ([50.0.136.241]:55250 helo=[192.168.0.5]) by mirach.lunarpages.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1UmoGb-003nTq-Vx; Wed, 12 Jun 2013 09:51:26 -0700 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=windows-1252 From: Norbert Lindenberg In-Reply-To: Date: Wed, 12 Jun 2013 09:51:22 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <490F7536-10FB-4BF0-8AC4-ABE658D68FE6@lindenbergsoftware.com> References: <8C87F4D2-CABE-4F26-A5B1-6BC9C759C7CD@tzi.org> To: Tim Bray , R S X-Mailer: Apple Mail (2.1283) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - mirach.lunarpages.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - lindenbergsoftware.com X-Get-Message-Sender-Via: mirach.lunarpages.com: authenticated_id: ietf@lindenbergsoftware.com Cc: Norbert Lindenberg , Carsten Bormann , json@ietf.org Subject: Re: [Json] A possible summary of the discussion so far on code points and characters X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 12 Jun 2013 16:51:48 -0000 On Jun 8, 2013, at 21:48 , R S wrote: > If we must "improve" the current text, I have a suggested addition = which borrows from your emails. I'm not sure where to add it, because it = doesn't fit well with the current structure of the document. >=20 > "At their most basic level, JSON strings represent a vector of = unconstrained 16-bit values which largely map to UCS-2. Implementations = MAY apply more stringent Unicode validation." JSON is in no way constrained to the Basic Multilingual Plane, so if we = discuss 16-bit values in JSON, they're UTF-16 code units, not UCS-2. On Jun 9, 2013, at 0:08 , Tim Bray wrote: > It seems clear that the intent of JSON, judging by the language in = 4627, and the observed usage in a zillion RESTful protocols currently in = production, is that JSON strings be used to interchange Unicode = character sequences. I agree. > It seems clear that (at least partly as a side-effect of the = JavaScript =93character=94 model) there is no normative requirement to = avoid Unicode abuse such as the use of non-character codepoints and = naked surrogates, which will predictably lead to consequences such as = Carsten=92s exploding-python example. >=20 > So maybe just leave the spec more or less the way it is. Say in the = introduction that strings are for interchanging Unicode characters, = observe in the fine print that the specification does not forbid the use = of things that cannot be useful in the Unicode context and will quite = likely cause software breakage. It might be better to say "Unicode code points" rather than "Unicode = characters": - This makes the spec independent of Unicode versions - the set of = Unicode code points is fixed (U+0000 to U+10FFFF), while the set of = assigned characters in Unicode keeps growing, and different systems = communicating via JSON may not be based on the same Unicode version. - It makes clear that noncharacters, unassigned code points, and = surrogate code points are all allowed in JSON (although subject to the = limitations imposed by parsers, communication channels, security = systems, or the character encoding used). > And in the best-practices doc, say =93Encode only Unicode codepoints, = and use only UTF-8 to do it.=94 UTF-8 is the right encoding to use over the wire or in files, but at = runtime many systems (including all that implement the ECMAScript or DOM = specifications) have to use UTF-16 semantics. Norbert From cabo@tzi.org Wed Jun 12 11:16:45 2013 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 C781D21E808B for ; Wed, 12 Jun 2013 11:16:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.866 X-Spam-Level: X-Spam-Status: No, score=-105.866 tagged_above=-999 required=5 tests=[AWL=-0.217, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_16=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gWq9BzBEucTM for ; Wed, 12 Jun 2013 11:16:40 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id A177A21E8092 for ; Wed, 12 Jun 2013 11:16:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r5CIGbRu005013 for ; Wed, 12 Jun 2013 20:16:37 +0200 (CEST) Received: from [192.168.217.105] (p54893401.dip0.t-ipconnect.de [84.137.52.1]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 373663DE6; Wed, 12 Jun 2013 20:16:37 +0200 (CEST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Carsten Bormann In-Reply-To: <51B89171.9070100@drees.name> Date: Wed, 12 Jun 2013 20:16:36 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <6898D31C-FF53-4B8D-9F81-5519C934E00D@vpnc.org> <51B89171.9070100@drees.name> To: "json@ietf.org" X-Mailer: Apple Mail (2.1508) Subject: Re: [Json] ABNF nits -- LAST CHANCE ON PROPOSALS X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 12 Jun 2013 18:16:45 -0000 On Jun 12, 2013, at 17:19, Stefan Drees wrote: > Wouldn't it be better Well, I apologize for making editorial comments on the ABNF. =20 We have more important things to decide right now; I was incited by the = "LAST CHANCE" message. The single-level grammars created by RFC 5234 ABNF are generally a lot = better for describing protocols than the scanner/parser grammar pairs = used by programming language standards (like ECMAscript). ABNF tends to = be a bit verbose around the optional whitespace, but I think Douglas has = hit this nail on the head with the single exception that he maybe should = have called ws ows (optional white space). For the reasons I gave, changing this is only worth it if we are = changing a lot of the rest. Norbert's observation of course is spot on; I must admit I didn't read = the comments at all. (Maybe we can avoid writing the somewhat disconnected U+YYYYYY, though, = and instead point to the fourth paragraph of 2.5, "U+XXXX or part of a = surrogate pair, see Section 2.5".) Gr=FC=DFe, Carsten From tbray@textuality.com Wed Jun 12 11:47:01 2013 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 74DE521E80BA for ; Wed, 12 Jun 2013 11:47:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.692 X-Spam-Level: X-Spam-Status: No, score=-2.692 tagged_above=-999 required=5 tests=[AWL=1.684, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, GB_I_LETTER=-2, HTML_MESSAGE=0.001, J_CHICKENPOX_82=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id krOgrXFy0T8L for ; Wed, 12 Jun 2013 11:46:55 -0700 (PDT) Received: from mail-vc0-f174.google.com (mail-vc0-f174.google.com [209.85.220.174]) by ietfa.amsl.com (Postfix) with ESMTP id 6BD2E11E80EF for ; Wed, 12 Jun 2013 11:46:55 -0700 (PDT) Received: by mail-vc0-f174.google.com with SMTP id kw10so6382151vcb.19 for ; Wed, 12 Jun 2013 11:46:54 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=446EvbF5jeXtskI/pWNTG6jpxj+kgoufRuZrjMDkEDo=; b=PwlJ9XK6yNzGm0uaEgKNVBi8JuKlIyDGa/KfefQSpy23b3gNt91dWoUfcrG1sy0Nhd rD8z7+b2JmpGYrg2PSTD1086dCyJGfWVotlCJc3RgIpQZ98XaU0udQledg1ndptmqfBB ecGwP9WZQPXhTASQPzF68AgMdGJs5yqo7hRMgWKWGXHkrjS6j1y+wtIq8K+EDlcE5anK go59uA+9VfJ08Z0Y9YGf4e/JrnuTB+54Hep+AHhKHVHTDUCDPyJTJ9jfjxMvCw8HQLmO qIhZRATKlecWHMIjWhEp5uAGLClwNUgP2HeXZSyE5BugSs4lDcLYOCfqMb6jQmkZgUBa 4teA== MIME-Version: 1.0 X-Received: by 10.52.30.14 with SMTP id o14mr8666288vdh.106.1371062814722; Wed, 12 Jun 2013 11:46:54 -0700 (PDT) Received: by 10.220.25.199 with HTTP; Wed, 12 Jun 2013 11:46:54 -0700 (PDT) X-Originating-IP: [96.49.81.176] Date: Wed, 12 Jun 2013 11:46:54 -0700 Message-ID: From: Tim Bray To: "json@ietf.org" Content-Type: multipart/alternative; boundary=20cf307ca1e60962e704def970e9 X-Gm-Message-State: ALoCoQnReAgvzM1fafQgMbLrlRadXc8QNwUb+mTRndVCWwMHZxxrRvlDp8z05HErJcLKFXgsixw3 Subject: [Json] Proposal for strings/Unicode text X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 12 Jun 2013 18:47:01 -0000 --20cf307ca1e60962e704def970e9 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Rationale: - emphasize the important fact that Strings are *intended* for Unicode characters - document the important fact that the rules allow horrible Unicode practices - say =E2=80=9Cbackslash=E2=80=9D instead of =E2=80=9Creverse solidus=E2=80= =9D :) In section 1, introduction Before: A string is a sequence of zero or more Unicode characters [UNICODE]. After: A string is intended to contain sequences of zero or more Unicode characters [UNICODE 6.2] Rewrite section 2.5 as follows: Strings begin and end with quotation marks. They are intended,to contain sequences of Unicode characters; Note however that the ABNF in this section allows the inclusion of 16-bit quantities in ways which can never be useful for representing characters and is likely to cause breakage in software designed to process Unicode text. The ABNF allows the use of many Unicode code points that could be used in future to represent Unicode characters, but have not yet been assigned. Therefore, this specification should not need revision as the Unicode character repertoire continues to grow. 16-bit quantities (normally Unicode characters from the Basic Multingual Pane(U+0000 through U+FFFF) may be =E2=80=9Cescaped=E2=80=9D, or represente= d as a six-character sequence: a backslash (U+005C REVERSE SOLIDUS), followed by the lowercase letter u, followed by four hexadecimal digits that encode the character's code point. The hexadecimal letters A though F can be upper or lower case. So, for example, a string containing only a single backslash may be represented as "\u005C". Alternatively, there are two-character sequence escape representations of some popular characters. So, for example, a string containing only a single backslash may be represented more compactly as "\\". To escape an extended character that is not in the Basic Multilingual Plane, the character is represented as a twelve-character sequence, encoding the UTF-16 surrogate pair. So, for example, a string containing only U+1D11E G CLEF may be represented as "\uD834\uDD1E". =3D=3D=3D insert ABNF here =3D=3D=3D=3D --20cf307ca1e60962e704def970e9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Rationale:
- emphasize t= he important fact that Strings are *intended* for Unicode characters
- document the important fact that the rules allow horrible Unicode= practices
- say =E2=80=9Cbackslash=E2=80=9D instead of =E2=80=9Creverse so= lidus=E2=80=9D :)

In section 1, introduction

Before:
=C2=A0=C2=A0 A string is a sequence of zero or more Unicode cha= racters [UNICODE].
After:
=C2=A0=C2=A0 A string is intended to contain sequences of zero or mor= e Unicode characters [UNICODE 6.2]

Rewrite section 2.5 as= follows:

Strings begin and end with quotation marks.=C2= =A0 They are intended,to contain sequences of Unicode characters; Note howe= ver that the ABNF in this section allows the inclusion of 16-bit quantities= in ways which can never be useful for representing characters and is likel= y to cause breakage in software designed to process Unicode text.

The ABNF allows the use of many Unicode code points that cou= ld be used in future to represent Unicode characters, but have not yet been= assigned. Therefore, this specification should not need revision as the Un= icode character repertoire continues to grow.

16-bit quantities (normally Unicode characters fr= om the Basic Multingual Pane(U+0000 through U+FFFF) may be =E2=80=9Cescaped= =E2=80=9D, or represented as a six-character sequence: a backslash (U+005C = REVERSE SOLIDUS), followed=C2=A0 by the lowercase letter u, followed by fou= r hexadecimal digits that encode the character's code point.=C2=A0 The = hexadecimal letters A though F can be upper or lower case.=C2=A0 So, for ex= ample, a string containing only a single backslash may be represented as &q= uot;\u005C".

Alternatively, there are two-character sequence escape representations = of some popular characters.=C2=A0 So, for example, a string containing only= a single backslash may be represented more compactly as "\\".
=C2=A0To escape an extended character that is not in the Basic Multilin= gual Plane, the character is represented as a twelve-character sequence, en= coding the UTF-16 surrogate pair.=C2=A0 So, for example, a string containin= g only U+1D11E G CLEF may be represented as
=C2=A0=C2=A0 "\uD834\uDD1E".

=3D=3D=3D insert A= BNF here =3D=3D=3D=3D
--20cf307ca1e60962e704def970e9-- From cabo@tzi.org Wed Jun 12 15:30:32 2013 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 B22F021E80E4 for ; Wed, 12 Jun 2013 15:30:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.856 X-Spam-Level: X-Spam-Status: No, score=-106.856 tagged_above=-999 required=5 tests=[AWL=0.793, BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_DE=0.35, J_CHICKENPOX_82=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id powRIzbq7Q2N for ; Wed, 12 Jun 2013 15:30:16 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 6A13F21F8F6E for ; Wed, 12 Jun 2013 15:30:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r5CMUBK8020709; Thu, 13 Jun 2013 00:30:11 +0200 (CEST) Received: from [192.168.217.105] (p54893401.dip0.t-ipconnect.de [84.137.52.1]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 324893E91; Thu, 13 Jun 2013 00:30:11 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Content-Type: text/plain; charset=windows-1252 From: Carsten Bormann In-Reply-To: Date: Thu, 13 Jun 2013 00:30:10 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <3E2A194C-789F-4E75-ABB0-CE966319463E@tzi.org> References: To: Tim Bray X-Mailer: Apple Mail (2.1508) Cc: "json@ietf.org" Subject: Re: [Json] Proposal for strings/Unicode text X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 12 Jun 2013 22:30:33 -0000 Hmm. Somehow I think the JSON specification should focus on describing what = the intended usage is. I strongly prefer adding an appendix M for things that you can do with = the ABNF that are almost, but not entirely unlike JSON. Gr=FC=DFe, Carsten PS.: I support jettisoning liturgical language in standards, and I = applaud Douglas for slipping with respect to the liturgical term "octet" = only twice (both in the same paragraph). But a document must also speak = the language of its editor, and if Douglas thinks "reverse solidus" is = the best way to speak about what some Germans (but never me) would call = "R=FCckschr=E4ger", that's fine, as long as it is consistent. PPS.: On the specific wording: > Before: > A string is a sequence of zero or more Unicode characters = [UNICODE]. > After: > A string is intended to contain sequences of zero or more Unicode = characters [UNICODE 6.2] A string is a sequence of characters. [not sequences of them] Add something like: "To reduce the burden on implementations, JSON is = less selective in what it accepts as a character than Unicode itself is. = See also Appendix M." > Strings begin and end with quotation marks.=20 The representation does, the string rarely does. RFC4627 got this right consistently, but in a tight language where = extracting a single sentence may lose the necessary context. > They are intended,to contain sequences of Unicode characters; Note = however that the ABNF in this section allows the inclusion of 16-bit = quantities in ways which can never be useful for representing characters = and is likely to cause breakage in software designed to process Unicode = text. This is where I would simply point to Appendix M. > The ABNF allows the use of many Unicode code points that could be used = in future to represent Unicode characters, but have not yet been = assigned. Therefore, this specification should not need revision as the = Unicode character repertoire continues to grow. This is something that even could be said in the introduction. Or in a section about stability and protocol evolution (the same section = that is needed to say that [past and future] changes in JavaScript don't = change JSON). > 16-bit quantities These are Unicode code points. > (normally Unicode characters from the Basic Multingual Pane(U+0000 = through U+FFFF) may be =93escaped=94, or represented as a six-character = sequence: a backslash (U+005C REVERSE SOLIDUS), followed by the = lowercase letter u, followed by four hexadecimal digits that encode the = character's code point. The hexadecimal letters A though F can be upper = or lower case. So, for example, a string containing only a single = backslash may be represented as "\u005C". >=20 > Alternatively, there are two-character sequence escape representations = of some popular characters. So, for example, a string containing only a = single backslash may be represented more compactly as "\\". >=20 > To escape an extended character Non-BMP characters aren't "extended". They have rights, too! You MUST rid your mind of discriminating against them. (I know, this was just copied over...) > that is not in the Basic Multilingual Plane, the character is = represented as a twelve-character sequence, encoding the UTF-16 = surrogate pair. So, for example, a string containing only U+1D11E G = CLEF may be represented as > "\uD834\uDD1E". (This could add a small apologetic clause pointing out the UTF-16 roots = of the weird notation. Or not.) This needs another pointer to appendix M. From ietf@lindenbergsoftware.com Wed Jun 12 15:46:20 2013 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 5DCC411E8114 for ; Wed, 12 Jun 2013 15:46:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.099 X-Spam-Level: X-Spam-Status: No, score=-4.099 tagged_above=-999 required=5 tests=[AWL=0.900, BAYES_00=-2.599, GB_I_LETTER=-2, J_CHICKENPOX_82=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QZts72a9qXAv for ; Wed, 12 Jun 2013 15:46:14 -0700 (PDT) Received: from mirach.lunarpages.com (mirach.lunarpages.com [216.97.235.70]) by ietfa.amsl.com (Postfix) with ESMTP id 75B2321E8105 for ; Wed, 12 Jun 2013 15:46:14 -0700 (PDT) Received: from 50-0-136-241.dsl.dynamic.sonic.net ([50.0.136.241]:56169 helo=[192.168.0.5]) by mirach.lunarpages.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1Umtnx-000aoL-0Y; Wed, 12 Jun 2013 15:46:13 -0700 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=utf-8 From: Norbert Lindenberg In-Reply-To: Date: Wed, 12 Jun 2013 15:46:07 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Tim Bray X-Mailer: Apple Mail (2.1283) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - mirach.lunarpages.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - lindenbergsoftware.com X-Get-Message-Sender-Via: mirach.lunarpages.com: authenticated_id: ietf@lindenbergsoftware.com Cc: Norbert Lindenberg , "json@ietf.org" Subject: Re: [Json] Proposal for strings/Unicode text X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 12 Jun 2013 22:46:20 -0000 On Jun 12, 2013, at 11:46 , Tim Bray wrote: > Rationale: > - emphasize the important fact that Strings are *intended* for Unicode = characters > - document the important fact that the rules allow horrible Unicode = practices > - say =E2=80=9Cbackslash=E2=80=9D instead of =E2=80=9Creverse = solidus=E2=80=9D :) The JSON RFC seems to use Unicode character names, in this case case = "reverse solidus". > In section 1, introduction >=20 > Before: > A string is a sequence of zero or more Unicode characters = [UNICODE]. > After: > A string is intended to contain sequences of zero or more Unicode = characters [UNICODE 6.2] >=20 > Rewrite section 2.5 as follows: >=20 > Strings begin and end with quotation marks. They are intended,to = contain sequences of Unicode characters; Note however that the ABNF in = this section allows the inclusion of 16-bit quantities in ways which can = never be useful for representing characters and is likely to cause = breakage in software designed to process Unicode text. This warning is too vague to be useful. Which specific risks do you = think need to be discussed here? Also, the ABNF doesn't do anything = specifically for 16-bit quantities, as far as I can see. > The ABNF allows the use of many Unicode code points that could be used = in future to represent Unicode characters, but have not yet been = assigned. Therefore, this specification should not need revision as the = Unicode character repertoire continues to grow. >=20 > 16-bit quantities (normally Unicode characters from the Basic = Multingual Pane(U+0000 through U+FFFF) may be =E2=80=9Cescaped=E2=80=9D, = or represented as a six-character sequence: a backslash (U+005C REVERSE = SOLIDUS), followed by the lowercase letter u, followed by four = hexadecimal digits that encode the character's code point. The = hexadecimal letters A though F can be upper or lower case. So, for = example, a string containing only a single backslash may be represented = as "\u005C". These escape sequences aren't about 16-bit quantities - they represent = Unicode BMP code points. If the parser inserts a BMP code point into an = output string in UTF-16 (in JavaScript, Java, and others), then the = result will be a 16-bit quantity. If it inserts the code point into an = output string in UTF-8 (in Python and others), then the result will be a = sequence of 1-3 bytes. If we discuss these escape sequences in prose, then the sequences for = BMP and supplementary characters need to be discussed together so that = it's clear what's a surrogate pair and how unpaired surrogates are = handled. JSON syntax allows almost all Unicode code points (with the exceptions = visible in the "unescaped" production) to be inserted into strings = directly, so escape sequences are mostly a convenience for using JSON in = environments that restrict the set of allowed characters (such as RFCs), = don't have the necessary fonts and input methods installed, or benefit = from making the code points visible (e.g., in test cases). > Alternatively, there are two-character sequence escape representations = of some popular characters. So, for example, a string containing only a = single backslash may be represented more compactly as "\\". I'd assume that this is not about popularity, but about the need to = represent control characters and characters that are also used within = the JSON syntax. I don't see two-character escapes for "e" or "=E7=9A=84".= Norbert From tbray@textuality.com Wed Jun 12 15:50:08 2013 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 5B29E21F994E for ; Wed, 12 Jun 2013 15:50:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.073 X-Spam-Level: X-Spam-Status: No, score=-1.073 tagged_above=-999 required=5 tests=[AWL=-0.125, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, GB_I_LETTER=-2, HTML_MESSAGE=0.001, J_CHICKENPOX_82=0.6, RCVD_IN_SORBS_DUL=0.877, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uvpgVq6TSQ4F for ; Wed, 12 Jun 2013 15:50:03 -0700 (PDT) Received: from mail-ve0-x231.google.com (mail-ve0-x231.google.com [IPv6:2607:f8b0:400c:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id 979A221F994C for ; Wed, 12 Jun 2013 15:49:57 -0700 (PDT) Received: by mail-ve0-f177.google.com with SMTP id cz10so7242762veb.36 for ; Wed, 12 Jun 2013 15:49:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=b0fKygUVrpWzVzqd6suigkGxCJj4+y0fB9bzJ0yWxVY=; b=fFUxHT4O3jfqgWxVSIyPIIv8HPRU/KUO8cUBSU8P2BfsgHyQKjCDdrLhoCLDzy7jq3 5/tNlnyzgJa4QO9B40NTACBt5DGtzB2Gpz3PFd3B/sZ8t0bevTQrwKkaNDAEEAB0/Qa7 mcLPDf5nmfClcZjOZrQ+REqDjUP0NguATRxMEBrer5xknjhyWb3O4q5mjJmnyll2JhGA ZGklBbQKsyUNAD82/nfJmaA1QvCnCed4xMWzSEsz5uVej9dIAIsSCkwhLS/YPrpOOkdL zke6+PfUX+4rjEpDeAFeGAB2YhKNC+dN5+bTgRJ7HvcPRNzesFPUCLCjB7yGBZPKF8a9 zcDQ== MIME-Version: 1.0 X-Received: by 10.52.30.14 with SMTP id o14mr8923277vdh.106.1371077396879; Wed, 12 Jun 2013 15:49:56 -0700 (PDT) Received: by 10.220.25.199 with HTTP; Wed, 12 Jun 2013 15:49:56 -0700 (PDT) X-Originating-IP: [96.49.81.176] In-Reply-To: <3E2A194C-789F-4E75-ABB0-CE966319463E@tzi.org> References: <3E2A194C-789F-4E75-ABB0-CE966319463E@tzi.org> Date: Wed, 12 Jun 2013 15:49:56 -0700 Message-ID: From: Tim Bray To: Carsten Bormann Content-Type: multipart/alternative; boundary=20cf307ca1e6337c3c04defcd5d5 X-Gm-Message-State: ALoCoQk/YK9D3gbaccdZk1Nx0m9O5lFPOurxqZ80UYLgDBoR3zF5tGfGtgVvBi3sk8YoonQI40jO Cc: "json@ietf.org" Subject: Re: [Json] Proposal for strings/Unicode text X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 12 Jun 2013 22:50:08 -0000 --20cf307ca1e6337c3c04defcd5d5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Revised per Carsten's and Norbert=E2=80=99s input. I=E2=80=99m unconvinced= about Appendix M since I think the =E2=80=9C16-bit quantities=E2=80=9D para says what need= s saying, but he caught a few bugs. Before: A string is a sequence of zero or more Unicode characters [UNICODE]. After: A string is intended to contain a sequence of zero or more Unicode characters [UNICODE 6.2] Rewrite section 2.5 as follows: Strings are delimited with quotation marks (U+0022 QUOTATION MARK). They are intended,to contain sequences of Unicode characters. Note however that the normative ABNF in this section allows the inclusion of 16-bit quantities, for example unpaired surrogate-block code points, in ways which can never be useful for representing characters and is likely to cause breakage in software designed to process Unicode text. The ABNF allows the use of many Unicode code points that could be used in future to represent Unicode characters, but have not yet been assigned. Therefore, this specification should not need revision as the Unicode character repertoire continues to grow. 16-bit quantities, normally representing Unicode characters from the Basic Multingual Pane (U+0000 through U+FFFF), may be =E2=80=9Cescaped=E2=80=9D, = or represented as a six-character sequence: a backslash (U+005C REVERSE SOLIDUS), followed by the lowercase letter u, followed by four hexadecimal digits that encode the character's code point. The hexadecimal letters A though F can be upper or lower case. So, for example, a string containing only a single backslash may be represented as "\u005C". Alternatively, there are two-character sequence escape representations of some popular characters. So, for example, a string containing only a single backslash may be represented more compactly as "\\". To escape a non-BMP character that is not in the Basic Multilingual Plane, the character is represented as a twelve-character sequence, encoding the UTF-16 surrogate pair. So, for example, a string containing only U+1D11E G CLEF may be represented as "\uD834\uDD1E". =3D=3D=3D insert ABNF here =3D=3D=3D=3D On Wed, Jun 12, 2013 at 3:30 PM, Carsten Bormann wrote: > Hmm. > > Somehow I think the JSON specification should focus on describing what th= e > intended usage is. > > I strongly prefer adding an appendix M for things that you can do with th= e > ABNF that are almost, but not entirely unlike JSON. > > Gr=C3=BC=C3=9Fe, Carsten > > PS.: I support jettisoning liturgical language in standards, and I applau= d > Douglas for slipping with respect to the liturgical term "octet" only twi= ce > (both in the same paragraph). But a document must also speak the languag= e > of its editor, and if Douglas thinks "reverse solidus" is the best way to > speak about what some Germans (but never me) would call "R=C3=BCckschr=C3= =A4ger", > that's fine, as long as it is consistent. > > PPS.: On the specific wording: > > Before: > > A string is a sequence of zero or more Unicode characters [UNICODE]. > > After: > > A string is intended to contain sequences of zero or more Unicode > characters [UNICODE 6.2] > > A string is a sequence of characters. [not sequences of them] > Add something like: "To reduce the burden on implementations, JSON is les= s > selective in what it accepts as a character than Unicode itself is. See > also Appendix M." > > > Strings begin and end with quotation marks. > > The representation does, the string rarely does. > RFC4627 got this right consistently, but in a tight language where > extracting a single sentence may lose the necessary context. > > > They are intended,to contain sequences of Unicode characters; Note > however that the ABNF in this section allows the inclusion of 16-bit > quantities in ways which can never be useful for representing characters > and is likely to cause breakage in software designed to process Unicode > text. > > This is where I would simply point to Appendix M. > > > The ABNF allows the use of many Unicode code points that could be used > in future to represent Unicode characters, but have not yet been assigned= . > Therefore, this specification should not need revision as the Unicode > character repertoire continues to grow. > > This is something that even could be said in the introduction. > Or in a section about stability and protocol evolution (the same section > that is needed to say that [past and future] changes in JavaScript don't > change JSON). > > > 16-bit quantities > > These are Unicode code points. > > > (normally Unicode characters from the Basic Multingual Pane(U+0000 > through U+FFFF) may be =E2=80=9Cescaped=E2=80=9D, or represented as a six= -character > sequence: a backslash (U+005C REVERSE SOLIDUS), followed by the lowercas= e > letter u, followed by four hexadecimal digits that encode the character's > code point. The hexadecimal letters A though F can be upper or lower cas= e. > So, for example, a string containing only a single backslash may be > represented as "\u005C". > > > > Alternatively, there are two-character sequence escape representations > of some popular characters. So, for example, a string containing only a > single backslash may be represented more compactly as "\\". > > > > To escape an extended character > > Non-BMP characters aren't "extended". They have rights, too! > You MUST rid your mind of discriminating against them. > (I know, this was just copied over...) > > > that is not in the Basic Multilingual Plane, the character is > represented as a twelve-character sequence, encoding the UTF-16 surrogate > pair. So, for example, a string containing only U+1D11E G CLEF may be > represented as > > "\uD834\uDD1E". > > (This could add a small apologetic clause pointing out the UTF-16 roots o= f > the weird notation. Or not.) > This needs another pointer to appendix M. > > --20cf307ca1e6337c3c04defcd5d5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Revised per Carsten's=C2=A0 and Norbert=E2=80=99s inpu= t. I=E2=80=99m unconvinced about Appendix M since I think the =E2=80=9C16-b= it quantities=E2=80=9D para says what needs saying, but he caught a few bug= s.

Before:
=C2=A0=C2=A0 A string is a sequence of zero or more Un= icode characters [UNICODE].
After:
=C2=A0=C2=A0 A string is intended to contain a sequence of zero or more Uni= code characters [UNICODE 6.2]

Rewrite section 2.5 as follows:
Strings are delimited=C2=A0 with quotation marks (U+0022 Q= UOTATION MARK).=C2=A0 They are intended,to contain=20 sequences of Unicode characters.=C2=A0 Note however that the normative ABNF= in this=20 section allows the inclusion of 16-bit quantities, for example unpaired sur= rogate-block code points, in ways which can=20 never be useful for representing characters and is likely to cause=20 breakage in software designed to process Unicode text.

The ABNF allows the use of many Unicode code points that=20 could be used in future to represent Unicode characters, but have not=20 yet been assigned. Therefore, this specification should not need=20 revision as the Unicode character repertoire continues to grow.

16-bit quantities, normally representing Unicode = characters from the Basic Multingual Pane (U+0000 through U+FFFF), may be =E2=80=9Ces= caped=E2=80=9D, or represented as a six-character sequence: a backslash (U+005C REVERSE SOLIDUS), followed=C2=A0 by the lowercase letter u, followed by four=20 hexadecimal digits that encode the character's code point.=C2=A0 The=20 hexadecimal letters A though F can be upper or lower case.=C2=A0 So, for=20 example, a string containing only a single backslash may be represented=20 as "\u005C".

Alternatively, there are two-character sequence escape=20 representations of some popular characters.=C2=A0 So, for example, a string= =20 containing only a single backslash may be represented more compactly as=20 "\\".

=C2=A0To escape a non-BMP character that is not in the Basic=20 Multilingual Plane, the character is represented as a twelve-character=20 sequence, encoding the UTF-16 surrogate pair.=C2=A0 So, for example, a stri= ng containing only U+1D11E G CLEF may be represented as
=C2=A0=C2=A0 "\uD834\uDD1E".

=3D=3D=3D insert ABNF h= ere =3D=3D=3D=3D


On Wed, Jun 12, 2013 at 3:30 PM, Carsten Bormann <cabo@tzi.org= > wrote:
Hmm.

Somehow I think the JSON specification should focus on describing what the = intended usage is.

I strongly prefer adding an appendix M for things that you can do with the = ABNF that are almost, but not entirely unlike JSON.

Gr=C3=BC=C3=9Fe, Carsten

PS.: I support jettisoning liturgical language in standards, and I applaud = Douglas for slipping with respect to the liturgical term "octet" = only twice (both in the same paragraph). =C2=A0But a document must also spe= ak the language of its editor, and if Douglas thinks "reverse solidus&= quot; is the best way to speak about what some Germans (but never me) would= call "R=C3=BCckschr=C3=A4ger", that's fine, as long as it is= consistent.

PPS.: On the specific wording:
> Before:
> =C2=A0 =C2=A0A string is a sequence of zero or more Unicode characters= [UNICODE].
> After:
> =C2=A0 =C2=A0A string is intended to contain sequences of zero or more= Unicode characters [UNICODE 6.2]

A string is a sequence of characters. =C2=A0[not sequences of them] Add something like: "To reduce the burden on implementations, JSON is = less selective in what it accepts as a character than Unicode itself is. = =C2=A0See also Appendix M."

> Strings begin and end with quotation marks.

The representation does, the string rarely does.
RFC4627 got this right consistently, but in a tight language where extracti= ng a single sentence may lose the necessary context.

> They are intended,to contain sequences of Unicode characters; Note how= ever that the ABNF in this section allows the inclusion of 16-bit quantitie= s in ways which can never be useful for representing characters and is like= ly to cause breakage in software designed to process Unicode text.

This is where I would simply point to Appendix M.

> The ABNF allows the use of many Unicode code points that could be used= in future to represent Unicode characters, but have not yet been assigned.= Therefore, this specification should not need revision as the Unicode char= acter repertoire continues to grow.

This is something that even could be said in the introduction.
Or in a section about stability and protocol evolution (the same section th= at is needed to say that [past and future] changes in JavaScript don't = change JSON).

> 16-bit quantities

These are Unicode code points.

> (normally Unicode characters from the Basic Multingual Pane(U+0000 thr= ough U+FFFF) may be =E2=80=9Cescaped=E2=80=9D, or represented as a six-char= acter sequence: a backslash (U+005C REVERSE SOLIDUS), followed =C2=A0by the= lowercase letter u, followed by four hexadecimal digits that encode the ch= aracter's code point. =C2=A0The hexadecimal letters A though F can be u= pper or lower case. =C2=A0So, for example, a string containing only a singl= e backslash may be represented as "\u005C".
>
> Alternatively, there are two-character sequence escape representations= of some popular characters. =C2=A0So, for example, a string containing onl= y a single backslash may be represented more compactly as "\\". >
> =C2=A0To escape an extended character

Non-BMP characters aren't "extended". =C2=A0They have r= ights, too!
You MUST rid your mind of discriminating against them.
(I know, this was just copied over...)

> that is not in the Basic Multilingual Plane, the character is represen= ted as a twelve-character sequence, encoding the UTF-16 surrogate pair. =C2= =A0So, for example, a string containing only U+1D11E G CLEF may be represen= ted as
> =C2=A0 =C2=A0"\uD834\uDD1E".

(This could add a small apologetic clause pointing out the UTF-16 roo= ts of the weird notation. =C2=A0Or not.)
This needs another pointer to appendix M.


--20cf307ca1e6337c3c04defcd5d5-- From tbray@textuality.com Wed Jun 12 15:54:32 2013 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 C416611E8109 for ; Wed, 12 Jun 2013 15:54:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.776 X-Spam-Level: X-Spam-Status: No, score=-2.776 tagged_above=-999 required=5 tests=[AWL=1.600, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, GB_I_LETTER=-2, HTML_MESSAGE=0.001, J_CHICKENPOX_82=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 51GKsgWFunEx for ; Wed, 12 Jun 2013 15:54:26 -0700 (PDT) Received: from mail-vc0-f176.google.com (mail-vc0-f176.google.com [209.85.220.176]) by ietfa.amsl.com (Postfix) with ESMTP id 4A38211E80F8 for ; Wed, 12 Jun 2013 15:54:26 -0700 (PDT) Received: by mail-vc0-f176.google.com with SMTP id ha12so3205022vcb.35 for ; Wed, 12 Jun 2013 15:54:25 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=9Kz/ziuDHClFqiVdRfFQmW1BIro+JQ4qpZoh518n03U=; b=h7aKdPIpyqkoR/uF03+SMALXBi8XEnWg8qK3UEg+cUN4JMhiYiDvI8OYPV838h+yvr oQnO8179qmQtLzib4XkS+6mFT+LKj2okDYygbv6GEn/nfeK+wB5ARVmZ0Dush7Hprjcu r0yOyeJW4NgVcWZVHdnDh0BRggdnypFkxCv0ergMyJgXWlDEHHn0OzzDM5+75j+dPZXG fInpKjjwj1jjU8riz0i+xlJ8sRoT25i7S5mHw++S9+VUcpCesWaFj2YLIla4Xh+QnGgH XNG7EVIkV0XvQl8KZ8MUzioErAO8PU06yjguGjV5pxl0Wyp/JyEp+UOVK80lncOV5ygy GJmQ== MIME-Version: 1.0 X-Received: by 10.52.112.5 with SMTP id im5mr8985553vdb.4.1371077665581; Wed, 12 Jun 2013 15:54:25 -0700 (PDT) Received: by 10.220.25.199 with HTTP; Wed, 12 Jun 2013 15:54:25 -0700 (PDT) X-Originating-IP: [96.49.81.176] In-Reply-To: References: Date: Wed, 12 Jun 2013 15:54:25 -0700 Message-ID: From: Tim Bray To: Norbert Lindenberg Content-Type: multipart/alternative; boundary=bcaec54857e83787c604defce58d X-Gm-Message-State: ALoCoQmCSknCoqpsLakfoY0cs98ZK11zctzqPj6j6dMSNoaWRLdy5IEk8is9SeaCezlZEwIoiKBc Cc: "json@ietf.org" Subject: Re: [Json] Proposal for strings/Unicode text X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 12 Jun 2013 22:54:32 -0000 --bcaec54857e83787c604defce58d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Jun 12, 2013 at 3:46 PM, Norbert Lindenberg < ietf@lindenbergsoftware.com> wrote: > The JSON RFC seems to use Unicode character names, in this case case > "reverse solidus". > We=E2=80=99re not allowed to change JSON but we are allowed to improve the = spec. The term =E2=80=9Csolidus=E2=80=9D is obscure and off-putting. > Strings begin and end with quotation marks. They are intended,to contain sequences of Unicode characters; Note however that the ABNF in this section allows the inclusion of 16-bit quantities in ways which can never be useful for representing characters and is likely to cause breakage in software designed to process Unicode text. This warning is too vague to be useful. Which specific risks do you think > need to be discussed here? Also, the ABNF doesn't do anything specificall= y > for 16-bit quantities, as far as I can see. > Agreed; I introduced a specific example. > > 16-bit quantities (normally Unicode characters from the Basic > Multingual Pane(U+0000 through U+FFFF) may be =E2=80=9Cescaped=E2=80=9D, = or represented as > a six-character sequence: a backslash (U+005C REVERSE SOLIDUS), followed > by the lowercase letter u, followed by four hexadecimal digits that enco= de > the character's code point. The hexadecimal letters A though F can be > upper or lower case. So, for example, a string containing only a single > backslash may be represented as "\u005C". > > These escape sequences aren't about 16-bit quantities - they represent > Unicode BMP code points. They also represent surrogates. Thus they combine fish and bicycles, and I think the only accurate way to describe what you can escape is =E2=80=9C16-= bit quantities=E2=80=9D > If we discuss these escape sequences in prose, then the sequences for BMP > and supplementary characters need to be discussed together so that it's > clear what's a surrogate pair and how unpaired surrogates are handled. > Hm? I see no point in replicating the discussion of surrogates in Unicode, and there is nothing useful to say about the handling of unpaired surrogates. > > Alternatively, there are two-character sequence escape representations > of some popular characters. So, for example, a string containing only a > single backslash may be represented more compactly as "\\". > > I'd assume that this is not about popularity, but about the need to > represent control characters and characters that are also used within the > JSON syntax. I don't see two-character escapes for "e" or "=E7=9A=84". > I tried to stay close to the language of the original. > > Norbert > > --bcaec54857e83787c604defce58d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Jun 12, 2013 at 3:46 PM, Norbert Lindenberg <ietf@lindenbergsoftware.com> wrote:
The JSON RFC seem= s to use Unicode character names, in this case case "reverse solidus&q= uot;.

We=E2=80=99re not allowed to change JSON b= ut we are allowed to improve the spec. The term =E2=80=9Csolidus=E2=80=9D i= s obscure and off-putting.
=C2=A0
> Strings begin and end with quotation marks. =C2=A0They are intended,to= contain sequences of Unicode characters; Note however that the ABNF in thi= s section allows the inclusion of 16-bit quantities in ways which can never= be useful for representing characters and is likely to cause breakage in s= oftware designed to process Unicode text.

This warning is too vague to be useful= . Which specific risks do you think need to be discussed here? Also, the AB= NF doesn't do anything specifically for 16-bit quantities, as far as I = can see.

Agreed; I introduced a specific example.

=C2=A0
> 16-bit quantities (normally Unicode characters from the Basic Multingu= al Pane(U+0000 through U+FFFF) may be =E2=80=9Cescaped=E2=80=9D, or represe= nted as a six-character sequence: a backslash (U+005C REVERSE SOLIDUS), fol= lowed =C2=A0by the lowercase letter u, followed by four hexadecimal digits = that encode the character's code point. =C2=A0The hexadecimal letters A= though F can be upper or lower case. =C2=A0So, for example, a string conta= ining only a single backslash may be represented as "\u005C".

These escape sequences aren't about 16-bit quantities - they repr= esent Unicode BMP code points.
=C2=A0
They also = represent surrogates.=C2=A0 Thus they combine fish and bicycles, and I thin= k the only accurate way to describe what you can escape is =E2=80=9C16-bit = quantities=E2=80=9D
=C2=A0
If we discuss these e= scape sequences in prose, then the sequences for BMP and supplementary char= acters need to be discussed together so that it's clear what's a su= rrogate pair and how unpaired surrogates are handled.

Hm?=C2=A0 I see no point in replicating th= e discussion of surrogates in Unicode, and there is nothing useful to say a= bout the handling of unpaired surrogates.
=C2=A0
> Alternatively, there are two-character sequence escape representations= of some popular characters. =C2=A0So, for example, a string containing onl= y a single backslash may be represented more compactly as "\\".

I'd assume that this is not about popularity, but about the need = to represent control characters and characters that are also used within th= e JSON syntax. I don't see two-character escapes for "e" or &= quot;=E7=9A=84".

I tried to stay close to the language of t= he original.

=C2=A0

Norbert


--bcaec54857e83787c604defce58d-- From cabo@tzi.org Wed Jun 12 16:41:08 2013 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 2E1D721E80AA for ; Wed, 12 Jun 2013 16:41:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.889 X-Spam-Level: X-Spam-Status: No, score=-105.889 tagged_above=-999 required=5 tests=[AWL=-0.240, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_82=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H-CkD1u3s-gv for ; Wed, 12 Jun 2013 16:41:02 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 7D2CD11E8119 for ; Wed, 12 Jun 2013 16:41:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r5CNepUf021482; Thu, 13 Jun 2013 01:40:51 +0200 (CEST) Received: from [192.168.217.105] (p54893401.dip0.t-ipconnect.de [84.137.52.1]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id AA5E23EA0; Thu, 13 Jun 2013 01:40:50 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: Date: Thu, 13 Jun 2013 01:40:49 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <3E2A194C-789F-4E75-ABB0-CE966319463E@tzi.org> To: Tim Bray X-Mailer: Apple Mail (2.1508) Cc: "json@ietf.org" Subject: Re: [Json] Proposal for strings/Unicode text X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 12 Jun 2013 23:41:08 -0000 On Jun 13, 2013, at 00:49, Tim Bray wrote: > Strings are delimited with quotation marks (U+0022 QUOTATION MARK). = They are intended,to contain sequences of Unicode characters. Note = however that the normative ABNF in this section allows the inclusion of = 16-bit quantities, for example unpaired surrogate-block code points, in = ways which can never be useful for representing characters and is likely = to cause breakage in software designed to process Unicode text. A kitchen knife is intended to cut food. Note however that the = normative cutting edge of the knife also allows the use against = intruding burglars, for example by slashing open their guts, which can = never be useful for food and is likely to cause you trouble in a number = of ways, including bloodstains on your shirt. I don't want to read this sentence in the introduction of the manual for = my kitchen knife, please. Again, can we focus on the correct usage and ban avenues for misuse to = an appendix? It could even be called "the JSON character model" to obscure its grisly = purpose. You are not going to get both "correct" and "understandable" if you = combine the intended usage with all the arcane legacy issues into one = piece of text. (If I'm the only one who cares about this editorial issue, this is going = to be my last comment on this... if this WG does manage to turn one of = the nicest-written RFCs into goulash, I can always point my students to = read the original.) Gr=FC=DFe, Carsten PS.: "16-bit quantities" is highly confusing. Outside of mathematics = and physics, "quantity" gives the amount of something. There is = absolutely no reason not to use the term "code point" from Unicode. =BBIn the Unicode Standard, the codespace consists of the integers from = 0 to 10FFFF[16], comprising 1,114,112 code points available for = assigning the repertoire of abstract characters.=AB See also Table 2-3. Yes, all of them can be used in a JSON document... =20 Some of them must be escaped, some of them are non-characters but = otherwise innocuous, some of them (surrogates) actively try to slash = your guts, but they are all code points. =BBSurrogate code points cannot be conformantly interchanged using = Unicode encoding forms. They do not correspond to Unicode scalar values = and thus do not have well-formed representations in any Unicode encoding = form. (See Section 3.8, Surrogates.)=AB So they must be escaped (unless you are using them for their intended = purpose in a UTF-16-encoded JSON document, a rare species). There also = is no way to notate a sequence of a high surrogate and a low surrogate = using escape sequences in JSON, because that always stands for the = non-BMP code point that results from the values of the two surrogates. = All that should be mentioned somewhere, because it takes a couple of = hours of analysis to ascertain that. (Maybe also mention that that = doesn't hurt the "JavaScript string as vector of 16-bit numbers" use = case, because the non-BMP characters can be (will be!) taken apart again = by the recipient. So you don't even have to escape them... More stuff = for the appendix, or maybe for a special "worst practice" document.) From sayrer@gmail.com Wed Jun 12 16:56:31 2013 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 94EE021E80BA for ; Wed, 12 Jun 2013 16:56:31 -0700 (PDT) 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=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kbjMFn7wf39e for ; Wed, 12 Jun 2013 16:56:31 -0700 (PDT) Received: from mail-we0-x22d.google.com (mail-we0-x22d.google.com [IPv6:2a00:1450:400c:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id C286A21E8087 for ; Wed, 12 Jun 2013 16:56:30 -0700 (PDT) Received: by mail-we0-f173.google.com with SMTP id x54so6528666wes.18 for ; Wed, 12 Jun 2013 16:56:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=xvwkfP/7n7FxGOr1Vtu1m3Ld2iqqneKDF9FgskiKtQE=; b=04nMc4slYZo5dbFlof3SLXBWsyR61MyxdlrER18Mqnx305pH13jAiwPFBlXvasOBZu wZa87oAqV1lNivp0EGYkYjQGpKh8K3Zlx0jNMSoASd/2U3tpA0+PW2U6mPT6KAdmmmuF WFrJ8PyUNvaiJ/B6frhGsP18DihxxEn7Zq5FhqaovElCTIfA0aSZoOIuVgoaiw15Q661 +yBJyjhH+X+wWyFxrjjqyb7Guba/DodmZp6izHO9q/M/J8UlVglTYFG3JUfOxNbnirnL WYaIuyHakL9m+I+kIfm6pWfu80EXpHiHy7j9SQT1xczWYaIQECpeCcDiKbIQ/jwFAZx8 bCcg== MIME-Version: 1.0 X-Received: by 10.180.185.4 with SMTP id ey4mr6000356wic.49.1371081389096; Wed, 12 Jun 2013 16:56:29 -0700 (PDT) Received: by 10.194.83.35 with HTTP; Wed, 12 Jun 2013 16:56:28 -0700 (PDT) In-Reply-To: References: <3E2A194C-789F-4E75-ABB0-CE966319463E@tzi.org> Date: Wed, 12 Jun 2013 16:56:28 -0700 Message-ID: From: R S To: Carsten Bormann Content-Type: multipart/alternative; boundary=001a11c3502227c68704defdc381 Cc: Tim Bray , "json@ietf.org" Subject: Re: [Json] Proposal for strings/Unicode text X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 12 Jun 2013 23:56:31 -0000 --001a11c3502227c68704defdc381 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Jun 12, 2013 at 4:40 PM, Carsten Bormann wrote: > > Again, can we focus on the correct usage and ban avenues for misuse to an > appendix? > The document should refrain from value judgements. The "correct" use is what JSON is already being used for. Even Tim's "breakage" language is a little strong (although I can live with it). - Rob --001a11c3502227c68704defdc381 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Jun 12, 2013 at 4:40 PM, Carsten Bormann <cabo@tzi.org= > wrote:

Again, can we focus on the correct usage and ban avenues for misuse to an a= ppendix?

The document should refr= ain from value judgements. The "correct" use is what JSON is alre= ady being used for. Even Tim's "breakage" language is a littl= e strong (although I can live with it).

- Rob
--001a11c3502227c68704defdc381-- From cowan@ccil.org Wed Jun 12 17:32:20 2013 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 9B71B21E8095 for ; Wed, 12 Jun 2013 17:32:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.425 X-Spam-Level: X-Spam-Status: No, score=-3.425 tagged_above=-999 required=5 tests=[AWL=0.174, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k2J14PdA7NDT for ; Wed, 12 Jun 2013 17:32:16 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id 45C0621E808E for ; Wed, 12 Jun 2013 17:32:16 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1UmvSX-0007Xv-IY; Wed, 12 Jun 2013 20:32:13 -0400 Date: Wed, 12 Jun 2013 20:32:13 -0400 From: John Cowan To: Norbert Lindenberg Message-ID: <20130613003213.GA26989@mercury.ccil.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Cc: Tim Bray , "json@ietf.org" Subject: Re: [Json] Proposal for strings/Unicode text X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 13 Jun 2013 00:32:20 -0000 Norbert Lindenberg scripsit: > JSON syntax allows almost all Unicode code points (with the exceptions > visible in the "unescaped" production) to be inserted into strings > directly, so escape sequences are mostly a convenience for using JSON > in environments that restrict the set of allowed characters (such as > RFCs), don't have the necessary fonts and input methods installed, > or benefit from making the code points visible (e.g., in test cases). Officially, yes. But surrogate code points cannot be inserted directly if the representation is UTF-8 (otherwise it becomes CESU-8 instead) or UTF-16 (otherwise it is broken UTF-16) or random non-Unicode encodings. So UTF-32 is the only encoding into which a surrogate code point can be inserted directly -- and nobody uses it. In practice, therefore, code points in the range D800-DFFF must be escaped if they are to be used. -- Mark Twain on Cecil Rhodes: John Cowan I admire him, I freely admit it, http://www.ccil.org/~cowan and when his time comes I shall cowan@ccil.org buy a piece of the rope for a keepsake. From presnick@qti.qualcomm.com Wed Jun 12 17:38:54 2013 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 03E6521F996A for ; Wed, 12 Jun 2013 17:38:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1L-PhJj32IlI for ; Wed, 12 Jun 2013 17:38:49 -0700 (PDT) Received: from sabertooth02.qualcomm.com (sabertooth02.qualcomm.com [65.197.215.38]) by ietfa.amsl.com (Postfix) with ESMTP id 9BA7821F9994 for ; Wed, 12 Jun 2013 17:38:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1371083929; x=1402619929; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=HHmlAauicgXQ3HaYcRfgN++samJZEOgvT8bSzM4rTrQ=; b=uAMD+S3sa0dwczjbFW1n+SvIYjCo6HmsX7T5osYF4a2oBNpR9yVga6UN yaYsKjLoUDwnuJrD7Oi20bcAm7a4kkDSj4wtrOtFzgxl3kks7R6D90gng MNiK0q/+f3rnw2vZg5JrCURRm8gh2rYWjr4MseRiWE8kbeoy/R268riCS 4=; X-IronPort-AV: E=Sophos;i="4.87,855,1363158000"; d="scan'208";a="44855891" Received: from ironmsg04-r.qualcomm.com ([172.30.46.18]) by sabertooth02.qualcomm.com with ESMTP; 12 Jun 2013 17:38:49 -0700 X-IronPort-AV: E=Sophos;i="4.87,855,1363158000"; d="scan'208";a="552756519" Received: from nasanexhc04.na.qualcomm.com ([172.30.48.17]) by Ironmsg04-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 12 Jun 2013 17:38:49 -0700 Received: from presnick-mac.local (172.30.48.1) by qcmail1.qualcomm.com (172.30.48.17) with Microsoft SMTP Server (TLS) id 14.2.318.4; Wed, 12 Jun 2013 17:38:48 -0700 Message-ID: <51B91496.8020806@qti.qualcomm.com> Date: Wed, 12 Jun 2013 19:38:46 -0500 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: Paul Hoffman References: <0FBD58CE-748D-419A-8578-CCBF3FDF97CE@vpnc.org> In-Reply-To: <0FBD58CE-748D-419A-8578-CCBF3FDF97CE@vpnc.org> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.30.48.1] Cc: "json@ietf.org" Subject: Re: [Json] String comparisons -- LAST CHANCE ON PROPOSALS X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 13 Jun 2013 00:38:54 -0000 I am speaking here solely as a participant. I just have a couple of suggestions on this topic: On 6/11/13 12:44 PM, Paul Hoffman wrote: [Both proposals:] > For purpose of establishing key equality, comparisons MUST be conducted, after all unescaping is done, by comparing numeric character code points. > I think the passive construction is really confusing, and in this case it took me multiple re-readings to figure out what it was trying to say. So I'd like to suggest (including changing "key" to "name"): "For purpose of establishing name equality, implementations MUST first do all unescaping and then MUST compare numeric character code points." Assuming that's what was meant. That was my guess after much re-reading. As for the rest: > Proposal 1 > ========== > There is to be no modification of any kind to the characters in keys, including case-changing or combining-form normalization. > > Proposal 2 > ========== > There MUST NOT be any modification of any kind to the characters in keys, including change of case or change between precomposed and decomposed forms. > I actually prefer proposal 1. This sentence is simply reinforcing the first sentence, which has the actual requirements. If you really want requirements language, again I'd prefer a non-passive construction: "Modifications MUST NOT be made to the characters in the names when doing comparisons, such as change of case or change between precomposed and decomposed forms of the characters." But again, just my preference. pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From derhoermi@gmx.net Thu Jun 13 03:15:32 2013 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 B923A21F96FE for ; Thu, 13 Jun 2013 03:15:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.513 X-Spam-Level: X-Spam-Status: No, score=-2.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4kmEarSe7o0W for ; Thu, 13 Jun 2013 03:15:28 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) by ietfa.amsl.com (Postfix) with ESMTP id 0E5FD21F96D9 for ; Thu, 13 Jun 2013 03:15:18 -0700 (PDT) Received: from mailout-de.gmx.net ([10.1.76.19]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0Lh9yb-1U1vl40Ixb-00oU9H for ; Thu, 13 Jun 2013 12:15:17 +0200 Received: (qmail invoked by alias); 13 Jun 2013 10:15:16 -0000 Received: from p5B233947.dip0.t-ipconnect.de (EHLO netb.Speedport_W_700V) [91.35.57.71] by mail.gmx.net (mp019) with SMTP; 13 Jun 2013 12:15:16 +0200 X-Authenticated: #723575 X-Provags-ID: V01U2FsdGVkX197PAIrI257xIROvVfqKM5vxQKUTB904feWvHMnVZ sZz5TjbE1uj6DP From: Bjoern Hoehrmann To: John Cowan Date: Thu, 13 Jun 2013 12:15:18 +0200 Message-ID: References: <20130613003213.GA26989@mercury.ccil.org> In-Reply-To: <20130613003213.GA26989@mercury.ccil.org> X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 Cc: "json@ietf.org" Subject: Re: [Json] Proposal for strings/Unicode text X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 13 Jun 2013 10:15:32 -0000 * John Cowan wrote: >Officially, yes. But surrogate code points cannot be inserted directly >if the representation is UTF-8 (otherwise it becomes CESU-8 instead) >or UTF-16 (otherwise it is broken UTF-16) or random non-Unicode encodings. >So UTF-32 is the only encoding into which a surrogate code point can be >inserted directly -- and nobody uses it. http://www.unicode.org/versions/Unicode6.2.0/ch03.pdf D31 UTF-32 encoding form: The Unicode encoding form which assigns each Unicode scalar value to a single unsigned 32-bit code unit with the same numeric value as the Unicode scalar value. • In UTF-32, the code point sequence <004D, 0430, 4E8C, 10302> is represented as <0000004D 00000430 00004E8C 00010302>. • Because surrogate code points are not included in the set of Unicode scalar values, UTF-32 code units in the range 0000D800_16 .. 0000DFFF_16 are ill-formed. • Any UTF-32 code unit greater than 0010FFFF_16 is ill-formed. Note the second bullet point. -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ From cowan@ccil.org Thu Jun 13 05:16:27 2013 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 0E02021F9921 for ; Thu, 13 Jun 2013 05:16:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.43 X-Spam-Level: X-Spam-Status: No, score=-3.43 tagged_above=-999 required=5 tests=[AWL=0.169, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 50FssTEyQvJZ for ; Thu, 13 Jun 2013 05:16:22 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id AC39F21F8B51 for ; Thu, 13 Jun 2013 05:16:21 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1Un6Rw-0000K3-87; Thu, 13 Jun 2013 08:16:20 -0400 Date: Thu, 13 Jun 2013 08:16:20 -0400 From: John Cowan To: Bjoern Hoehrmann Message-ID: <20130613121620.GB11739@mercury.ccil.org> References: <20130613003213.GA26989@mercury.ccil.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Cc: "json@ietf.org" Subject: Re: [Json] Proposal for strings/Unicode text X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 13 Jun 2013 12:16:27 -0000 Bjoern Hoehrmann scripsit: > >Officially, yes. But surrogate code points cannot be inserted directly > >if the representation is UTF-8 (otherwise it becomes CESU-8 instead) > >or UTF-16 (otherwise it is broken UTF-16) or random non-Unicode encodings. > >So UTF-32 is the only encoding into which a surrogate code point can be > >inserted directly -- and nobody uses it. > > • Because surrogate code points are not included in the set of > Unicode scalar values, UTF-32 code units in the range > 0000D800_16 .. 0000DFFF_16 are ill-formed. Well, sure. Note the fine distinction between "can" (in physical fact) and "may" (in the RFC 2119 sense). It's invalid to have unpaired surrogates in *any* context. But at least it is safe and possible to do so in UTF-32. In UTF-8, there is no representation at all, and in UTF-16 you can't tell the difference between two consecutive unpaired surrogates of opposite polarities and a surrogate pair. (Though come to think of it, escaping doesn't allow two consecutive unpaired surrogates either, so maybe we can fairly say that either UTF-16 or UTF-32 allow them.) The point is that if JSON is encoded in UTF-8, any surrogate code points MUST be escaped, even though the grammar does not say so. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org Uneasy lies the head that wears the Editor's hat! --Eddie Foirbeis Climo From douglas@crockford.com Thu Jun 13 08:51:05 2013 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 8D13A21F99F8 for ; Thu, 13 Jun 2013 08:51:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.513 X-Spam-Level: X-Spam-Status: No, score=-2.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t5rpdsZM1B1Y for ; Thu, 13 Jun 2013 08:50:57 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id E488721F997F for ; Thu, 13 Jun 2013 08:50:53 -0700 (PDT) Received: from [192.168.115.232] ([216.113.168.135]) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis) id 0M8Ouw-1URW8n0o0A-00wHvr; Thu, 13 Jun 2013 11:50:52 -0400 Message-ID: <51B9EA49.2050604@crockford.com> Date: Thu, 13 Jun 2013 08:50:33 -0700 From: Douglas Crockford User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "json@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V02:K0:x1I3vwY3Cu5rql8UTxlkhIKrzfE0ot3vnWfXooG8uiT 5ZdK7YW3/Hbsg2CPij6+tgbktaM8P4Mre5yVkmNTZUXiThJ34C MxDnZXkcnTo7ClS9dlxDc/NBQLZ40aTngdF9nuCXQlz4c9BdWp mCgKihpzqbL5tmiLJehM7MvZsCBV9qarC5bSUcEaAdqqHLA1aV e7/jilsiiefR1LTepads1gOboHqvuSOljD55HWuDVcWVzttMq1 7PKW5k4lD9ER0U8osYJokG98MBX6XIcgPzGJhKLFKnkGZGzT7a n1TbXCxRaBfUKteuu43KJG8kuNBUvn0x18uTnDLw0Tv8PKDBHy ketjy7i66cBayAwz2k1Edeqenj10ufjDmZxBw7DcO Subject: [Json] Two Documents X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 13 Jun 2013 15:51:05 -0000 The confusion and controversy around this work is due to a mistake that I made in RFC 4627. The purpose of the RFC, which is clearly indicated in the title, was to establish a MIME type. I also gave a description of the JSON Data Interchange Format. My mistake was in conflating the two, putting details about the MIME type into the description of the format. My intention was to add clarity. That obviously was not the result. JSON is just a format. It describes a syntax of brackets and commas that is useful in many contexts, profiles, and applications. JSON is agnostic about all of that stuff. JSON shouldn't even care about character encoding. Its only dependence on Unicode in the hex numbers used in the \u notation. JSON can be encoded in ASCII or EBCDIC or even Hollerith codes. JSON can be used in contexts where there is no character encoding at all, such as paper documents and marble monuments. There are uses of JSON however in which such choices matter, and where behavior needs to be attached to or derived from the syntax. That is important stuff, and it belongs in different documents. Such documents will place necessary restrictions on JSON's potential. No such document can fit all applications, which causes much of the controversy we've seen here. One size cannot fit all. JSON the format is universal. But real applications require reasonable restrictions. So we should be working on at least two documents, which is something we have discussed earlier. The first is The JSON Data Interchange Format, which is a simple grammar. The second is a best practices document, which recommends specific conventions of usage. From cowan@ccil.org Thu Jun 13 08:57:52 2013 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 A9EDF21F9815 for ; Thu, 13 Jun 2013 08:57:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.435 X-Spam-Level: X-Spam-Status: No, score=-3.435 tagged_above=-999 required=5 tests=[AWL=0.164, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S6aOGKMozyjl for ; Thu, 13 Jun 2013 08:57:36 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id 1852421F9967 for ; Thu, 13 Jun 2013 08:57:20 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1Un9te-0006UK-7v; Thu, 13 Jun 2013 11:57:10 -0400 Date: Thu, 13 Jun 2013 11:57:10 -0400 From: John Cowan To: Douglas Crockford Message-ID: <20130613155710.GB29284@mercury.ccil.org> References: <51B9EA49.2050604@crockford.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <51B9EA49.2050604@crockford.com> User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Cc: "json@ietf.org" Subject: Re: [Json] Two Documents X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 13 Jun 2013 15:57:52 -0000 Douglas Crockford scripsit: > The confusion and controversy around this work is due to a mistake > that I made in RFC 4627. The purpose of the RFC, which is clearly > indicated in the title, was to establish a MIME type. I also gave > a description of the JSON Data Interchange Format. My mistake was > in conflating the two, putting details about the MIME type into the > description of the format. My intention was to add clarity. That > obviously was not the result. Indeed. > So we should be working on at least two documents, which is something > we have discussed earlier. The first is The JSON Data Interchange > Format, which is a simple grammar. The second is a best practices > document, which recommends specific conventions of usage. Fine, but the definition of the application/json media type can't be exiled to a BCP. It either has to be in a separate standards-track RFC, or needs to be in the same RFC as the definition of JSON format but in a different section of it. The latter strikes me as more sensible. -- John Cowan cowan@ccil.org "You need a change: try Canada" "You need a change: try China" --fortune cookies opened by a couple that I know From douglas@crockford.com Thu Jun 13 09:12:15 2013 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 EE1D821F9A1C for ; Thu, 13 Jun 2013 09:12:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5QpR7YjDpO7j for ; Thu, 13 Jun 2013 09:12:10 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id 1158721F994F for ; Thu, 13 Jun 2013 09:12:09 -0700 (PDT) Received: from [192.168.115.232] ([216.113.168.135]) by mrelay.perfora.net (node=mrus0) with ESMTP (Nemesis) id 0MGTYO-1UZwij2o1w-00DHxO; Thu, 13 Jun 2013 12:12:08 -0400 Message-ID: <51B9EF43.3020700@crockford.com> Date: Thu, 13 Jun 2013 09:11:47 -0700 From: Douglas Crockford User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: John Cowan References: <51B9EA49.2050604@crockford.com> <20130613155710.GB29284@mercury.ccil.org> In-Reply-To: <20130613155710.GB29284@mercury.ccil.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V02:K0:q9gQNVukztCqEixs4PW3O8HewRg4QQvpZwKQBzpFDMQ k1LRssluhBQcjz7HWaFOBsMyMVyX0r8v+e2MX1sf7JXAOLlhJN uKZz7ahmHBpqGk8OaAvJX+LcxB36yqWlOe/ZiX71fpoEpRh2lr X7DLD4oif8mqaSzklkb+RUfOLZePVoTdlex06ySojqbbsBK8CO Q7ZNzb0RB/DIiRNlJnGASMf05YblPIKPbiqcEDxUztFHLOHpg0 xLPHzT8TeRUDHRp3VCTY2efN70cX8QdLUfHVOcM29VHTYS23qj cqfONveaUtf5yY4ESq70035vbZHhs82KoU68GtUeXLouoBKuHS AgB+nnAgiTBfpA8wHCUikT55plrdjqGVeCF7XvuoT Cc: "json@ietf.org" Subject: Re: [Json] Two Documents X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 13 Jun 2013 16:12:16 -0000 On 6/13/2013 8:57 AM, John Cowan wrote: > Douglas Crockford scripsit: > >> The confusion and controversy around this work is due to a mistake >> that I made in RFC 4627. The purpose of the RFC, which is clearly >> indicated in the title, was to establish a MIME type. I also gave >> a description of the JSON Data Interchange Format. My mistake was >> in conflating the two, putting details about the MIME type into the >> description of the format. My intention was to add clarity. That >> obviously was not the result. > Indeed. > >> So we should be working on at least two documents, which is something >> we have discussed earlier. The first is The JSON Data Interchange >> Format, which is a simple grammar. The second is a best practices >> document, which recommends specific conventions of usage. > Fine, but the definition of the application/json media type can't be > exiled to a BCP. It either has to be in a separate standards-track RFC, > or needs to be in the same RFC as the definition of JSON format but in a > different section of it. The latter strikes me as more sensible. > I think it will be better for ECMA that application/json be in a separate document. ECMA does not appear to be concerned with the maintenance of MIME types. From erights@gmail.com Thu Jun 13 09:21:54 2013 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 4A41C21F9944 for ; Thu, 13 Jun 2013 09:21:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.932 X-Spam-Level: X-Spam-Status: No, score=-1.932 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m6g1q8AH5K9I for ; Thu, 13 Jun 2013 09:21:50 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4CDCA21F946C for ; Thu, 13 Jun 2013 09:21:46 -0700 (PDT) Received: by mail-vc0-f172.google.com with SMTP id ib11so7307301vcb.17 for ; Thu, 13 Jun 2013 09:21:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=AE5NjfGiDP2X55FHi5AXLxIJXWSYhgAAFakG5CFbHsg=; b=brxWeB+ZKtk9m9PWPyf1NFH0KaPEmzY7lrOJFzpGy0BAOMILVauPyHEPE92Lwz4nEb GBsgJYU45chh0dBwFjdzUy4npv42twfIOhYAttfsHqxGu8zRWteszk8HiNBFJvtYrmvd FvNgmJHnAAc0ZkoUhGvvDVdZwAZ6OyEHLJ1Ly9Cqzo1gn4NbDLV7WzXJjnIkUbZT2N3o owg+2bn1KujjjsyqzUhiOpUkZDIM6+sd0e+VA4ZqAFzd/v/AcCrnZ/RskV+/PgXSR//r SYhl03eOaUVw9qqtlLBie0shOaw4LMplR2Nq/hr8BwFZ6qh2S1Siejq2A01+W7ZjsTbH xFIw== MIME-Version: 1.0 X-Received: by 10.220.123.131 with SMTP id p3mr648913vcr.69.1371140506399; Thu, 13 Jun 2013 09:21:46 -0700 (PDT) Received: by 10.52.0.202 with HTTP; Thu, 13 Jun 2013 09:21:46 -0700 (PDT) In-Reply-To: <51B9EF43.3020700@crockford.com> References: <51B9EA49.2050604@crockford.com> <20130613155710.GB29284@mercury.ccil.org> <51B9EF43.3020700@crockford.com> Date: Thu, 13 Jun 2013 09:21:46 -0700 Message-ID: From: Mark Miller To: Douglas Crockford Content-Type: multipart/alternative; boundary=089e013cbb22d23bf504df0b8625 Cc: John Cowan , "json@ietf.org" Subject: Re: [Json] Two Documents X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 13 Jun 2013 16:21:54 -0000 --089e013cbb22d23bf504df0b8625 Content-Type: text/plain; charset=ISO-8859-1 I support separating these documents, and directing the present activity towards standardizing the JSON Data Interchange Format. I agree that this focuses the activity on which IETF and ECMA need coordinate. On Thu, Jun 13, 2013 at 9:11 AM, Douglas Crockford wrote: > > On 6/13/2013 8:57 AM, John Cowan wrote: > >> Douglas Crockford scripsit: >> >> The confusion and controversy around this work is due to a mistake >>> that I made in RFC 4627. The purpose of the RFC, which is clearly >>> indicated in the title, was to establish a MIME type. I also gave >>> a description of the JSON Data Interchange Format. My mistake was >>> in conflating the two, putting details about the MIME type into the >>> description of the format. My intention was to add clarity. That >>> obviously was not the result. >>> >> Indeed. >> >> So we should be working on at least two documents, which is something >>> we have discussed earlier. The first is The JSON Data Interchange >>> Format, which is a simple grammar. The second is a best practices >>> document, which recommends specific conventions of usage. >>> >> Fine, but the definition of the application/json media type can't be >> exiled to a BCP. It either has to be in a separate standards-track RFC, >> or needs to be in the same RFC as the definition of JSON format but in a >> different section of it. The latter strikes me as more sensible. >> >> I think it will be better for ECMA that application/json be in a > separate document. > ECMA does not appear to be concerned with the maintenance of MIME types. > > ______________________________**_________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/**listinfo/json > -- Text by me above is hereby placed in the public domain Cheers, --MarkM --089e013cbb22d23bf504df0b8625 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I support separating these documents, and directing the pr= esent activity towards standardizing the JSON Data Interchange Format. I ag= ree that this focuses the activity on which IETF and ECMA need coordinate.<= br>



On Thu, Jun 13, 2013 at 9:11 AM, Douglas Crockford <douglas@cr= ockford.com> wrote:

On 6/13/2013 8:57 AM, John Cowan wrote:
Douglas Crockford scripsit:

The confusion and controversy around this work is due to a mistake
that I made in RFC 4627. The purpose of the RFC, which is clearly
indicated in the title, was to establish a MIME type. I also gave
a description of the JSON Data Interchange Format. My mistake was
in conflating the two, putting details about the MIME type into the
description of the format. My intention was to add clarity. That
obviously was not the result.
Indeed.

So we should be working on at least two documents, which is something
we have discussed earlier. The first is The JSON Data Interchange
Format, which is a simple grammar. The second is a best practices
document, which recommends specific conventions of usage.
Fine, but the definition of the application/json media type can't be exiled to a BCP. =A0It either has to be in a separate standards-track RFC,<= br> or needs to be in the same RFC as the definition of JSON format but in a different section of it. =A0The latter strikes me as more sensible.

I think it will be better for ECMA that application/json be in a separate d= ocument.
ECMA does not appear to be concerned with the maintenance of MIME types.

_______________________________________________
json mailing list
json@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/json



--
= Text by me above is hereby placed in the public domain

=A0 Cheers,=A0 --MarkM
--089e013cbb22d23bf504df0b8625-- From markus.lanthaler@gmx.net Thu Jun 13 09:50:35 2013 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 6129921F99B7 for ; Thu, 13 Jun 2013 09:50:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.15 X-Spam-Level: X-Spam-Status: No, score=-1.15 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hhg1-U-b4ABZ for ; Thu, 13 Jun 2013 09:50:29 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) by ietfa.amsl.com (Postfix) with ESMTP id 310CB21F96FE for ; Thu, 13 Jun 2013 09:50:29 -0700 (PDT) Received: from mailout-de.gmx.net ([10.1.76.29]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0MWMYG-1UpnLp1en4-00XdLv for ; Thu, 13 Jun 2013 18:50:23 +0200 Received: (qmail invoked by alias); 13 Jun 2013 16:50:23 -0000 Received: from 84-115-182-43.dynamic.surfer.at (EHLO Vostro3500) [84.115.182.43] by mail.gmx.net (mp029) with SMTP; 13 Jun 2013 18:50:23 +0200 X-Authenticated: #419883 X-Provags-ID: V01U2FsdGVkX19tAAIfurttwLjvA6E7ZVbfLYHfd/kuS8bZ04f/gB OIpivw+rorFKUJ From: "Markus Lanthaler" To: References: <51B9EA49.2050604@crockford.com> <20130613155710.GB29284@mercury.ccil.org> In-Reply-To: <20130613155710.GB29284@mercury.ccil.org> Date: Thu, 13 Jun 2013 18:50:14 +0200 Message-ID: <00f801ce6856$165d6a20$43183e60$@lanthaler@gmx.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac5oTsV3cTj774IyQv+Igrlslzeq+AABu9hQ Content-Language: de X-Y-GMX-Trusted: 0 Subject: Re: [Json] Two Documents X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 13 Jun 2013 16:50:35 -0000 On Thursday, June 13, 2013 5:57 PM, John Cowan wrote: > Douglas Crockford scripsit: > > So we should be working on at least two documents, which is something > > we have discussed earlier. The first is The JSON Data Interchange > > Format, which is a simple grammar. The second is a best practices > > document, which recommends specific conventions of usage. > > Fine, but the definition of the application/json media type can't be > exiled to a BCP. It either has to be in a separate standards-track > RFC, or needs to be in the same RFC as the definition of JSON format > but in a different section of it. The latter strikes me as more > sensible. +1 and I also think that it makes more sense to put the media type definition in the same RFC. -- Markus Lanthaler @markuslanthaler From tbray@textuality.com Thu Jun 13 09:55:07 2013 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 88EE921F8CDD for ; Thu, 13 Jun 2013 09:55:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.338 X-Spam-Level: X-Spam-Status: No, score=0.338 tagged_above=-999 required=5 tests=[AWL=-1.780, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_SORBS_DUL=0.877, RDNS_NONE=0.1, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RKPC0sql0AqM for ; Thu, 13 Jun 2013 09:55:03 -0700 (PDT) Received: from mail-ve0-x22e.google.com (mail-ve0-x22e.google.com [IPv6:2607:f8b0:400c:c01::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 42D3121F8994 for ; Thu, 13 Jun 2013 09:55:03 -0700 (PDT) Received: by mail-ve0-f174.google.com with SMTP id oz10so7852693veb.5 for ; Thu, 13 Jun 2013 09:55:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=ocwRCviSsOEPXLRlhbT362UaEYU/w0cpzjEcNuz3Ciw=; b=MKb2oRPK+9jkXg+jeDAV3uDXO7+6fsM50LgWX7M4SbTSLFLBnpArCMsNKnfYbpQjFG G+E/eakVXl0zVylKcFjMhfIF/pm38oR2xtFOKm5vdM2siQwQyCy3iBL3o9Mn1b0+8OQW fONnAvrHY9YcwjGtvxdF5ACh/8R/ilbBHbDqKYfGBtd264X7iB2Lbdek8L95mcQvzNYj SDAHvqw9rYeccpKfrrCg3SG+ydl1qLSlOP9ooTlw7JpAqS30pwl02xX3n0Bwpd3xUrCx MpTGq515+SbaZuz057XTYwO3luSicLzsURMO9BnFuByEXRAaEnCD8OZTqMJuQpu2aI8F 1nzA== MIME-Version: 1.0 X-Received: by 10.58.40.42 with SMTP id u10mr727091vek.39.1371142502482; Thu, 13 Jun 2013 09:55:02 -0700 (PDT) Received: by 10.220.25.199 with HTTP; Thu, 13 Jun 2013 09:55:02 -0700 (PDT) X-Originating-IP: [96.49.81.176] In-Reply-To: <51B9EA49.2050604@crockford.com> References: <51B9EA49.2050604@crockford.com> Date: Thu, 13 Jun 2013 09:55:02 -0700 Message-ID: From: Tim Bray To: Douglas Crockford Content-Type: multipart/alternative; boundary=089e0129420ccc18a504df0bfdbe X-Gm-Message-State: ALoCoQkYs7HgJ99wRqV/Jypx7xNRbVup5C5ECnnpfUwDDGpPmbVmqS1+G3/8brrk8pAQqC3XdXai Cc: "json@ietf.org" Subject: Re: [Json] Two Documents X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 13 Jun 2013 16:55:07 -0000 --089e0129420ccc18a504df0bfdbe Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I think we have widely-shared agreement on two documents, a JSON spec and a best-practices doc. Just a word of caution, though: Our profession has ample experience with the notion of =E2=80=9Cabstract syntax=E2=80=9D - in = ASN.1 and in SGML. Neither of which ever exhibited good usability in Internet protocols. One of the central defining virtues of the Internet and the Web is that there are no object models or APIs, just messages. It is the job of the IETF to define the message formats and interchange patterns. Which is to say, a document that defines a syntax but omits discussion of how that syntax is expressed in bytes for transmission on the wire is not really appropriate subject matter for the IETF. The end-goal is pretty clear, I think: As someone who regularly works on the design of network protocols based on JSON, I want an RFC to turn to that will have nice crisp definitions of =E2=80=9CJSON text=E2=80=9D, =E2= =80=9Cobject=E2=80=9D, =E2=80=9Carray=E2=80=9D, =E2=80=9Cstring=E2=80=9D, =E2=80=9Cnumber=E2=80=9D and =E2=80=9Cboolean=E2= =80=9D so I can use those confidently in my protocol design, and also sufficient precision about byte encoding that I can rely on infrastructure builders to have created interoperable libraries that work well on a variety of platforms and architectures. It would also be nice if there were a best-practices document so that someone could review my design and berate me for something stupid like allowing the use of duplicate keys, and have something to point to. So... two documents, yes. Abstract syntax, no. -T On Thu, Jun 13, 2013 at 8:50 AM, Douglas Crockford w= rote: > The confusion and controversy around this work is due to a mistake that I > made in RFC 4627. The purpose of the RFC, which is clearly indicated > in the title, was to establish a MIME type. I also gave a description of > the JSON Data Interchange Format. My mistake was in conflating the two, > putting details about the MIME type into the description of the format. M= y > intention was to add clarity. That obviously was not the result. > > JSON is just a format. It describes a syntax of brackets and commas that > is useful in many contexts, profiles, and applications. JSON is agnostic > about all of that stuff. JSON shouldn't even care about character encodin= g. > Its only dependence on Unicode in the hex numbers used in the \u notation= . > JSON can be encoded in ASCII or EBCDIC or even Hollerith codes. JSON can > be used in contexts where there is no character encoding at all, such as > paper documents and marble monuments. > > There are uses of JSON however in which such choices matter, and where > behavior needs to be attached to or derived from the syntax. That is > important stuff, and it belongs in different documents. Such documents > will place necessary restrictions on JSON's potential. No such document > can fit all applications, which causes much of the controversy we've seen > here. One size cannot fit all. JSON the format is universal. But real > applications require reasonable restrictions. > > So we should be working on at least two documents, which is something we > have > discussed earlier. The first is The JSON Data Interchange Format, which i= s > a simple grammar. The second is a best practices document, which recommen= ds > specific conventions of usage. > > ______________________________**_________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/**listinfo/json > --089e0129420ccc18a504df0bfdbe Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I think we have widely-shared agr= eement on two documents, a JSON spec and a best-practices doc.=C2=A0 Just a= word of caution, though: Our profession has ample experience with the noti= on of =E2=80=9Cabstract syntax=E2=80=9D - in ASN.1 and in SGML.=C2=A0 Neith= er of which ever exhibited good usability in Internet protocols.=C2=A0

One of the central defining virtues of the Internet and the Web is that= there are no object models or APIs, just messages. It is the job of the IE= TF to define the message formats and interchange patterns.=C2=A0 Which is t= o say, a document that defines a syntax but omits discussion of how that sy= ntax is expressed in bytes for transmission on the wire is not really appro= priate subject matter for the IETF.=C2=A0

The end-goal is pretty clear, I think: As someone who regul= arly works on the design of network protocols based on JSON, I want an RFC = to turn to that will have nice crisp definitions of =E2=80=9CJSON text=E2= =80=9D, =E2=80=9Cobject=E2=80=9D, =E2=80=9Carray=E2=80=9D, =E2=80=9Cstring= =E2=80=9D, =E2=80=9Cnumber=E2=80=9D and =E2=80=9Cboolean=E2=80=9D so I can = use those confidently in my protocol design, and also sufficient precision = about byte encoding that I can rely on infrastructure builders to have crea= ted interoperable libraries that work well on a variety of platforms and ar= chitectures.

It would also be nice if there were a best-practices document so = that someone could review my design and berate me for something stupid like= allowing the use of duplicate keys, and have something to point to.

So... two documents, yes.=C2=A0 Abstract syntax, no.

=C2=A0-T


= On Thu, Jun 13, 2013 at 8:50 AM, Douglas Crockford <douglas@crockford.= com> wrote:
The confusion and controversy around this wo= rk is due to a mistake that I
made in RFC 4627. The purpose of the RFC, which is clearly indicated
in the title, was to establish a MIME type. I also gave a description of the JSON Data Interchange Format. My mistake was in conflating the two,
putting details about the MIME type into the description of the format. My<= br> intention was to add clarity. That obviously was not the result.

JSON is just a format. It describes a syntax of brackets and commas that is useful in many contexts, profiles, and applications. JSON is agnostic about all of that stuff. JSON shouldn't even care about character encod= ing.
Its only dependence on Unicode in the hex numbers used in the \u notation.<= br> JSON can be encoded in ASCII or EBCDIC or even Hollerith codes. JSON can be used in contexts where there is no character encoding at all, such as paper documents and marble monuments.

There are uses of JSON however in which such choices matter, and where
behavior needs to be attached to or derived from the syntax. That is
important stuff, and it belongs in different documents. Such documents
will place necessary restrictions on JSON's potential. No such document=
can fit all applications, which causes much of the controversy we've se= en
here. One size cannot fit all. JSON the format is universal. But real
applications require reasonable restrictions.

So we should be working on at least two documents, which is something we ha= ve
discussed earlier. The first is The JSON Data Interchange Format, which is<= br> a simple grammar. The second is a best practices document, which recommends=
specific conventions of usage.

_______________________________________________
json mailing list
json@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/json

--089e0129420ccc18a504df0bfdbe-- From jhildebr@cisco.com Thu Jun 13 10:46:41 2013 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 8B58521F99D5 for ; Thu, 13 Jun 2013 10:46:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2iMDZVwbXdVI for ; Thu, 13 Jun 2013 10:46:36 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id EA39321F99DA for ; Thu, 13 Jun 2013 10:46:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=485; q=dns/txt; s=iport; t=1371145596; x=1372355196; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=ZSiZcAxCj5un3AEAviuBSyWUtQMAicS60Jmr0assXck=; b=ITlE5QmhEjysUUH62/MQG3glr173Brn5pTQDy77vkA8z/TMOIWOWfhA9 2yyLo4IqJIRhHDTq7Z6SLwJkQXbFaJwFwO6z1AcRyzdsbempeOLQ7gPHW OOFHZEME518vYZlQf2on1XVIqSgDaIJ4+aoI8vpplLMhFei0cEsuXTdYA A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: An0FAC0FulGtJXG//2dsb2JhbABbgwl5gi28EIECFnSCJQEEOj8SAQgiFEIlAgQBDQUIiAa7T48SMQeCf2EDqQODD4In X-IronPort-AV: E=Sophos;i="4.87,860,1363132800"; d="scan'208";a="222288513" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-1.cisco.com with ESMTP; 13 Jun 2013 17:46:33 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r5DHkW6n025280 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 13 Jun 2013 17:46:32 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.56]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.02.0318.004; Thu, 13 Jun 2013 12:46:32 -0500 From: "Joe Hildebrand (jhildebr)" To: John Cowan , Bjoern Hoehrmann Thread-Topic: [Json] Proposal for strings/Unicode text Thread-Index: AQHOZ51Gb76aHFDldEuIrE325m6ppJkzAdeAgAAdpYCAAKLpAIAAIdEA///3qYA= Date: Thu, 13 Jun 2013 17:46:32 +0000 Message-ID: In-Reply-To: <20130613121620.GB11739@mercury.ccil.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [10.21.148.31] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "json@ietf.org" Subject: Re: [Json] Proposal for strings/Unicode text X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 13 Jun 2013 17:46:41 -0000 On 6/13/13 6:16 AM, "John Cowan" wrote: >The point is that if JSON is encoded in UTF-8, any surrogate code points >MUST be escaped, even though the grammar does not say so. What about changing the grammar to make that clear? unescaped =3D %x20-21 / %x23-5B / %x5D-%xD7FF / %E000-%10FFFF ; Any unicode code point except control characters, QUOTATION MARK, ; REVERSE SOLIDUS, or code points reserved for UTF-16 surrogates --=20 Joe Hildebrand From tbray@textuality.com Thu Jun 13 11:00:24 2013 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 F16D121F9A42 for ; Thu, 13 Jun 2013 11:00:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.358 X-Spam-Level: X-Spam-Status: No, score=-0.358 tagged_above=-999 required=5 tests=[AWL=-0.810, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_SORBS_DUL=0.877, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zy77PsuRkITb for ; Thu, 13 Jun 2013 11:00:20 -0700 (PDT) Received: from mail-ve0-x235.google.com (mail-ve0-x235.google.com [IPv6:2607:f8b0:400c:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id F1A8821F9A33 for ; Thu, 13 Jun 2013 11:00:19 -0700 (PDT) Received: by mail-ve0-f181.google.com with SMTP id db10so7921041veb.40 for ; Thu, 13 Jun 2013 11:00:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=+SPO6eIzlHiq8ghNhkVgM/ajkyYlt+mNRDRi3yPZTGo=; b=RJaGDSMOvnKiBuhVUHW5tB7PTXsK1wCS2tEX/rNbVEfBI2Qkv/3/vs+QvY4BZ2lSBB ydWzCP89Ov6jEuQIIvuCgbYvAxCqVQtUOR+CeViWrf5nhNY13I5+FGqJiNXvkC5sEcI7 mFFmiOYdP3Ib4wH+D3YauReoqQzKp3KfdPCSkUwg6i09NL6NsMSEiPAWRRpgj4YubBzk PDkrU2/wenBkosw8yKQP3Wrmg6ZVsPKB/lk66yvXhMzKcfnLpV+zErBlg6fJ/7zbGxkk avy/bRMLnpiR714hPoEDw5ikB4hUrn7lpHsKSkCLBHOyPqdzxq6HF1ZkTyPv5o5AS3g9 ARmw== MIME-Version: 1.0 X-Received: by 10.58.236.42 with SMTP id ur10mr819419vec.48.1371146419391; Thu, 13 Jun 2013 11:00:19 -0700 (PDT) Received: by 10.220.25.199 with HTTP; Thu, 13 Jun 2013 11:00:19 -0700 (PDT) X-Originating-IP: [96.49.81.176] In-Reply-To: <20130613121620.GB11739@mercury.ccil.org> References: <20130613003213.GA26989@mercury.ccil.org> <20130613121620.GB11739@mercury.ccil.org> Date: Thu, 13 Jun 2013 11:00:19 -0700 Message-ID: From: Tim Bray To: John Cowan Content-Type: multipart/alternative; boundary=047d7bd6ac2a435eb604df0ce74c X-Gm-Message-State: ALoCoQm8nFYkacyqxRSvkPQNkUzWlIcPc5+rUe9eGjGaaWBQ+wj3hLZ6YtxtOx8/qqePW1m+estL Cc: Bjoern Hoehrmann , "json@ietf.org" Subject: Re: [Json] Proposal for strings/Unicode text X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 13 Jun 2013 18:00:24 -0000 --047d7bd6ac2a435eb604df0ce74c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Jun 13, 2013 at 5:16 AM, John Cowan wrote: > The point is that if JSON is encoded in UTF-8, any surrogate code points > MUST be escaped, even though the grammar does not say so. > Why? UTF-8 is perfectly capable of representing those integers. Yes, the spec says that You Shouldn=E2=80=99t Do That, but it says the same thing ab= out unpaired surrogates in UTF-16. For historical reasons JSON allows the encoding of stuff that is strictly nonconforming to Unicode. This will break lots of things, not just UTF-8 decoders (most of which, I bet, will never actually notice). -T > > -- > John Cowan http://www.ccil.org/~cowan cowan@ccil.org > Uneasy lies the head that wears the Editor's hat! --Eddie Foirbeis Climo > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > --047d7bd6ac2a435eb604df0ce74c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, Jun 13, 2013 at 5:16 AM, John Cowan <cowan@m= ercury.ccil.org> wrote:
The point is that if JSON is encoded in UTF-= 8, any surrogate code points
MUST be escaped, even though the grammar does not say so.
<= div>
Why?=C2=A0 UTF-8 is perfectly capable of representing th= ose integers.=C2=A0 Yes, the spec says that You Shouldn=E2=80=99t Do That, = but it says the same thing about unpaired surrogates in UTF-16.=C2=A0 For h= istorical reasons JSON allows the encoding of stuff that is strictly noncon= forming to Unicode.=C2=A0 This will break lots of things, not just UTF-8 de= coders (most of which, I bet, will never actually notice).=C2=A0 -T

=C2=A0

--
John Cowan =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0http://www.ccil.org/~cowan =C2=A0 =C2= =A0 cowan@ccil.org
Uneasy lies the head that wears the Editor's hat! --Eddie Foirbeis Clim= o
_____________________= __________________________
json mailing list
json@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/json

--047d7bd6ac2a435eb604df0ce74c-- From nico@cryptonector.com Thu Jun 13 11:16:16 2013 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 33DF421F9A03 for ; Thu, 13 Jun 2013 11:16:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.963 X-Spam-Level: X-Spam-Status: No, score=-1.963 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Mcklvxeoq4M for ; Thu, 13 Jun 2013 11:16:11 -0700 (PDT) Received: from homiemail-a16.g.dreamhost.com (mailbigip.dreamhost.com [208.97.132.5]) by ietfa.amsl.com (Postfix) with ESMTP id 448E621F9A06 for ; Thu, 13 Jun 2013 11:16:11 -0700 (PDT) Received: from homiemail-a16.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a16.g.dreamhost.com (Postfix) with ESMTP id CA528508084 for ; Thu, 13 Jun 2013 11:16:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=plu8huskcP1UOSQAMTNy6oXrI5A=; b=hpLIlX7wHR7 nVlGHft9NY1vWEKlwT4IrzXKL3CSkF3DZ6nNGT9Q4XNBdgoWkkeXTZWSKCydWfhO Ue1RYKDUUGHCISCN/Umpf3hTxtxIFkuWdOfp44bVMRl6B2PtxwJAT/4Bm+D0uASI 5qLyWI8bas/aGRYPW354vgel1+d2In9U= Received: from mail-we0-f169.google.com (mail-we0-f169.google.com [74.125.82.169]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a16.g.dreamhost.com (Postfix) with ESMTPSA id 78FC9508064 for ; Thu, 13 Jun 2013 11:16:10 -0700 (PDT) Received: by mail-we0-f169.google.com with SMTP id n57so8392492wev.28 for ; Thu, 13 Jun 2013 11:16:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=P2cKPkHZa46zCdVgDnLM3arVwEd/Lexrl4pACs5S2Jw=; b=lG6ckVizx2xvErUrelDXjg8teBAJrRm6nNmfpDtKJdcan6jRH/QIjSXJgCWWXHmFoS fYjrUdlOPNaJqIVcEXZftH5fUJumgoSrUJ/iIQoYaG3dNQbuar1jDFnQwSGlzHe8F5IQ xwASL6E/eRaLfBxD7IOrPJA9JugXfKtjEan2YRlMdnXvVGXhgTODgsePgtmx47JA/Viu Q8aTjYcHZPSNpu2UcwVv7m/PQk/fHlnEDWpY2C5v0kWdYujmb99OT/40k/m7v2mDII62 J2jjbyuziXcOkQjTMXA8pDOeqy/Xb0n8IhpJsdu+ijy6DnlSYRlNOfODizTmwYIRvveU faSg== MIME-Version: 1.0 X-Received: by 10.180.109.195 with SMTP id hu3mr1311679wib.13.1371147369060; Thu, 13 Jun 2013 11:16:09 -0700 (PDT) Received: by 10.216.63.136 with HTTP; Thu, 13 Jun 2013 11:16:08 -0700 (PDT) In-Reply-To: References: <20130613003213.GA26989@mercury.ccil.org> <20130613121620.GB11739@mercury.ccil.org> Date: Thu, 13 Jun 2013 13:16:08 -0500 Message-ID: From: Nico Williams To: Tim Bray Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Bjoern Hoehrmann , John Cowan , "json@ietf.org" Subject: Re: [Json] Proposal for strings/Unicode text X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 13 Jun 2013 18:16:16 -0000 On Thu, Jun 13, 2013 at 1:00 PM, Tim Bray wrote: > On Thu, Jun 13, 2013 at 5:16 AM, John Cowan wrot= e: >> The point is that if JSON is encoded in UTF-8, any surrogate code points >> MUST be escaped, even though the grammar does not say so. > > Why? UTF-8 is perfectly capable of representing those integers. Yes, th= e > spec says that You Shouldn=E2=80=99t Do That, but it says the same thing = about > unpaired surrogates in UTF-16. For historical reasons JSON allows the > encoding of stuff that is strictly nonconforming to Unicode. This will > break lots of things, not just UTF-8 decoders (most of which, I bet, will > never actually notice). -T I was thinking the same thing. We're way into "you shouldn't do that but actually, look, you can" territory. I think it's important that some \uXXXX sequences not be unescaped by intermediaries, or, rather, that certain code points always be escaped by encoders. E.g., \u0000, \u2028, \uD800, and so on. The reason is that a parser may not be able to handle such code points unescaped. We should stop at that and otherwise allow just about any code point. Nico -- From cowan@ccil.org Thu Jun 13 11:20:12 2013 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 D3D5621F8EB3 for ; Thu, 13 Jun 2013 11:20:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.139 X-Spam-Level: X-Spam-Status: No, score=-3.139 tagged_above=-999 required=5 tests=[AWL=-0.140, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CQB5JKUX2hmH for ; Thu, 13 Jun 2013 11:19:57 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id A213A21F881F for ; Thu, 13 Jun 2013 11:19:57 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1UnC7n-0004iT-HR; Thu, 13 Jun 2013 14:19:55 -0400 Date: Thu, 13 Jun 2013 14:19:55 -0400 From: John Cowan To: Tim Bray Message-ID: <20130613181955.GH29284@mercury.ccil.org> References: <20130613003213.GA26989@mercury.ccil.org> <20130613121620.GB11739@mercury.ccil.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Cc: Bjoern Hoehrmann , "json@ietf.org" Subject: Re: [Json] Proposal for strings/Unicode text X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 13 Jun 2013 18:20:13 -0000 Tim Bray scripsit: > Why? UTF-8 is perfectly capable of representing those integers. Yes, the > spec says that You Shouldn’t Do That, but it says the same thing about > unpaired surrogates in UTF-16. If this is going to be just another informational RFC, then of course we can do what we want. But if it's a standards-track RFC, it has to play nicely with other standards-track RFCs. And RFC 3629 aka STD 63 is not just standards-track, it's an Internet Standard, it's ten years old, and it says uncompromisingly: The definition of UTF-8 prohibits encoding character numbers between U+D800 and U+DFFF, which are reserved for use with the UTF-16 encoding form (as surrogate pairs) and do not directly represent characters. When encoding in UTF-8 from UTF-16 data, it is necessary to first decode the UTF-16 data to obtain character numbers, which are then encoded in UTF-8 as described above. This contrasts with CESU-8 [CESU-8], which is a UTF-8-like encoding that is not meant for use on the Internet. CESU-8 operates similarly to UTF-8 but encodes the UTF-16 code values (16-bit quantities) instead of the character number (code point). This leads to different results for character numbers above 0xFFFF; the CESU-8 encoding of those characters is NOT valid UTF-8. The Unicode definition today is the same, though in the past it's been more wishy-washy. (CESU-8, BTW, is the official name for Oracle's and MySQL's "UTF-8" encoding for database strings: the real thing is called "AL32UTF8" and "utf8mb4" in Oracle and MySQL respectively.) > This will break lots of things, not just UTF-8 decoders (most of which, > I bet, will never actually notice). -T Modern ones that pay attention to spoofing most definitely will. -- John Cowan cowan@ccil.org "You need a change: try Canada" "You need a change: try China" --fortune cookies opened by a couple that I know From cabo@tzi.org Thu Jun 13 13:56:09 2013 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 2AD3521F9977 for ; Thu, 13 Jun 2013 13:56:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.18 X-Spam-Level: X-Spam-Status: No, score=-106.18 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J4Jt2NHRDXZn for ; Thu, 13 Jun 2013 13:56:03 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id A730821F9AE6 for ; Thu, 13 Jun 2013 13:56:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r5DKtrjn029535; Thu, 13 Jun 2013 22:55:53 +0200 (CEST) Received: from [192.168.217.105] (p54893550.dip0.t-ipconnect.de [84.137.53.80]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 69DA6360E; Thu, 13 Jun 2013 22:55:53 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: Date: Thu, 13 Jun 2013 22:55:52 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <6B248CB6-BDD2-4A24-B69D-FB7A29EEF27F@tzi.org> References: <51B9EA49.2050604@crockford.com> To: Tim Bray X-Mailer: Apple Mail (2.1508) Cc: Douglas Crockford , "json@ietf.org" Subject: Re: [Json] Two Documents X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 13 Jun 2013 20:56:09 -0000 On Jun 13, 2013, at 18:55, Tim Bray wrote: > So... two documents, yes. Abstract syntax, no. +1 The JSON data interchange format has no use if it is floating in the = air. It must have both feet firmly on the ground, in concrete syntax, in bits = and bytes. (And one of the feet can be RFC 3629.) RFC4627 managed to do this reasonably well, why should it suddenly be = hard? Gr=FC=DFe, Carsten From nico@cryptonector.com Thu Jun 13 14:06:03 2013 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 6F58121F9635 for ; Thu, 13 Jun 2013 14:06:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.964 X-Spam-Level: X-Spam-Status: No, score=-1.964 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4sogpVX+f9tq for ; Thu, 13 Jun 2013 14:05:58 -0700 (PDT) Received: from homiemail-a87.g.dreamhost.com (caiajhbdcbhh.dreamhost.com [208.97.132.177]) by ietfa.amsl.com (Postfix) with ESMTP id 8C80A21F9AF3 for ; Thu, 13 Jun 2013 14:05:58 -0700 (PDT) Received: from homiemail-a87.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a87.g.dreamhost.com (Postfix) with ESMTP id 46AC026C063 for ; Thu, 13 Jun 2013 14:05:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=0A9DxQuy8BbElLrHL/q1 9Y4uR6o=; b=NYXEYnBP30F1z1EHjg9cpEsomw0sLPeX7Jzk/Nx5Vnbiqy+YnY3r 8+ZZU6ULrLoPqR7ZbtiUwa20rmGFNAmQ72siQmQfA0vxZ9a9cUp5UzHUZZhV62wz W8OTM/ajdGMuUyYQx7bDUfW6HclnhZBw7sEIng0ypYUKZxIxo4v8IOg= Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a87.g.dreamhost.com (Postfix) with ESMTPSA id EB40F26C05B for ; Thu, 13 Jun 2013 14:05:57 -0700 (PDT) Received: by mail-we0-f182.google.com with SMTP id p60so6832239wes.27 for ; Thu, 13 Jun 2013 14:05:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=aY0iGNlhN/txE/pLlpr3NTyGWR5GGhUlHfDQYT2ZK9Y=; b=AUBdzu322ForrS1jCXbzlZTqqw/JRNukg2h71kXIQbh/TspOQcKfG0WqR3BbMF9Qm3 vWkyDsxHbPhJIg8aj5a75Q8oyyf1ynyeKDJvyNeo/zKC4xpQnF/jOmsuXfEWRbFv1PV+ cMzWi2pxwj13Oytk+G7z/sTBfmvCR8m7EFkmovrmDO3A+25I8sDSAV/+7Bbq0fv7jnSH FnpZqP9Z71ID9fcDAgyiiO/0Vmi7/VAosMd2QF/MjAtl/6qFsSQrqZh5+AzM8iawbqWe T+HBn9K/jqOe7Gz+MbGl4Clc7vFOnyJssXXdKcazMHb6AnRpQeCh+DK25ZjG8F/39UIh sf8Q== MIME-Version: 1.0 X-Received: by 10.180.182.83 with SMTP id ec19mr3367617wic.0.1371157556353; Thu, 13 Jun 2013 14:05:56 -0700 (PDT) Received: by 10.216.63.136 with HTTP; Thu, 13 Jun 2013 14:05:56 -0700 (PDT) In-Reply-To: <6B248CB6-BDD2-4A24-B69D-FB7A29EEF27F@tzi.org> References: <51B9EA49.2050604@crockford.com> <6B248CB6-BDD2-4A24-B69D-FB7A29EEF27F@tzi.org> Date: Thu, 13 Jun 2013 16:05:56 -0500 Message-ID: From: Nico Williams To: Carsten Bormann Content-Type: text/plain; charset=UTF-8 Cc: Tim Bray , Douglas Crockford , "json@ietf.org" Subject: Re: [Json] Two Documents X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 13 Jun 2013 21:06:03 -0000 On Thu, Jun 13, 2013 at 3:55 PM, Carsten Bormann wrote: > On Jun 13, 2013, at 18:55, Tim Bray wrote: > >> So... two documents, yes. Abstract syntax, no. To be fair "JSON in EBCDIC vs. JSON in UTF-8" are not really comparable to "ASN.1 w/ DER vs. ASN.1 w/ PER -- a difference of degree, though not of kind. :) > +1 > > The JSON data interchange format has no use if it is floating in the air. > It must have both feet firmly on the ground, in concrete syntax, in bits and bytes. > (And one of the feet can be RFC 3629.) > > RFC4627 managed to do this reasonably well, why should it suddenly be hard? It isn't. I think the talk of EBCDIC was illustrative or best taken as such. Move along, nothing to see here :) More seriously, we have to iron out the details of what strings really are. I think we must prohibit certain unescaped code points, but we must allow any 16-bit number \u-escaped. This is tied to JavaScript's handling of those code points as well as to the validity of UTF-8-encoding those code points. The best practices document should further recommend the use of proper Unicode characters only in JSON strings. Nico -- From cowan@ccil.org Thu Jun 13 14:37:03 2013 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 2719B21F9AE0 for ; Thu, 13 Jun 2013 14:37:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.435 X-Spam-Level: X-Spam-Status: No, score=-3.435 tagged_above=-999 required=5 tests=[AWL=0.164, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9BF5k1g6AUE8 for ; Thu, 13 Jun 2013 14:36:58 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id 8DED321F9301 for ; Thu, 13 Jun 2013 14:36:57 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1UnFCH-0000AC-Uw; Thu, 13 Jun 2013 17:36:46 -0400 Date: Thu, 13 Jun 2013 17:36:45 -0400 From: John Cowan To: Carsten Bormann Message-ID: <20130613213642.GD21259@mercury.ccil.org> References: <51B9EA49.2050604@crockford.com> <6B248CB6-BDD2-4A24-B69D-FB7A29EEF27F@tzi.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6B248CB6-BDD2-4A24-B69D-FB7A29EEF27F@tzi.org> User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Cc: Tim Bray , Douglas Crockford , "json@ietf.org" Subject: Re: [Json] Two Documents X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 13 Jun 2013 21:37:03 -0000 Carsten Bormann scripsit: > The JSON data interchange format has no use if it is floating in > the air. It must have both feet firmly on the ground, in concrete > syntax, in bits and bytes. A concrete syntax in characters only is not useless. Essentially all programming languages are defined only in characters, and rightly so. Even for special cases like JavaScript, it's sensible to define the repertoire used by the language, but not the encoding(s) of the language. -- My corporate data's a mess! John Cowan It's all semi-structured, no less. http://www.ccil.org/~cowan But I'll be carefree cowan@ccil.org Using XSLT On an XML DBMS. From ietf@lindenbergsoftware.com Thu Jun 13 15:47:50 2013 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 888F821F9AAC for ; Thu, 13 Jun 2013 15:47:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.624 X-Spam-Level: X-Spam-Status: No, score=-3.624 tagged_above=-999 required=5 tests=[AWL=-0.025, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jx9665Mra7N4 for ; Thu, 13 Jun 2013 15:47:45 -0700 (PDT) Received: from mirach.lunarpages.com (mirach.lunarpages.com [216.97.235.70]) by ietfa.amsl.com (Postfix) with ESMTP id 2D57721F99B0 for ; Thu, 13 Jun 2013 15:47:45 -0700 (PDT) Received: from 50-0-136-241.dsl.dynamic.sonic.net ([50.0.136.241]:58202 helo=[192.168.0.5]) by mirach.lunarpages.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1UnGIw-0049h2-B9; Thu, 13 Jun 2013 15:47:42 -0700 From: Norbert Lindenberg Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 13 Jun 2013 15:47:38 -0700 Message-Id: <6FC6B441-B74D-4B9F-B883-065C05890880@lindenbergsoftware.com> To: json@ietf.org Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - mirach.lunarpages.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - lindenbergsoftware.com X-Get-Message-Sender-Via: mirach.lunarpages.com: authenticated_id: ietf@lindenbergsoftware.com Cc: Norbert Lindenberg Subject: [Json] Scope: Wire format or runtime format? X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 13 Jun 2013 22:47:50 -0000 In looking over older messages on this list, I found a message that made = clear to me why we're having this endless discussion about Unicode = surrogates - it's because we're not clear whether we're designing a wire = format or a format that also for use at runtime: http://www.ietf.org/mail-archive/web/json/current/msg00355.html Some people are coming from the runtime point of view, especially = ECMAScript, where it's accepted practice to use ill-formed UTF-16 or = even non-text in strings. At least the ill-formed UTF-16 is legitimized = by section 2.7 of the Unicode standard. Other people are coming from the wire protocol point of view, where = clean formats are expected, in particular well-formed Unicode code unit = sequences according to section 3.9 of the Unicode standard. So which one shall it be? If we adopt the wire protocol point of view and require well-formed code = unit sequences, then ECMAScript will have to define its own extension of = JSON (which it has already by allowing JSON values at the top level). If we adopt the runtime point of view and allow all code points as in = RFC 4627, then there probably should be separate verbiage defining a = restricted version for use over the wire. Norbert= From cromis@gmail.com Thu Jun 13 16:16:11 2013 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 747B721F9B2A for ; Thu, 13 Jun 2013 16:16:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.145 X-Spam-Level: X-Spam-Status: No, score=-1.145 tagged_above=-999 required=5 tests=[AWL=-0.834, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tUeL2YcpfmI7 for ; Thu, 13 Jun 2013 16:16:10 -0700 (PDT) Received: from mail-qc0-x22b.google.com (mail-qc0-x22b.google.com [IPv6:2607:f8b0:400d:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 8FBFA21F9B1A for ; Thu, 13 Jun 2013 16:16:10 -0700 (PDT) Received: by mail-qc0-f171.google.com with SMTP id n1so2739985qcw.16 for ; Thu, 13 Jun 2013 16:16:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=I+IPaPwm62fSm5e3E66GQ6NbZI/FutKnrmJR22+/oOo=; b=GHLz2quwMWfXZIvjUr9HDBlxcm3sEUggoQMiZsRyrXliV4TzlVKcfgV+sWEGIXkmOi r12RxMEaOtwDSIRR+CH9i0E7xntV1rpRlT+jZjpEyMy67mYrmuz5Lnm6A8ierD6gVXRt cycTob4v1tedC8kZya6dbmL1p2zHjANnd6bkGUoW/dkmFaQV5crk8f9l34JDa7H0+lM+ /eNQhpQDIMu9+DbBcxGjpLY6hlazsgX9GRPeihyZ+f8Wuws3hxGGeZD8G+fmasM5KXWj g3I+NOKYYUeJZdvu7Lb8ZLz0BHlMhl+03So/XFgF8RL4yx6kpyhlyGeSnhlOXsU6wsii b/2Q== X-Received: by 10.224.205.8 with SMTP id fo8mr5373443qab.62.1371165369844; Thu, 13 Jun 2013 16:16:09 -0700 (PDT) MIME-Version: 1.0 Sender: cromis@gmail.com Received: by 10.49.106.228 with HTTP; Thu, 13 Jun 2013 16:15:49 -0700 (PDT) In-Reply-To: <51B9EA49.2050604@crockford.com> References: <51B9EA49.2050604@crockford.com> From: Jacob Davies Date: Thu, 13 Jun 2013 16:15:49 -0700 X-Google-Sender-Auth: max1SMiVTtTtSMo8PtNrGSj1nGE Message-ID: To: Douglas Crockford Content-Type: multipart/alternative; boundary=20cf3005dc0acc491804df115048 Cc: "json@ietf.org" Subject: Re: [Json] Two Documents X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 13 Jun 2013 23:16:11 -0000 --20cf3005dc0acc491804df115048 Content-Type: text/plain; charset=ISO-8859-1 I think the current lucid, succinct text that describes a data model, a language, and a byte serialization is so useful because it comprehensively describes all three things. So I wouldn't break it up. The byte serialization description is essential because in order to actually use JSON for anything you must deal with some byte serialized form, and in 99% of cases that will be the application/json form. I advocated dropping the mentions of Unicode except in byte serialization and character lookup for Unicode escapes. That's as a matter of clarity since those mentions are extraneous, and also so that applications that represent models without using Unicode or serialize to non-Unicode encodings not described as application/json are not needlessly deemed non-compliant. But I think those changes are relatively unimportant; few people are going to be confused by the current text, and those who are doing non-compliant things probably don't know or care. On Thu, Jun 13, 2013 at 8:50 AM, Douglas Crockford wrote: > The confusion and controversy around this work is due to a mistake that I > made in RFC 4627. The purpose of the RFC, which is clearly indicated > in the title, was to establish a MIME type. I also gave a description of > the JSON Data Interchange Format. My mistake was in conflating the two, > putting details about the MIME type into the description of the format. My > intention was to add clarity. That obviously was not the result. > > JSON is just a format. It describes a syntax of brackets and commas that > is useful in many contexts, profiles, and applications. JSON is agnostic > about all of that stuff. JSON shouldn't even care about character encoding. > Its only dependence on Unicode in the hex numbers used in the \u notation. > JSON can be encoded in ASCII or EBCDIC or even Hollerith codes. JSON can > be used in contexts where there is no character encoding at all, such as > paper documents and marble monuments. > > There are uses of JSON however in which such choices matter, and where > behavior needs to be attached to or derived from the syntax. That is > important stuff, and it belongs in different documents. Such documents > will place necessary restrictions on JSON's potential. No such document > can fit all applications, which causes much of the controversy we've seen > here. One size cannot fit all. JSON the format is universal. But real > applications require reasonable restrictions. > > So we should be working on at least two documents, which is something we > have > discussed earlier. The first is The JSON Data Interchange Format, which is > a simple grammar. The second is a best practices document, which recommends > specific conventions of usage. > > ______________________________**_________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/**listinfo/json > --20cf3005dc0acc491804df115048 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I think the current lucid, succinct text that describes a = data model, a language, and a byte serialization is so useful because it co= mprehensively describes all three things. So I wouldn't break it up.
The byte serialization description is essential because in o= rder to actually use JSON for anything you must deal with some byte seriali= zed form, and in 99% of cases that will be the application/json form.

I advocated dropping the mentions of Unicode exce= pt in byte serialization and character lookup for Unicode escapes. That'= ;s as a matter of clarity since those mentions are extraneous, and also so = that applications that represent models without using Unicode or serialize = to non-Unicode encodings not described as application/json are not needless= ly deemed non-compliant. But I think those changes are relatively unimporta= nt; few people are going to be confused by the current text, and those who = are doing non-compliant things probably don't know or care.


On Thu,= Jun 13, 2013 at 8:50 AM, Douglas Crockford <douglas@crockford.com> wrote:
The confusion and controversy around this wo= rk is due to a mistake that I
made in RFC 4627. The purpose of the RFC, which is clearly indicated
in the title, was to establish a MIME type. I also gave a description of the JSON Data Interchange Format. My mistake was in conflating the two,
putting details about the MIME type into the description of the format. My<= br> intention was to add clarity. That obviously was not the result.

JSON is just a format. It describes a syntax of brackets and commas that is useful in many contexts, profiles, and applications. JSON is agnostic about all of that stuff. JSON shouldn't even care about character encod= ing.
Its only dependence on Unicode in the hex numbers used in the \u notation.<= br> JSON can be encoded in ASCII or EBCDIC or even Hollerith codes. JSON can be used in contexts where there is no character encoding at all, such as paper documents and marble monuments.

There are uses of JSON however in which such choices matter, and where
behavior needs to be attached to or derived from the syntax. That is
important stuff, and it belongs in different documents. Such documents
will place necessary restrictions on JSON's potential. No such document=
can fit all applications, which causes much of the controversy we've se= en
here. One size cannot fit all. JSON the format is universal. But real
applications require reasonable restrictions.

So we should be working on at least two documents, which is something we ha= ve
discussed earlier. The first is The JSON Data Interchange Format, which is<= br> a simple grammar. The second is a best practices document, which recommends=
specific conventions of usage.

_______________________________________________
json mailing list
json@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/json

--20cf3005dc0acc491804df115048-- From cromis@gmail.com Thu Jun 13 16:48:09 2013 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 2A9E321F9B32 for ; Thu, 13 Jun 2013 16:48:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.839 X-Spam-Level: X-Spam-Status: No, score=-1.839 tagged_above=-999 required=5 tests=[AWL=0.138, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HuYfuG5i1YFB for ; Thu, 13 Jun 2013 16:48:08 -0700 (PDT) Received: from mail-qa0-x234.google.com (mail-qa0-x234.google.com [IPv6:2607:f8b0:400d:c00::234]) by ietfa.amsl.com (Postfix) with ESMTP id 17F9421F9B31 for ; Thu, 13 Jun 2013 16:48:08 -0700 (PDT) Received: by mail-qa0-f52.google.com with SMTP id bv4so35212qab.11 for ; Thu, 13 Jun 2013 16:48:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=HSIxEI2t5WsPK4G8SDdcIefFKZIFktTWX/cSWUSnELY=; b=uQdr4wCDKv7lBf+q04f3QKZZtOgPCB96WqH7CHUHbvzhamDVjuJeq0QBLAkrVnIDsC Ox2J0qEGdXv8YtHO8H7v5Bjnt6T5RRsk8wVog6XjMddwc4gN92lphi0cuE/7T31Fn2l3 cD/hZfjUiUmumykrptaJP4iyzkoraDZk4x3eyaqTv6djfhG5PqEhw6HlCfRwIAZ2283c Em7ouGfMNWvH6LfttO+XVmnBEx9UYVfzuC9AuL3W7FbZlHEkOBSvXcqrcJqvdN6Fa5bF +FvumlVTHe9SIJ9HXUzrnnBlir3WRAQYxuUvic5ERODCbpjCr/+fdcaQyu+XpXlGT543 mqwA== X-Received: by 10.49.101.74 with SMTP id fe10mr4441224qeb.11.1371167287436; Thu, 13 Jun 2013 16:48:07 -0700 (PDT) MIME-Version: 1.0 Sender: cromis@gmail.com Received: by 10.49.106.228 with HTTP; Thu, 13 Jun 2013 16:47:47 -0700 (PDT) In-Reply-To: <257919C3-279E-47CA-9430-17FD52F82745@lindenbergsoftware.com> References: <257919C3-279E-47CA-9430-17FD52F82745@lindenbergsoftware.com> From: Jacob Davies Date: Thu, 13 Jun 2013 16:47:47 -0700 X-Google-Sender-Auth: wJM5sEdUkehBNJkp_uOlJR0dNTU Message-ID: To: Norbert Lindenberg Content-Type: multipart/alternative; boundary=001a11c2c6ce191cfb04df11c3f1 Cc: "json@ietf.org" Subject: Re: [Json] "Generators SHOULD escape all Unicode whitespace characters"? X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 13 Jun 2013 23:48:09 -0000 --001a11c2c6ce191cfb04df11c3f1 Content-Type: text/plain; charset=ISO-8859-1 > > This list includes some but not all Unicode control characters in addition > to space characters. > Yes, and languages vary in what they actually consider "whitespace". I think in general we're concerned with "non-printing or whitespace characters other than a simple space". > "Whitespace smuggling" is a mild security concern and, from > > experience, can be quite hard to debug if non-0x20 spaces are not > > escaped. There is a small overhead of a couple of characters in doing > > so. > > Can you provide more detail on the problem that this proposal is intended > to solve? Sure - what sometimes happens is that various parts of a system disagree over what is whitespace. For instance, a server may strip whitespace using Java's built-in check that does not recognize all of the above-mentioned characters - http://docs.oracle.com/javase/1.5.0/docs/api/java/lang/Character.html#isWhitespace(int)- when the intent was to remove all whitespace. Malicious users may use characters that evade this check to introduce whitespace to content in ways that are unwanted or misleading. In other cases some system may tokenize by whitespace but varying definitions of what whitespace is result in different tokenizations and security concerns (as in the case Stephen Dolan mentions earlier). It may also assist in debugging seemingly-identical JSON strings that differ only by invisible or indiscernible whitespace, whether malicious or intentional. Does the proposal really solve the problem, given that generators don't > have to implement it, that they cannot implement it for characters added to > Unicode in a Unicode version later than the one they're based on, and that > parsers cannot rely on generators to have implemented it? > It certainly does not solve it. It mitigates it in the same way that escaping control characters and ASCII whitespace in strings mitigate similar concerns; they make it easier to see exactly what a string is intended to contain, in human-readable characters. The case it helps mitigate is the common one where a non-malicious generator is sending the JSON you're trying to understand, as for instance when a site's Javascript is communicating with its own server. One of the nice things about JSON is that it is easy to debug problems in JSON data using primitive tools - dumping text into page content, or hitting a URL directly and looking at the JSON in the browser. As much as possible, implementations should assist. The recommendation could list a specific set of current characters and additionally refer to the whitespace and control characters in the latest Unicode version. As a mitigation measure it helps even though it is partial. This may be a candidate for a best practice recommendation instead; I thought it was worth mentioning one way or another. --001a11c2c6ce191cfb04df11c3f1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
This list includes some but not all Unicode control characters in addition = to space characters.

Yes, and lan= guages vary in what they actually consider "whitespace". I think = in general we're concerned with "non-printing or whitespace charac= ters other than a simple space".

> "Whitespace smuggling" is a mild security concern and, from<= br> > experience, can be quite hard to debug if non-0x20 spaces are not
> escaped. There is a small overhead of a couple of characters in doing<= br> > so.

Can you provide more detail on the problem that this proposal is inte= nded to solve?

Sure - what sometimes= happens is that various parts of a system disagree over what is whitespace= . For instance, a server may strip whitespace using Java's built-in che= ck that does not recognize all of the above-mentioned characters -=A0http://docs.oracle.com/javase/1.5.0/docs/api/java/lang/C= haracter.html#isWhitespace(int) - when the intent was to remove all whi= tespace. Malicious users may use characters that evade this check to introd= uce whitespace to content in ways that are unwanted or misleading. In other= cases some system may tokenize by whitespace but varying definitions of wh= at whitespace is result in different tokenizations and security concerns (a= s in the case Stephen Dolan mentions earlier).

It may also assist in debugging seemingly-identic= al JSON strings that differ only by invisible or indiscernible whitespace, = whether malicious or intentional.

Does the proposal really solve the problem, given that generators don't= have to implement it, that they cannot implement it for characters added t= o Unicode in a Unicode version later than the one they're based on, and= that parsers cannot rely on generators to have implemented it?

It certainly does not solve it. It m= itigates it in the same way that escaping control characters and ASCII whit= espace in strings mitigate similar concerns; they make it easier to see exa= ctly what a string is intended to contain, in human-readable characters.

The case it helps mitigate is the common on= e where a non-malicious generator is sending the JSON you're trying to = understand, as for instance when a site's Javascript is communicating w= ith its own server. One of the nice things about JSON is that it is easy to= debug problems in JSON data using primitive tools - dumping text into page= content, or hitting a URL directly and looking at the JSON in the browser.= As much as possible, implementations should assist.

The recommendation could list a specific se= t of current characters and additionally refer to the whitespace and contro= l characters in the latest Unicode version. As a mitigation measure it help= s even though it is partial.

This may be a candidate for a best practice= recommendation instead; I thought it was worth mentioning one way or anoth= er.


--001a11c2c6ce191cfb04df11c3f1-- From sayrer@gmail.com Thu Jun 13 18:42:58 2013 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 D9C3D21F9B45 for ; Thu, 13 Jun 2013 18:42:58 -0700 (PDT) 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=[AWL=0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a4FeNnG1fM3Z for ; Thu, 13 Jun 2013 18:42:58 -0700 (PDT) Received: from mail-qa0-x22e.google.com (mail-qa0-x22e.google.com [IPv6:2607:f8b0:400d:c00::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 4BC8B21F9B00 for ; Thu, 13 Jun 2013 18:42:58 -0700 (PDT) Received: by mail-qa0-f46.google.com with SMTP id ih17so1489212qab.19 for ; Thu, 13 Jun 2013 18:42:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=t+2EPG5+pHCgClnH7vw2qr8GBUzVgE1sYXYJP5sgK2A=; b=M29yIgxNOoNWVYg4tnmCLfZA39LG/4phxc/c5Hsjxt6a+vQJIShWOuDoWkZBRsmDUS 8Ba5kHC7Mk70UGrJ1Bx9Oj7F44yUGBkqh/v96SB1Fu0OBvxwnrXkLd3JY75lF8mpRRBg Yw4nwPOxAVfrnBinagYmKeqQRl7LElyMAL1Uak7gPLw1B/liHZ3ZDF8QC9MsECg/s5O0 GB+lVJefuQqqqJifrurBy/jPQ76kOF6d8H++tXKd0uCTdt6Fm3uVFDjRKx/cQ7PHW76o AH9Gx7Zgh+zAqxcttVUv0ojrKZvueIlC4j7VrtwE3BpAsAw+H0NCQTqDscDCfmbzwR+x hodw== MIME-Version: 1.0 X-Received: by 10.229.141.69 with SMTP id l5mr63390qcu.23.1371174177703; Thu, 13 Jun 2013 18:42:57 -0700 (PDT) Received: by 10.224.130.67 with HTTP; Thu, 13 Jun 2013 18:42:57 -0700 (PDT) In-Reply-To: References: <51B9EA49.2050604@crockford.com> Date: Thu, 13 Jun 2013 18:42:57 -0700 Message-ID: From: R S To: Jacob Davies Content-Type: multipart/alternative; boundary=90e6ba10af85c9937804df135da6 Cc: Douglas Crockford , "json@ietf.org" Subject: Re: [Json] Two Documents X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 14 Jun 2013 01:42:59 -0000 --90e6ba10af85c9937804df135da6 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Jun 13, 2013 at 4:15 PM, Jacob Davies wrote: > I think the current lucid, succinct text that describes a data model, a > language, and a byte serialization is so useful because it comprehensively > describes all three things. So I wouldn't break it up. > I also think it is useful. JSON is a wildly successful format, so that leads me to believe that the current document got the level of encoding precision just about right. This dual-document proposal seems aimed at avoiding impractical character encoding requirements. I am sympathetic to that. I would prefer two documents over a single document with prescriptive and therefore incorrect encoding directives. - Rob --90e6ba10af85c9937804df135da6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Jun 13, 2013 at 4:15 PM, Jacob Davies <jacob@well.co= m> wrote:
I think the current lucid, succinct text that describes a = data model, a language, and a byte serialization is so useful because it co= mprehensively describes all three things. So I wouldn't break it up.

I also think it is useful. JSON is a= wildly successful format, so that leads me to believe that the current doc= ument got the level of encoding precision just about right.

This dual-document proposal seems aimed at avoiding im= practical character encoding requirements. I am sympathetic to that. I woul= d prefer two documents over a single document with prescriptive and therefo= re incorrect encoding directives.

- Rob
--90e6ba10af85c9937804df135da6-- From tbray@textuality.com Thu Jun 13 19:01:35 2013 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 800DB21F9B06 for ; Thu, 13 Jun 2013 19:01:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GX4Mw5Iccba3 for ; Thu, 13 Jun 2013 19:01:29 -0700 (PDT) Received: from mail-vc0-f178.google.com (mail-vc0-f178.google.com [209.85.220.178]) by ietfa.amsl.com (Postfix) with ESMTP id 6D21221F9AA4 for ; Thu, 13 Jun 2013 19:01:29 -0700 (PDT) Received: by mail-vc0-f178.google.com with SMTP id m17so34631vca.23 for ; Thu, 13 Jun 2013 19:01:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=RmaaxF47pLA6O2dIVcpd2t2+JBNvXz5CL2bhJ1uwCLM=; b=WkRGpoD+9VyhSlZI74kF7I9m1Plj5Xw2gaqTmEeIGeJCx9h4j2MaLF/oJ24NpQcPDs BEYroXfqkw2Zswn2IAV2AuezPZ2IYzhOvKrEUHG7mWbZzjqA00m8uIz4QEbLAa/ZMmwQ ejpalArgxiSBfI0tl1rOlOdcj5kvokoQtveRJWl4k8bMcc+hl7FPqSZXSGquR8t+KJmF yoJTL9uSoXfwupynJZzFTnJ8TD8lPFGExen8UJwuV2nHybvsLTkaJDmVupCLdvx0wQKx D5i5m3e4O01zYTpGMWnlNDWxCWfPQHrbyZxrBlumaEBG2qwi255R4atc+Gti6jAIMU07 Hdag== MIME-Version: 1.0 X-Received: by 10.220.67.81 with SMTP id q17mr85151vci.64.1371175286173; Thu, 13 Jun 2013 19:01:26 -0700 (PDT) Received: by 10.220.25.199 with HTTP; Thu, 13 Jun 2013 19:01:25 -0700 (PDT) X-Originating-IP: [209.52.105.82] In-Reply-To: References: <51B9EA49.2050604@crockford.com> Date: Thu, 13 Jun 2013 19:01:25 -0700 Message-ID: From: Tim Bray To: R S Content-Type: multipart/alternative; boundary=047d7b343814dbbc9f04df139f5a X-Gm-Message-State: ALoCoQmZr/FDN1gs6Y+C8UGPpuNurLp/70+YoGuruQdK1Qdf7UHtkgNIYZfhqZZuWK2n9vsle3zD Cc: Jacob Davies , Douglas Crockford , "json@ietf.org" Subject: Re: [Json] Two Documents X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 14 Jun 2013 02:01:35 -0000 --047d7b343814dbbc9f04df139f5a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Jun 13, 2013 at 6:42 PM, R S wrote: > This dual-document proposal seems aimed at avoiding impractical character > encoding requirements. I am sympathetic to that. I would prefer two > documents over a single document with prescriptive and therefore incorrec= t > encoding directives. > I think it=E2=80=99s pretty clear that 4627bis can=E2=80=99t retroactively = rule out things that are already in JSON like naked surrogates. So with luck we=E2=80=99re = good with a single JSON spec that says so, then another best-Internet-practices one that says =E2=80=9Cdon=E2=80=99t=E2=80=9D. -T > > - Rob > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > > --047d7b343814dbbc9f04df139f5a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, Jun 13, 2013 at 6:42 PM, R S <= ;sayrer@gmail.com= > wrote:
This dual-document proposal seems aimed at avoiding imprac= tical character encoding requirements. I am sympathetic to that. I would pr= efer two documents over a single document with prescriptive and therefore i= ncorrect encoding directives.

I think it=E2=80=99s pretty clear that 462= 7bis can=E2=80=99t retroactively rule out things that are already in JSON l= ike naked surrogates. So with luck we=E2=80=99re good with a single JSON sp= ec that says so, then another best-Internet-practices one that says =E2=80= =9Cdon=E2=80=99t=E2=80=9D. -T

=C2=A0
=

- Rob

_______________________________________________
json mailing list
json@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/json


--047d7b343814dbbc9f04df139f5a-- From nico@cryptonector.com Thu Jun 13 19:20:07 2013 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 E800621F99A7 for ; Thu, 13 Jun 2013 19:20:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KO2keWUFfPHO for ; Thu, 13 Jun 2013 19:20:03 -0700 (PDT) Received: from homiemail-a66.g.dreamhost.com (caiajhbdcahe.dreamhost.com [208.97.132.74]) by ietfa.amsl.com (Postfix) with ESMTP id DEC5A21F8AF4 for ; Thu, 13 Jun 2013 19:20:02 -0700 (PDT) Received: from homiemail-a66.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a66.g.dreamhost.com (Postfix) with ESMTP id 1F9B9350072 for ; Thu, 13 Jun 2013 19:20:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=Eadr7nWTwacDBAGzdO3d oqF2B+Q=; b=XSaTkeI8WVLCR8g2/WjaSURx0ez3IsThDj8aG0fWQkdZQnTZ1b7G 75kBFeI+3zq7Vzo1L4d3JL+rTmhWPXTf1p667o/+wEDoZcaY/2v0Q9ajY9qE/D7J M/8sRiZkZrlKFcgTo2jOtaokUK2LnBmVSmFRsNIdIfoklv1UEXmMvoA= Received: from mail-ie0-f178.google.com (mail-ie0-f178.google.com [209.85.223.178]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a66.g.dreamhost.com (Postfix) with ESMTPSA id ED727350057 for ; Thu, 13 Jun 2013 19:20:01 -0700 (PDT) Received: by mail-ie0-f178.google.com with SMTP id u16so187930iet.9 for ; Thu, 13 Jun 2013 19:20:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=s+zPsB/ORbPr07zXnqxaCd9pmv3BTgyUQIEE4LAV/2k=; b=JvEIVABijLzeijikdjBn/1IugT8G9eR6KOA2gDuAZ/ylhql2ntnRw2mh9KsUxLX4xE ZRH1ZeQVB1WHKJKFyyGHxMUZd9YBtnKVccJBWUkXzQLviykwugPyrz5Z/xfU8m6kFEXF EuWQf45aOPwe8hEklSEOrG2ckZ+Xa1W5tw86R0waMz6GCGimdDo91on3VpnUCiAmo+Me QwdBOyRBBCGF04PpMbE3Y0RmN7IHhql3jTFBNZnstOWohZHA8Kl6DJyrrq7J+Pfu8ZBu udXj6LX3Q+KxB/fSe5u5wokBHn4oKgtPfwSvwBDe+/mKiCMwI8QgjsmVE1NE88M0UoGF vlMw== MIME-Version: 1.0 X-Received: by 10.50.127.211 with SMTP id ni19mr73460igb.93.1371176401280; Thu, 13 Jun 2013 19:20:01 -0700 (PDT) Received: by 10.64.106.232 with HTTP; Thu, 13 Jun 2013 19:20:00 -0700 (PDT) In-Reply-To: <6FC6B441-B74D-4B9F-B883-065C05890880@lindenbergsoftware.com> References: <6FC6B441-B74D-4B9F-B883-065C05890880@lindenbergsoftware.com> Date: Thu, 13 Jun 2013 21:20:00 -0500 Message-ID: From: Nico Williams To: Norbert Lindenberg Content-Type: text/plain; charset=UTF-8 Cc: json@ietf.org Subject: Re: [Json] Scope: Wire format or runtime format? X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 14 Jun 2013 02:20:08 -0000 Well, JavaScript itself carries data and programs (but I repeat myself) and gets carried around in network protocols all the time. A stretch, maybe, but to say that JavaScript is the language of the web is not all that hyperbolic. We might well end up with *two* JSONs. I'd rather as much as possible end up with just one. The spec + best practices concept works for me so far. I don't really mind the compromises that actual deployments have forced on JSON, be it re: duplicate names in objects or non-Unicode content in what look like Unicode strings. I was as shocked as others for a bit, but it's passed :) Nico -- From lear@cisco.com Thu Jun 13 19:49:17 2013 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 E86A811E80CC for ; Thu, 13 Jun 2013 19:49:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o4R8dkcL86eQ for ; Thu, 13 Jun 2013 19:49:13 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 5F4ED21E8051 for ; Thu, 13 Jun 2013 19:49:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1957; q=dns/txt; s=iport; t=1371178142; x=1372387742; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=p1T/agMAB7LHZPZDFv46v7q2gMlVxBe7RPtM4khz+Yc=; b=OpJDxtOYmMzPGjDw0fPO715VBNqEvIm4SUfuBCGTB9vb94n6GqBnKsB0 TrLARR6/3mwRHhm3RiZ6wABcOJ4ekAQk087WunlOwi7RY55OWUi2+BRgm G0plsJoclBhPk9QkW0rcWHN0RJyuS2d/QuMOrYx2NDvG9CdOFwLGI9T0R c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhkFAMaDulGtJV2Y/2dsb2JhbABagwkwgz27WoEFFnSCIwEBAQQBAQEgSwoBEAsYAgIFFgsCAgkDAgECARUwBg0BBQIBAYgKDKkzkS4EgSaOIQeCTIEUA5dBkUKDKyA X-IronPort-AV: E=Sophos;i="4.87,863,1363132800"; d="scan'208";a="222650484" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-6.cisco.com with ESMTP; 14 Jun 2013 02:49:02 +0000 Received: from rtp-vpn3-1627.cisco.com (rtp-vpn3-1627.cisco.com [10.82.222.98]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r5E2n0Cq001542 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 14 Jun 2013 02:49:01 GMT Message-ID: <51BA849C.4050508@cisco.com> Date: Thu, 13 Jun 2013 22:49:00 -0400 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Douglas Crockford References: <51B9EA49.2050604@crockford.com> <20130613155710.GB29284@mercury.ccil.org> <51B9EF43.3020700@crockford.com> In-Reply-To: <51B9EF43.3020700@crockford.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: John Cowan , "json@ietf.org" Subject: Re: [Json] Two Documents X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 14 Jun 2013 02:49:18 -0000 Hi Douglas, I think your suggestion of two documents is an interesting one. One way to go would be to create the 2nd document and include what needs to be included there, and then decide LATER whether to merge the two documents back. If the best practices document ends up not being excessive in length, then perhaps there's no harm in adding stuff back to the main document, so long as it is clear what is normative and what is advice. Eliot On 6/13/13 12:11 PM, Douglas Crockford wrote: > > On 6/13/2013 8:57 AM, John Cowan wrote: >> Douglas Crockford scripsit: >> >>> The confusion and controversy around this work is due to a mistake >>> that I made in RFC 4627. The purpose of the RFC, which is clearly >>> indicated in the title, was to establish a MIME type. I also gave >>> a description of the JSON Data Interchange Format. My mistake was >>> in conflating the two, putting details about the MIME type into the >>> description of the format. My intention was to add clarity. That >>> obviously was not the result. >> Indeed. >> >>> So we should be working on at least two documents, which is something >>> we have discussed earlier. The first is The JSON Data Interchange >>> Format, which is a simple grammar. The second is a best practices >>> document, which recommends specific conventions of usage. >> Fine, but the definition of the application/json media type can't be >> exiled to a BCP. It either has to be in a separate standards-track RFC, >> or needs to be in the same RFC as the definition of JSON format but in a >> different section of it. The latter strikes me as more sensible. >> > I think it will be better for ECMA that application/json be in a > separate document. > ECMA does not appear to be concerned with the maintenance of MIME types. > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > > From paul.hoffman@vpnc.org Sat Jun 15 08:27:42 2013 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 372BB21F9DC8 for ; Sat, 15 Jun 2013 08:27:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sPeone51NSvx for ; Sat, 15 Jun 2013 08:27:41 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id BCF1321F9DC7 for ; Sat, 15 Jun 2013 08:27:41 -0700 (PDT) Received: from [209.140.71.190] ([209.140.71.190]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r5FFRTOF066524 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 15 Jun 2013 08:27:38 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Paul Hoffman In-Reply-To: <6FC6B441-B74D-4B9F-B883-065C05890880@lindenbergsoftware.com> Date: Sat, 15 Jun 2013 11:27:30 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <0E2DB76C-3180-4D27-BD89-07C84A5D3599@vpnc.org> References: <6FC6B441-B74D-4B9F-B883-065C05890880@lindenbergsoftware.com> To: Norbert Lindenberg X-Mailer: Apple Mail (2.1508) Cc: json@ietf.org Subject: Re: [Json] Scope: Wire format or runtime format? X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 15 Jun 2013 15:27:42 -0000 On Jun 13, 2013, at 6:47 PM, Norbert Lindenberg = wrote: > In looking over older messages on this list, I found a message that = made clear to me why we're having this endless discussion about Unicode = surrogates - it's because we're not clear whether we're designing a wire = format or a format that also for use at runtime: > http://www.ietf.org/mail-archive/web/json/current/msg00355.html >=20 > Some people are coming from the runtime point of view, especially = ECMAScript, where it's accepted practice to use ill-formed UTF-16 or = even non-text in strings. At least the ill-formed UTF-16 is legitimized = by section 2.7 of the Unicode standard. >=20 > Other people are coming from the wire protocol point of view, where = clean formats are expected, in particular well-formed Unicode code unit = sequences according to section 3.9 of the Unicode standard. >=20 > So which one shall it be? Why not both? RFC 4627 deals with both; why should the update change to = restrict that? --Paul Hoffman= From tbray@textuality.com Sat Jun 15 08:56:21 2013 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 867D521F9DDD for ; Sat, 15 Jun 2013 08:56:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.663 X-Spam-Level: X-Spam-Status: No, score=-1.663 tagged_above=-999 required=5 tests=[AWL=1.313, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y9E7rnOhvViv for ; Sat, 15 Jun 2013 08:56:16 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9586621F9DA5 for ; Sat, 15 Jun 2013 08:56:16 -0700 (PDT) Received: by mail-vc0-f172.google.com with SMTP id ib11so1142915vcb.3 for ; Sat, 15 Jun 2013 08:56:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=uM6M4/+VHXE8l2JqN4EEVaQkV55aBj0IzDIyEqV+6Fo=; b=KUZ/suGVCzXzsdUzdFy1c36WV+xJ5B8G9/wElFFtxGTCMKbh6sbH7GY2cr4MjWyI4q XAM6paunEnxcNpN8f9/yUuQFDiwkSYR+PP2F4LXZHQyoMbWxSq6DvrKKZAgwNoLQhLfE 3fr2Ad0ssr8j9cDfrVxPRsBmQDPtW53pfzUmZd0rKqtX6VfBAVwxaPD4fBeBBXR+EwTi ADpfUEsaTZ7T3rYDNZJwbBoCopn6ClPhLRtm2b69v9l8OHhkgKAX3+yk3a3vRc8ob6VW 9eLq5hKX9XCYMMDN27BKHMocxuJw8QAdCZkOKpUFI/CmvEzhX68r9WnAzJ0iE6e1YHpw IvtQ== MIME-Version: 1.0 X-Received: by 10.220.123.131 with SMTP id p3mr2410855vcr.69.1371311775325; Sat, 15 Jun 2013 08:56:15 -0700 (PDT) Received: by 10.220.25.199 with HTTP; Sat, 15 Jun 2013 08:56:15 -0700 (PDT) X-Originating-IP: [24.84.235.32] In-Reply-To: <0E2DB76C-3180-4D27-BD89-07C84A5D3599@vpnc.org> References: <6FC6B441-B74D-4B9F-B883-065C05890880@lindenbergsoftware.com> <0E2DB76C-3180-4D27-BD89-07C84A5D3599@vpnc.org> Date: Sat, 15 Jun 2013 08:56:15 -0700 Message-ID: From: Tim Bray To: Paul Hoffman Content-Type: multipart/alternative; boundary=089e013cbb223eaf5704df336748 X-Gm-Message-State: ALoCoQm2stfcjzO/s1w1JrzalClLrGZtB6rlbc7iMExt+OREi+8t9WmLSlYxkzkhQ2IwezxfugdV Cc: Norbert Lindenberg , "json@ietf.org" Subject: Re: [Json] Scope: Wire format or runtime format? X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 15 Jun 2013 15:56:21 -0000 --089e013cbb223eaf5704df336748 Content-Type: text/plain; charset=UTF-8 I think the IETF, at least at the Apps area, is in the business of network protocols, so I see our job here primarily as getting the wire-format aspects right. -T On Sat, Jun 15, 2013 at 8:27 AM, Paul Hoffman wrote: > On Jun 13, 2013, at 6:47 PM, Norbert Lindenberg < > ietf@lindenbergsoftware.com> wrote: > > > In looking over older messages on this list, I found a message that made > clear to me why we're having this endless discussion about Unicode > surrogates - it's because we're not clear whether we're designing a wire > format or a format that also for use at runtime: > > http://www.ietf.org/mail-archive/web/json/current/msg00355.html > > > > Some people are coming from the runtime point of view, especially > ECMAScript, where it's accepted practice to use ill-formed UTF-16 or even > non-text in strings. At least the ill-formed UTF-16 is legitimized by > section 2.7 of the Unicode standard. > > > > Other people are coming from the wire protocol point of view, where > clean formats are expected, in particular well-formed Unicode code unit > sequences according to section 3.9 of the Unicode standard. > > > > So which one shall it be? > > Why not both? RFC 4627 deals with both; why should the update change to > restrict that? > > --Paul Hoffman > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > --089e013cbb223eaf5704df336748 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I think the IETF, at least at the Apps area, is in the bus= iness of network protocols, so I see our job here primarily as getting the = wire-format aspects right.

=C2=A0-T


On Sat, Jun 15, 2013 at 8:27 AM, Paul Hoffma= n <paul.hoffman@vpnc.org> wrote:
On Jun 13, 2013, at 6:47 PM, Norbert Lindenberg <ietf@lindenbergsoftware.com&g= t; wrote:

> In looking over older messages on this list, I found a message that ma= de clear to me why we're having this endless discussion about Unicode s= urrogates - it's because we're not clear whether we're designin= g a wire format or a format that also for use at runtime:
> http://www.ietf.org/mail-archive/web/json/current/m= sg00355.html
>
> Some people are coming from the runtime point of view, especially ECMA= Script, where it's accepted practice to use ill-formed UTF-16 or even n= on-text in strings. At least the ill-formed UTF-16 is legitimized by sectio= n 2.7 of the Unicode standard.
>
> Other people are coming from the wire protocol point of view, where cl= ean formats are expected, in particular well-formed Unicode code unit seque= nces according to section 3.9 of the Unicode standard.
>
> So which one shall it be?

Why not both? RFC 4627 deals with both; why should the update change = to restrict that?

--Paul Hoffman
_____________________= __________________________
json mailing list
json@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/json

--089e013cbb223eaf5704df336748-- From cowan@ccil.org Sat Jun 15 09:07:03 2013 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 1B36021F9DAF for ; Sat, 15 Jun 2013 09:07:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.44 X-Spam-Level: X-Spam-Status: No, score=-3.44 tagged_above=-999 required=5 tests=[AWL=0.159, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eIAy-9Ax7JTf for ; Sat, 15 Jun 2013 09:06:58 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id DF34F21F9590 for ; Sat, 15 Jun 2013 09:06:54 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1Unt04-0004Xo-Mx; Sat, 15 Jun 2013 12:06:48 -0400 Date: Sat, 15 Jun 2013 12:06:48 -0400 From: John Cowan To: Tim Bray Message-ID: <20130615160648.GC30796@mercury.ccil.org> References: <6FC6B441-B74D-4B9F-B883-065C05890880@lindenbergsoftware.com> <0E2DB76C-3180-4D27-BD89-07C84A5D3599@vpnc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Cc: Norbert Lindenberg , Paul Hoffman , "json@ietf.org" Subject: Re: [Json] Scope: Wire format or runtime format? X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 15 Jun 2013 16:07:03 -0000 Tim Bray scripsit: > I think the IETF, at least at the Apps area, is in the business of network > protocols, so I see our job here primarily as getting the wire-format > aspects right. +1, but that still has at least two aspects, the character-level syntax and the mapping to an entity body. -- John Cowan cowan@ccil.org http://ccil.org/~cowan Big as a house, much bigger than a house, it looked to [Sam], a grey-clad moving hill. Fear and wonder, maybe, enlarged him in the hobbit's eyes, but the Mumak of Harad was indeed a beast of vast bulk, and the like of him does not walk now in Middle-earth; his kin that live still in latter days are but memories of his girth and his majesty. --"Of Herbs and Stewed Rabbit" From jhildebr@cisco.com Sat Jun 15 13:35:39 2013 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 9F67721F9CF3 for ; Sat, 15 Jun 2013 13:35:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UDiMGEtgh6dz for ; Sat, 15 Jun 2013 13:35:34 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 18E1021F9CEF for ; Sat, 15 Jun 2013 13:35:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=557; q=dns/txt; s=iport; t=1371328534; x=1372538134; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=/AaxrmW/v0YZZe3sOk4MCy/e7LKL6IRYWWsfHWsx88g=; b=S0sk79N3E12fm5LsKQdE5bLfTAE94fGodzgMR8zDOYmDv+m/bTcg8TG3 cBC/KJetB84hJnxBLpx+/fxFm0xUE2gl4WquoE9dvGtRiw+dQl4Nti1/k vHR9kQv6FNDIjPWF82mpclMoZULxk2dewqRGeaz27BsoMzmWGJGB7TfwY g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqMFAJjPvFGtJXHA/2dsb2JhbABagwl6gji8EIEGFnSCJQEEOj8SAQgiFEIlAgQBDQUIiAa5Io8WMQeCf2EDqQSDD4Io X-IronPort-AV: E=Sophos;i="4.87,872,1363132800"; d="scan'208";a="223274402" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-6.cisco.com with ESMTP; 15 Jun 2013 20:35:33 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r5FKZXAt026052 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 15 Jun 2013 20:35:33 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.56]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.02.0318.004; Sat, 15 Jun 2013 15:35:33 -0500 From: "Joe Hildebrand (jhildebr)" To: John Cowan , Tim Bray Thread-Topic: [Json] Scope: Wire format or runtime format? Thread-Index: AQHOadzi0LDFyps3JkOZ3Lj86+cy5Jk3QdKAgAAC8wD//+aBgA== Date: Sat, 15 Jun 2013 20:35:32 +0000 Message-ID: In-Reply-To: <20130615160648.GC30796@mercury.ccil.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [10.21.117.127] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Norbert Lindenberg , Paul Hoffman , "json@ietf.org" Subject: Re: [Json] Scope: Wire format or runtime format? X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 15 Jun 2013 20:35:39 -0000 On 6/15/13 10:06 AM, "John Cowan" wrote: >Tim Bray scripsit: > >> I think the IETF, at least at the Apps area, is in the business of >>network >> protocols, so I see our job here primarily as getting the wire-format >> aspects right. > >+1, but that still has at least two aspects, the character-level syntax >and the mapping to an entity body. Is that only because of the multiple encodings? For example, if JSON was UTF8-only, could we define a purely concrete syntax of octet sequences? --=20 Joe Hildebrand From cowan@ccil.org Sat Jun 15 15:39:20 2013 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 315D921F9E31 for ; Sat, 15 Jun 2013 15:39:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.443 X-Spam-Level: X-Spam-Status: No, score=-3.443 tagged_above=-999 required=5 tests=[AWL=0.156, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0E91R9bDiSJY for ; Sat, 15 Jun 2013 15:39:15 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id D589C21F9E30 for ; Sat, 15 Jun 2013 15:39:15 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1Unz7o-0000y3-Bk; Sat, 15 Jun 2013 18:39:12 -0400 Date: Sat, 15 Jun 2013 18:39:12 -0400 From: John Cowan To: "Joe Hildebrand (jhildebr)" Message-ID: <20130615223912.GI30796@mercury.ccil.org> References: <20130615160648.GC30796@mercury.ccil.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Cc: Norbert Lindenberg , Tim Bray , Paul Hoffman , "json@ietf.org" Subject: Re: [Json] Scope: Wire format or runtime format? X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 15 Jun 2013 22:39:20 -0000 Joe Hildebrand (jhildebr) scripsit: > Is that only because of the multiple encodings? For example, if JSON was > UTF8-only, could we define a purely concrete syntax of octet sequences? In principle, but that would make it difficult to embed JSON in HTML or XML or JavaScript or another format defined by characters. -- Business before pleasure, if not too bloomering long before. --Nicholas van Rijn John Cowan http://www.ccil.org/~cowan From tony@att.com Sat Jun 15 16:33:43 2013 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 54A6121F9E34 for ; Sat, 15 Jun 2013 16:33:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O+zmTGdn59kK for ; Sat, 15 Jun 2013 16:33:37 -0700 (PDT) Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) by ietfa.amsl.com (Postfix) with ESMTP id 4015D21F9E33 for ; Sat, 15 Jun 2013 16:33:37 -0700 (PDT) Received: from unknown [144.160.20.145] (EHLO mlpd192.enaf.sfdc.sbc.com) by nbfkord-smmo06.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id 0d9fcb15.0.236099.00-411.636343.nbfkord-smmo06.seg.att.com (envelope-from ); Sat, 15 Jun 2013 23:33:37 +0000 (UTC) X-MXL-Hash: 51bcf9d1304c7e21-27796d990ed882afdeb7e34d41185888bde88d72 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r5FNXa9I005493 for ; Sat, 15 Jun 2013 19:33:36 -0400 Received: from alpi132.aldc.att.com (alpi132.aldc.att.com [130.8.217.2]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r5FNXWKR005473 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 15 Jun 2013 19:33:32 -0400 Received: from alpi153.aldc.att.com (alpi153.aldc.att.com [130.8.42.31]) by alpi132.aldc.att.com (RSA Interceptor) for ; Sat, 15 Jun 2013 23:33:20 GMT Received: from aldc.att.com (localhost [127.0.0.1]) by alpi153.aldc.att.com (8.14.5/8.14.5) with ESMTP id r5FNXKON008400 for ; Sat, 15 Jun 2013 19:33:20 -0400 Received: from dns.maillennium.att.com (maillennium.att.com [135.25.114.99]) by alpi153.aldc.att.com (8.14.5/8.14.5) with ESMTP id r5FNXGDd008342 for ; Sat, 15 Jun 2013 19:33:18 -0400 Received: from [130.10.228.179] (vpn-130-10-228-179.vpn.sest.att.com[130.10.228.179]) by maillennium.att.com (mailgw1) with ESMTP id <20130615233315gw100bhh6ve> (Authid: tony); Sat, 15 Jun 2013 23:33:16 +0000 X-Originating-IP: [130.10.228.179] Message-ID: <51BCF9C0.1080408@att.com> Date: Sat, 15 Jun 2013 19:33:20 -0400 From: Tony Hansen User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Paul Hoffman References: <6FC6B441-B74D-4B9F-B883-065C05890880@lindenbergsoftware.com> <0E2DB76C-3180-4D27-BD89-07C84A5D3599@vpnc.org> In-Reply-To: <0E2DB76C-3180-4D27-BD89-07C84A5D3599@vpnc.org> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.145] X-AnalysisOut: [v=2.0 cv=FZaAMuC6 c=1 sm=0 a=ZRNLZ4dFUbCvG8UMqPvVAA==:17 a] X-AnalysisOut: [=Y4bMX7OWe-8A:10 a=bfzWQn4VrGAA:10 a=89nDKbIBrqAA:10 a=ofM] X-AnalysisOut: [gfj31e3cA:10 a=BLceEmwcHowA:10 a=8nJEP1OIZ-IA:10 a=zQP7CpK] X-AnalysisOut: [OAAAA:8 a=5G9hByssVJsA:10 a=yb3l31EbAAAA:8 a=48vgC7mUAAAA:] X-AnalysisOut: [8 a=euPEhZ44BlnFORzG5AUA:9 a=wPNLvfGTeEIA:10 a=JvmnxntETa4] X-AnalysisOut: [A:10 a=xDJGhPxdmhgA:10] Cc: Norbert Lindenberg , json@ietf.org Subject: Re: [Json] Scope: Wire format or runtime format? X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 15 Jun 2013 23:33:43 -0000 On 6/15/2013 11:27 AM, Paul Hoffman wrote: > On Jun 13, 2013, at 6:47 PM, Norbert Lindenberg wrote: > >> In looking over older messages on this list, I found a message that made clear to me why we're having this endless discussion about Unicode surrogates - it's because we're not clear whether we're designing a wire format or a format that also for use at runtime: >> http://www.ietf.org/mail-archive/web/json/current/msg00355.html >> >> Some people are coming from the runtime point of view, especially ECMAScript, where it's accepted practice to use ill-formed UTF-16 or even non-text in strings. At least the ill-formed UTF-16 is legitimized by section 2.7 of the Unicode standard. >> >> Other people are coming from the wire protocol point of view, where clean formats are expected, in particular well-formed Unicode code unit sequences according to section 3.9 of the Unicode standard. >> >> So which one shall it be? > Why not both? RFC 4627 deals with both; why should the update change to restrict that? I'm with Paul -- it needs to continue to do both. IMO, there's 1) the character-based definition of the JSON format, the one defined by the ABNF, and 2) an expression of that for over-the-wire use as an application/json entity. The bulk of this document should be focused on #1, and I think #2 can then be a fairly small section. Tony Hansen From stefan@drees.name Sun Jun 16 03:43:32 2013 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 3B2D121F9E38 for ; Sun, 16 Jun 2013 03:43:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.107 X-Spam-Level: X-Spam-Status: No, score=-2.107 tagged_above=-999 required=5 tests=[AWL=0.142, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DjshNsDTns4w for ; Sun, 16 Jun 2013 03:43:27 -0700 (PDT) Received: from mout.web.de (mout.web.de [212.227.15.14]) by ietfa.amsl.com (Postfix) with ESMTP id 34EBC21F9E43 for ; Sun, 16 Jun 2013 03:43:26 -0700 (PDT) Received: from newyork.local.box ([93.129.105.13]) by smtp.web.de (mrweb002) with ESMTPSA (Nemesis) id 0LwZ5z-1UGINV1x0R-018MxE; Sun, 16 Jun 2013 12:43:19 +0200 Message-ID: <51BD96C5.80709@drees.name> Date: Sun, 16 Jun 2013 12:43:17 +0200 From: Stefan Drees User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Tony Hansen References: <6FC6B441-B74D-4B9F-B883-065C05890880@lindenbergsoftware.com> <0E2DB76C-3180-4D27-BD89-07C84A5D3599@vpnc.org> <51BCF9C0.1080408@att.com> In-Reply-To: <51BCF9C0.1080408@att.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:QW/CaBexQ9ZMZKBkRAizOiMoI4sheiVRggG1bKPNOc6LXIKDwyp qDZ7zkeAfKHW6uWDcDxLWaFQkvHKpRjXZyTsaAZzWXRlGIBWj7aKcgSJRT49VFePqLazgwy xbhwsBK681MMDqL5QScO3yItHHD1EVPPMdSWiMHc8mC8XCQC8HQP/j5unlbiegLKBUITnoY co3mxrN43uMTgerIW9RSw== Cc: Norbert Lindenberg , Paul Hoffman , json@ietf.org Subject: Re: [Json] Scope: Wire format or runtime format? X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stefan@drees.name List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Jun 2013 10:43:32 -0000 On 2013-06-16 01:33 +02:00, Tony Hansen wrote: > On 6/15/2013 11:27 AM, Paul Hoffman wrote: >> On Jun 13, 2013, at 6:47 PM, Norbert Lindenberg wrote: >> >>> In looking over older messages on this list, I found a message that made clear to me why we're having this endless discussion about Unicode surrogates - it's because we're not clear whether we're designing a wire format or a format that also for use at runtime: >>> http://www.ietf.org/mail-archive/web/json/current/msg00355.html >>> >>> Some people are coming from the runtime point of view, especially ECMAScript, where it's accepted practice to use ill-formed UTF-16 or even non-text in strings. At least the ill-formed UTF-16 is legitimized by section 2.7 of the Unicode standard. >>> >>> Other people are coming from the wire protocol point of view, where clean formats are expected, in particular well-formed Unicode code unit sequences according to section 3.9 of the Unicode standard. >>> >>> So which one shall it be? >> Why not both? RFC 4627 deals with both; why should the update change to restrict that? > > I'm with Paul -- it needs to continue to do both. > > IMO, there's 1) the character-based definition of the JSON format, the > one defined by the ABNF, and 2) an expression of that for over-the-wire > use as an application/json entity. The bulk of this document should be > focused on #1, and I think #2 can then be a fairly small section. I second that POV. Until we started suggesting new titles for our well-beloved RFC 4627, we all focused mostly on #1 and took #2 for granted as necessary for hand-over "conventions". Please keep these two aspects together in one document, and ... just let us **not** shoot too far over the approx. 2000 words RFC 4627 needed. Most discussions - until now - convinced me that we will not be able to really add that much to it, so many additional words will be considered unreasonable and diluting. An additional document even worse, seems like complete overhead to me. Stefan Drees. From markus.lanthaler@gmx.net Sun Jun 16 03:59:49 2013 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 656A021F8D10 for ; Sun, 16 Jun 2013 03:59:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.15 X-Spam-Level: X-Spam-Status: No, score=-1.15 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CxUhkMKBqIAC for ; Sun, 16 Jun 2013 03:59:43 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) by ietfa.amsl.com (Postfix) with ESMTP id 53E5221F9635 for ; Sun, 16 Jun 2013 03:59:43 -0700 (PDT) Received: from mailout-de.gmx.net ([10.1.76.34]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0MUzND-1Up4yZ15Qb-00YSU5 for ; Sun, 16 Jun 2013 12:59:42 +0200 Received: (qmail invoked by alias); 16 Jun 2013 10:59:42 -0000 Received: from 84-115-182-43.dynamic.surfer.at (EHLO Vostro3500) [84.115.182.43] by mail.gmx.net (mp034) with SMTP; 16 Jun 2013 12:59:42 +0200 X-Authenticated: #419883 X-Provags-ID: V01U2FsdGVkX1/EfrZwlYHELvsUUJZcb7SpSpsfRejsFoaUAoIvBV zobnkYm0QPFDCz From: "Markus Lanthaler" To: References: <6FC6B441-B74D-4B9F-B883-065C05890880@lindenbergsoftware.com> <0E2DB76C-3180-4D27-BD89-07C84A5D3599@vpnc.org> <51BCF9C0.1080408@att.com> <51BD96C5.80709@drees.name> In-Reply-To: <51BD96C5.80709@drees.name> Date: Sun, 16 Jun 2013 12:59:39 +0200 Message-ID: <00b001ce6a80$9a821ea0$cf865be0$@lanthaler@gmx.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac5qfl0On0yMhgE6QlWDHxoeX0ztGAAAg7HA Content-Language: de X-Y-GMX-Trusted: 0 Subject: Re: [Json] Scope: Wire format or runtime format? X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 16 Jun 2013 10:59:49 -0000 On Sunday, June 16, 2013 12:43 PM, Stefan Drees wrote: > On 2013-06-16 01:33 +02:00, Tony Hansen wrote: > > On 6/15/2013 11:27 AM, Paul Hoffman wrote: > >> Why not both? RFC 4627 deals with both; why should the update change > >> to restrict that? > > > > I'm with Paul -- it needs to continue to do both. > > > > IMO, there's 1) the character-based definition of the JSON format, the > > one defined by the ABNF, and 2) an expression of that for over-the-wire > > use as an application/json entity. The bulk of this document should be > > focused on #1, and I think #2 can then be a fairly small section. > > I second that POV. Until we started suggesting new titles for our > well-beloved RFC 4627, we all focused mostly on #1 and took #2 for > granted as necessary for hand-over "conventions". > > Please keep these two aspects together in one document, and ... just let > us **not** shoot too far over the approx. 2000 words RFC 4627 needed. > Most discussions - until now - convinced me that we will not be able to > really add that much to it, so many additional words will be considered > unreasonable and diluting. > > An additional document even worse, seems like complete overhead to me. +1 -- Markus Lanthaler @markuslanthaler From duerst@it.aoyama.ac.jp Sun Jun 16 18:59:51 2013 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 CAD4C21F8B07 for ; Sun, 16 Jun 2013 18:59:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.59 X-Spam-Level: X-Spam-Status: No, score=-101.59 tagged_above=-999 required=5 tests=[AWL=-1.800, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xRUuCA1Xb1T4 for ; Sun, 16 Jun 2013 18:59:45 -0700 (PDT) Received: from scintmta01.scbb.aoyama.ac.jp (scintmta01.scbb.aoyama.ac.jp [133.2.253.33]) by ietfa.amsl.com (Postfix) with ESMTP id 1879121F9C01 for ; Sun, 16 Jun 2013 18:59:44 -0700 (PDT) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta01.scbb.aoyama.ac.jp (secret/secret) with SMTP id r5H1xVO0017543; Mon, 17 Jun 2013 10:59:31 +0900 Received: from (unknown [133.2.206.134]) by scmse02.scbb.aoyama.ac.jp with smtp id 174d_9a4f_8ce4247c_d6f1_11e2_825f_001e6722eec2; Mon, 17 Jun 2013 10:59:30 +0900 Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id 1E1A8C0234; Mon, 17 Jun 2013 10:58:13 +0900 (JST) Message-ID: <51BE6D79.5010909@it.aoyama.ac.jp> Date: Mon, 17 Jun 2013 10:59:21 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: Markus Lanthaler References: <6FC6B441-B74D-4B9F-B883-065C05890880@lindenbergsoftware.com> <0E2DB76C-3180-4D27-BD89-07C84A5D3599@vpnc.org> <51BCF9C0.1080408@att.com> <51BD96C5.80709@drees.name> <00b001ce6a80$9a821ea0$cf865be0$@lanthaler@gmx.net> In-Reply-To: <00b001ce6a80$9a821ea0$cf865be0$@lanthaler@gmx.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: json@ietf.org Subject: Re: [Json] Scope: Wire format or runtime format? X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 17 Jun 2013 01:59:51 -0000 On 2013/06/16 19:59, Markus Lanthaler wrote: > On Sunday, June 16, 2013 12:43 PM, Stefan Drees wrote: >> On 2013-06-16 01:33 +02:00, Tony Hansen wrote: >>> On 6/15/2013 11:27 AM, Paul Hoffman wrote: >>>> Why not both? RFC 4627 deals with both; why should the update change >>>> to restrict that? >>> >>> I'm with Paul -- it needs to continue to do both. >>> >>> IMO, there's 1) the character-based definition of the JSON format, the >>> one defined by the ABNF, and 2) an expression of that for over-the-wire >>> use as an application/json entity. The bulk of this document should be >>> focused on #1, and I think #2 can then be a fairly small section. >> >> I second that POV. +1. But as far as I understand, these two were not the two that Norbert was talking about in the mail that started this thread. (More on that in a separate mail.) >> Until we started suggesting new titles for our >> well-beloved RFC 4627, we all focused mostly on #1 and took #2 for >> granted as necessary for hand-over "conventions". >> >> Please keep these two aspects together in one document, and ... just let >> us **not** shoot too far over the approx. 2000 words RFC 4627 needed. >> Most discussions - until now - convinced me that we will not be able to >> really add that much to it, so many additional words will be considered >> unreasonable and diluting. >> >> An additional document even worse, seems like complete overhead to me. > > +1 +1, at least as long as we haven't tried seriously with one document. Regards, Martin. From duerst@it.aoyama.ac.jp Sun Jun 16 21:18:06 2013 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 F3BEC21F9EFF for ; Sun, 16 Jun 2013 21:18:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.426 X-Spam-Level: X-Spam-Status: No, score=-101.426 tagged_above=-999 required=5 tests=[AWL=-1.636, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ff+s09YvLvxO for ; Sun, 16 Jun 2013 21:18:00 -0700 (PDT) Received: from scintmta01.scbb.aoyama.ac.jp (scintmta01.scbb.aoyama.ac.jp [133.2.253.33]) by ietfa.amsl.com (Postfix) with ESMTP id DAE4721F9EFB for ; Sun, 16 Jun 2013 21:17:59 -0700 (PDT) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta01.scbb.aoyama.ac.jp (secret/secret) with SMTP id r5H4HuKp017004; Mon, 17 Jun 2013 13:17:56 +0900 Received: from (unknown [133.2.206.134]) by scmse02.scbb.aoyama.ac.jp with smtp id 1750_dd99_e3300680_d704_11e2_82cc_001e6722eec2; Mon, 17 Jun 2013 13:17:56 +0900 Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id 3471FC0234; Mon, 17 Jun 2013 13:16:38 +0900 (JST) Message-ID: <51BE8DEA.7030307@it.aoyama.ac.jp> Date: Mon, 17 Jun 2013 13:17:46 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: Norbert Lindenberg References: <6FC6B441-B74D-4B9F-B883-065C05890880@lindenbergsoftware.com> In-Reply-To: <6FC6B441-B74D-4B9F-B883-065C05890880@lindenbergsoftware.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: json@ietf.org Subject: Re: [Json] Scope: Wire format or runtime format? X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 17 Jun 2013 04:18:06 -0000 Hello Norbert, On 2013/06/14 7:47, Norbert Lindenberg wrote: > In looking over older messages on this list, I found a message that made clear to me why we're having this endless discussion about Unicode surrogates - >it's because we're not clear whether we're designing a wire format or a format that also for use at runtime: > http://www.ietf.org/mail-archive/web/json/current/msg00355.html This is kind of the first time I have heard the term "format for use at runtime" in this context. Of course there are formats used at runtime (internal representations of number and strings, for example), but I think the term "runtime format" only confuses our discussion. In my understanding, JavaScript does not have or use JSON as a runtime format. If that has changed, then please tell us. > Some people are coming from the runtime point of view, especially ECMAScript, where it's accepted practice to use ill-formed UTF-16 or even non-text in strings. >At least the ill-formed UTF-16 is legitimized by section 2.7 of the Unicode standard. "Accepted practice" is probably going a bit too far, and giving the wrong impression. My understanding is that the Unicode standard accepts this for efficiency reasons, not because it's in anyway inherently useful. For ECMAScript, we have to add history to efficiency, but still I hope it's considered bad practice to actually use ill-formed UTF-16. > Other people are coming from the wire protocol point of view, where clean formats are expected, > in particular well-formed Unicode code unit sequences according to section 3.9 of the Unicode standard. > > So which one shall it be? > If we adopt the wire protocol point of view To me, it's very clear that we are describing (we are not designing; that has happened a long time ago, and very implicitly) a wire format, or something close to a wire format (somebody mentioned JSON embedded in an (e.g.) EUC-JP HTML page (*)). > and require well-formed code unit sequences, For practical reasons, I think we shouldn't go there. But we should make it very clear (in the base spec, not relegated to some "best practices" document) that using lone surrogates is a bad idea, and that senders and receivers MAY reject such data (e.g. because of security concerns). > then ECMAScript will have to define its own extension of JSON I very much hope we can avoid that. I very much hope that ECMAScript can tolerate that lone surrogates are often if not always a bad idea, even if they may sometimes happen for historical and efficiency reasons. > (which it has already by allowing JSON values at the top level). At least on the IETF side, as far as I know, this is still under discussion. > If we adopt the runtime point of view and allow all code points as in RFC 4627, then there probably should be separate verbiage defining a restricted version for use over the wire. I'm still at loss about what you mean by "runtime point of view". It seems very clear to me that neither the IETF version nor the ECMAScript version (in case they end up to differ) will in any way describe ECMAScript strings (or other datatypes) at runtime. Regards, Martin. (*) It's not impossible for me to imagine something like JSON embedded in an (e.g.) EUC-JP HTML page, but I'm seriously wondering how widespread this is in practice. A simple case would be that a script says "take the content of this element and interpret it as JSON". But how widespread is that? Of course, we have a lot of stuff inside ECMAScript, but as soon as I'm in ECMAScript, something like measurement = { 'unit': 'mm', 'amount': 15 } is no longer JSON, it's just ECMAScript literal notation. From James.H.Manger@team.telstra.com Sun Jun 16 22:02:45 2013 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 88E2621F9A31 for ; Sun, 16 Jun 2013 22:02:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.633 X-Spam-Level: X-Spam-Status: No, score=-0.633 tagged_above=-999 required=5 tests=[AWL=0.268, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FpEdFOQ2m-hR for ; Sun, 16 Jun 2013 22:02:39 -0700 (PDT) Received: from ipxbno.tcif.telstra.com.au (ipxbno.tcif.telstra.com.au [203.35.82.204]) by ietfa.amsl.com (Postfix) with ESMTP id E0F6021F9A30 for ; Sun, 16 Jun 2013 22:02:38 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.87,878,1363093200"; d="scan'208";a="134534556" Received: from unknown (HELO ipccni.tcif.telstra.com.au) ([10.97.216.208]) by ipobni.tcif.telstra.com.au with ESMTP; 17 Jun 2013 15:02:38 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,7108"; a="145213789" Received: from wsmsg3702.srv.dir.telstra.com ([172.49.40.170]) by ipccni.tcif.telstra.com.au with ESMTP; 17 Jun 2013 15:02:37 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3702.srv.dir.telstra.com ([172.49.40.170]) with mapi; Mon, 17 Jun 2013 15:02:37 +1000 From: "Manger, James H" To: "Joe Hildebrand (jhildebr)" , "json@ietf.org" Date: Mon, 17 Jun 2013 15:02:36 +1000 Thread-Topic: [Json] Proposal for strings/Unicode text Thread-Index: AQHOZ51Gb76aHFDldEuIrE325m6ppJkzAdeAgAAdpYCAAKLpAIAAIdEA///3qYCABYBx4A== Message-ID: <255B9BB34FB7D647A506DC292726F6E1151B931064@WSMSG3153V.srv.dir.telstra.com> References: <20130613121620.GB11739@mercury.ccil.org> In-Reply-To: Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [Json] Proposal for strings/Unicode text X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 17 Jun 2013 05:02:45 -0000 PiA+VGhlIHBvaW50IGlzIHRoYXQgaWYgSlNPTiBpcyBlbmNvZGVkIGluIFVURi04LCBhbnkgc3Vy cm9nYXRlIGNvZGUNCj4gPnBvaW50cyBNVVNUIGJlIGVzY2FwZWQsIGV2ZW4gdGhvdWdoIHRoZSBn cmFtbWFyIGRvZXMgbm90IHNheSBzby4NCj4gDQo+IFdoYXQgYWJvdXQgY2hhbmdpbmcgdGhlIGdy YW1tYXIgdG8gbWFrZSB0aGF0IGNsZWFyPw0KPiANCj4gdW5lc2NhcGVkID0gJXgyMC0yMSAvICV4 MjMtNUIgLyAleDVELSV4RDdGRiAvICVFMDAwLSUxMEZGRkYgIDsgQW55DQo+IHVuaWNvZGUgY29k ZSBwb2ludCBleGNlcHQgY29udHJvbCBjaGFyYWN0ZXJzLCBRVU9UQVRJT04gTUFSSywgIDsNCj4g UkVWRVJTRSBTT0xJRFVTLCBvciBjb2RlIHBvaW50cyByZXNlcnZlZCBmb3IgVVRGLTE2IHN1cnJv Z2F0ZXMNCg0KKzENClVucGFpcmVkIHN1cnJvZ2F0ZXMgY2Fubm90IGJlIGludGVyY2hhbmdlZCBy ZWxpYWJseSBzbyB0aGV5IHNob3VsZCBiZSBkcm9wcGVkIGZyb20gdGhpcyBBQk5GLiBJIGRvbid0 IG1pbmQgYSBub3RlIHNheWluZyBob3cgc29tZSBpbXBsZW1lbnRhdGlvbnMgaGFuZGxlIHRoZW0g KG9yIHRoZWlyIGVzY2FwZWQgZm9ybSkuDQoNCkZpeGluZyB0eXBvcyBhbmQgdHdlYWtpbmcgdGhl IGNvbW1lbnQ6DQoNCiAgdW5lc2NhcGVkID0gJXgyMC0yMSAvICV4MjMtNUIgLyAleDVELUQ3RkYg LyAleEUwMDAtMTBGRkZGDQogICAgOyBhbnkgVW5pY29kZSBzY2FsYXIgdmFsdWUsIGV4Y2VwdCB0 aG9zZSB0aGF0IG11c3QgYmUgZXNjYXBlZA0KICAgIDsgKGNvbnRyb2wgY2hhcmFjdGVycywgcXVv dGF0aW9uIG1hcmssIGFuZCByZXZlcnNlIHNvbGlkdXMpDQoNCi0tDQpKYW1lcyBNYW5nZXINCg== From ietf@lindenbergsoftware.com Mon Jun 17 01:21:29 2013 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 DEE2921F8FF3 for ; Mon, 17 Jun 2013 01:21:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.169 X-Spam-Level: X-Spam-Status: No, score=-3.169 tagged_above=-999 required=5 tests=[AWL=-0.470, BAYES_00=-2.599, J_CHICKENPOX_45=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N6LgFtBN8kmh for ; Mon, 17 Jun 2013 01:21:23 -0700 (PDT) Received: from mirach.lunarpages.com (mirach.lunarpages.com [216.97.235.70]) by ietfa.amsl.com (Postfix) with ESMTP id A287121F9634 for ; Mon, 17 Jun 2013 01:21:09 -0700 (PDT) Received: from 50-0-136-241.dsl.dynamic.sonic.net ([50.0.136.241]:60551 helo=[192.168.0.5]) by mirach.lunarpages.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1UoUgU-002DYL-FA; Mon, 17 Jun 2013 01:21:06 -0700 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Norbert Lindenberg In-Reply-To: <51BE8DEA.7030307@it.aoyama.ac.jp> Date: Mon, 17 Jun 2013 01:21:02 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <118A7923-5D66-4EF5-8A78-CAE125032010@lindenbergsoftware.com> References: <6FC6B441-B74D-4B9F-B883-065C05890880@lindenbergsoftware.com> <51BE8DEA.7030307@it.aoyama.ac.jp> To: =?iso-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= X-Mailer: Apple Mail (2.1283) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - mirach.lunarpages.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - lindenbergsoftware.com X-Get-Message-Sender-Via: mirach.lunarpages.com: authenticated_id: ietf@lindenbergsoftware.com Cc: Norbert Lindenberg , json@ietf.org Subject: Re: [Json] Scope: Wire format or runtime format? X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 17 Jun 2013 08:21:30 -0000 Hi Martin, On Jun 16, 2013, at 21:17 , Martin J. D=FCrst wrote: > Hello Norbert, >=20 > On 2013/06/14 7:47, Norbert Lindenberg wrote: >> In looking over older messages on this list, I found a message that = made clear to me why we're having this endless discussion about Unicode = surrogates - it's because we're not clear whether we're designing a wire = format or a format that also for use at runtime: >> http://www.ietf.org/mail-archive/web/json/current/msg00355.html >=20 > This is kind of the first time I have heard the term "format for use = at runtime" in this context. Of course there are formats used at runtime = (internal representations of number and strings, for example), but I = think the term "runtime format" only confuses our discussion. In my = understanding, JavaScript does not have or use JSON as a runtime format. = If that has changed, then please tell us. Maybe you have a better term for it: What I mean in the ECMAScript = context is the format that the functions JSON.parse and JSON.stringify = parse and produce [1]. The format is based on the JSON grammar, = represented in ECMAScript string values, that is, sequences of UTF-16 = code units. ECMAScript doesn't specify wire formats (it doesn't even = have any sort of I/O system), and has no control over what applications = do with the strings before passing them to parse() or after obtaining = them from stringify(). In many cases applications will get them from or = send them to some I/O system (such as XMLHttpRequest in the browser or = the file system module in Node.js), but they might modify them in = between, or do something completely different. >> Some people are coming from the runtime point of view, especially = ECMAScript, where it's accepted practice to use ill-formed UTF-16 or = even non-text in strings. At least the ill-formed UTF-16 is legitimized = by section 2.7 of the Unicode standard. >=20 > "Accepted practice" is probably going a bit too far, and giving the = wrong impression. My understanding is that the Unicode standard accepts = this for efficiency reasons, not because it's in anyway inherently = useful. For ECMAScript, we have to add history to efficiency, but still = I hope it's considered bad practice to actually use ill-formed UTF-16. "Grudgingly accepted practice"? Unfortunately, considering it bad = practice to use ill-formed UTF-16 or to represent JPEGs as string values = doesn't make it go away. >> Other people are coming from the wire protocol point of view, where = clean formats are expected, in particular well-formed Unicode code unit = sequences according to section 3.9 of the Unicode standard. >>=20 >> So which one shall it be? >>=20 >> If we adopt the wire protocol point of view >=20 > To me, it's very clear that we are describing (we are not designing; = that has happened a long time ago, and very implicitly) a wire format, = or something close to a wire format (somebody mentioned JSON embedded in = an (e.g.) EUC-JP HTML page (*)). >=20 >> and require well-formed code unit sequences, >=20 > For practical reasons, I think we shouldn't go there. But we should = make it very clear (in the base spec, not relegated to some "best = practices" document) that using lone surrogates is a bad idea, and that = senders and receivers MAY reject such data (e.g. because of security = concerns). John Cowan pointed to RFC 3629, which prohibits the use of surrogate = code points in UTF-8 [2]. Do you think that even for a wire format we = can ignore that prohibition? >> then ECMAScript will have to define its own extension of JSON >=20 > I very much hope we can avoid that. I very much hope that ECMAScript = can tolerate that lone surrogates are often if not always a bad idea, = even if they may sometimes happen for historical and efficiency reasons. The ECMAScript specification generally doesn't discuss good or bad = ideas; it just specifies the behavior of implementations. The specified = behavior is that unpaired surrogates in strings are passed through by = both parse() and stringify(), and parse() unescapes escape sequences for = all surrogate values, paired or not. Personally, I agree that unpaired surrogates are in most cases a bad = idea. [1] http://ecma-international.org/ecma-262/5.1/#sec-15.12 [2] http://www.ietf.org/mail-archive/web/json/current/msg00831.html Regards, Norbert From cowan@ccil.org Mon Jun 17 04:55:10 2013 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 2A8F221F9963 for ; Mon, 17 Jun 2013 04:55:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.147 X-Spam-Level: X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[AWL=-0.148, BAYES_00=-2.599, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5wJDKVG2qK5H for ; Mon, 17 Jun 2013 04:55:03 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id 0402A21F9294 for ; Mon, 17 Jun 2013 04:55:00 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1UoY1O-0004ac-5X; Mon, 17 Jun 2013 07:54:54 -0400 Date: Mon, 17 Jun 2013 07:54:54 -0400 From: John Cowan To: Norbert Lindenberg Message-ID: <20130617115453.GC19150@mercury.ccil.org> References: <6FC6B441-B74D-4B9F-B883-065C05890880@lindenbergsoftware.com> <51BE8DEA.7030307@it.aoyama.ac.jp> <118A7923-5D66-4EF5-8A78-CAE125032010@lindenbergsoftware.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <118A7923-5D66-4EF5-8A78-CAE125032010@lindenbergsoftware.com> User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Cc: =?iso-8859-1?B?Ik1hcnRpbiBKLiBE/HJzdCI=?= , json@ietf.org Subject: Re: [Json] Scope: Wire format or runtime format? X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 17 Jun 2013 11:55:11 -0000 Norbert Lindenberg scripsit: > Maybe you have a better term for it: What I mean in the ECMAScript > context is the format that the functions JSON.parse and JSON.stringify > parse and produce [1]. This simply is the description of JSON at the level of characters. -- Almost all theorems are true, John Cowan but almost all proofs have bugs. http://www.ccil.org/~cowan --Paul Pedersen From paul.hoffman@vpnc.org Mon Jun 17 06:59:08 2013 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 ACB6221F9C2F for ; Mon, 17 Jun 2013 06:59:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.488 X-Spam-Level: X-Spam-Status: No, score=-102.488 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iy+EwNHPQZei for ; Mon, 17 Jun 2013 06:59:08 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 36FAD21F9BB8 for ; Mon, 17 Jun 2013 06:59:08 -0700 (PDT) Received: from [10.20.30.90] (50-0-66-165.dsl.dynamic.sonic.net [50.0.66.165]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r5HDx6jg032757 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 17 Jun 2013 06:59:07 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Paul Hoffman In-Reply-To: <255B9BB34FB7D647A506DC292726F6E1151B931064@WSMSG3153V.srv.dir.telstra.com> Date: Mon, 17 Jun 2013 06:59:07 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <9DC91218-B255-4CA2-8337-41F7135A90BD@vpnc.org> References: <20130613121620.GB11739@mercury.ccil.org> <255B9BB34FB7D647A506DC292726F6E1151B931064@WSMSG3153V.srv.dir.telstra.com> To: "Manger, James H" X-Mailer: Apple Mail (2.1508) Cc: json@ietf.org Subject: Re: [Json] Proposal for strings/Unicode text X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 17 Jun 2013 13:59:08 -0000 On Jun 16, 2013, at 10:02 PM, "Manger, James H" = wrote: >>> The point is that if JSON is encoded in UTF-8, any surrogate code >>> points MUST be escaped, even though the grammar does not say so. >>=20 >> What about changing the grammar to make that clear? >>=20 >> unescaped =3D %x20-21 / %x23-5B / %x5D-%xD7FF / %E000-%10FFFF ; Any >> unicode code point except control characters, QUOTATION MARK, ; >> REVERSE SOLIDUS, or code points reserved for UTF-16 surrogates >=20 > +1 > Unpaired surrogates cannot be interchanged reliably so they should be = dropped from this ABNF. I don't mind a note saying how some = implementations handle them (or their escaped form). >=20 > Fixing typos and tweaking the comment: >=20 > unescaped =3D %x20-21 / %x23-5B / %x5D-D7FF / %xE000-10FFFF > ; any Unicode scalar value, except those that must be escaped > ; (control characters, quotation mark, and reverse solidus) Making comments in ABNF that disagree with the ABNF itself seems like a = completely terrible idea that will lead to lack of interoperability. = Complicated ABNF is better than simple ABNF that has contradictory = comments. --Paul Hoffman= From cowan@ccil.org Mon Jun 17 07:14:29 2013 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 894DC21F9CA6 for ; Mon, 17 Jun 2013 07:14:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.444 X-Spam-Level: X-Spam-Status: No, score=-3.444 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YjsIDKXVfbOs for ; Mon, 17 Jun 2013 07:14:15 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id A73A321F9CA8 for ; Mon, 17 Jun 2013 07:14:15 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1UoaC9-00039x-IY; Mon, 17 Jun 2013 10:14:10 -0400 Date: Mon, 17 Jun 2013 10:14:09 -0400 From: John Cowan To: Paul Hoffman Message-ID: <20130617141409.GB23594@mercury.ccil.org> References: <20130613121620.GB11739@mercury.ccil.org> <255B9BB34FB7D647A506DC292726F6E1151B931064@WSMSG3153V.srv.dir.telstra.com> <9DC91218-B255-4CA2-8337-41F7135A90BD@vpnc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9DC91218-B255-4CA2-8337-41F7135A90BD@vpnc.org> User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Cc: "Manger, James H" , json@ietf.org Subject: Re: [Json] Proposal for strings/Unicode text X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 17 Jun 2013 14:14:29 -0000 Paul Hoffman scripsit: > > unescaped = %x20-21 / %x23-5B / %x5D-D7FF / %xE000-10FFFF > > ; any Unicode scalar value, except those that must be escaped > > ; (control characters, quotation mark, and reverse solidus) > > Making comments in ABNF that disagree with the ABNF itself > seems like a completely terrible idea that will lead to lack of > interoperability. Complicated ABNF is better than simple ABNF that > has contradictory comments. Where's the contradiction? The prose says exactly what the ABNF says. %22 (quotation mark), %5C (backslash), and %D800 through %DFFF (surrogate pairs) are left out of the full Unicode range. -- No saves, Antonio, loke es morirse en su lingua. Es komo John Cowan kedarse soliko en el silensyo kada dya ke Dyo da, komo cowan@ccil.org ser sikileoso sin saver porke. http://www.ccil.org/~cowan --Marcel Cohen, 1985 From paul.hoffman@vpnc.org Mon Jun 17 07:23:09 2013 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 84BD421F9695 for ; Mon, 17 Jun 2013 07:23:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.49 X-Spam-Level: X-Spam-Status: No, score=-102.49 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CAinShYyVsJc for ; Mon, 17 Jun 2013 07:23:04 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 3A3AC21F9691 for ; Mon, 17 Jun 2013 07:23:03 -0700 (PDT) Received: from [10.20.30.90] (50-0-66-165.dsl.dynamic.sonic.net [50.0.66.165]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r5HEN03v033675 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 17 Jun 2013 07:23:01 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Paul Hoffman In-Reply-To: <20130617141409.GB23594@mercury.ccil.org> Date: Mon, 17 Jun 2013 07:23:00 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <7CF56357-6A86-4BAA-BFD8-225019A11980@vpnc.org> References: <20130613121620.GB11739@mercury.ccil.org> <255B9BB34FB7D647A506DC292726F6E1151B931064@WSMSG3153V.srv.dir.telstra.com> <9DC91218-B255-4CA2-8337-41F7135A90BD@vpnc.org> <20130617141409.GB23594@mercury.ccil.org> To: John Cowan X-Mailer: Apple Mail (2.1508) Cc: json@ietf.org Subject: Re: [Json] Proposal for strings/Unicode text X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 17 Jun 2013 14:23:09 -0000 On Jun 17, 2013, at 7:14 AM, John Cowan wrote: > Paul Hoffman scripsit: >=20 >>> unescaped =3D %x20-21 / %x23-5B / %x5D-D7FF / %xE000-10FFFF >>> ; any Unicode scalar value, except those that must be escaped >>> ; (control characters, quotation mark, and reverse solidus) >>=20 >> Making comments in ABNF that disagree with the ABNF itself >> seems like a completely terrible idea that will lead to lack of >> interoperability. Complicated ABNF is better than simple ABNF that >> has contradictory comments. >=20 > Where's the contradiction? The prose says exactly what the ABNF says. > %22 (quotation mark), %5C (backslash), and %D800 through %DFFF = (surrogate > pairs) are left out of the full Unicode range. U+0000-0019 is not the entire list of Unicode control characters? U+0022 = is not the only Unicode quotation mark. Did we not learn anything from the IDN WG work 13 years ago? --Paul Hoffman= From cowan@ccil.org Mon Jun 17 07:32:38 2013 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 38C6F21F9C88 for ; Mon, 17 Jun 2013 07:32:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.447 X-Spam-Level: X-Spam-Status: No, score=-3.447 tagged_above=-999 required=5 tests=[AWL=0.152, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dp62cZNGjKQe for ; Mon, 17 Jun 2013 07:32:33 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id D16D421F9C87 for ; Mon, 17 Jun 2013 07:32:33 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1UoaTw-00051U-Q5; Mon, 17 Jun 2013 10:32:32 -0400 Date: Mon, 17 Jun 2013 10:32:32 -0400 From: John Cowan To: Paul Hoffman Message-ID: <20130617143232.GC23594@mercury.ccil.org> References: <20130613121620.GB11739@mercury.ccil.org> <255B9BB34FB7D647A506DC292726F6E1151B931064@WSMSG3153V.srv.dir.telstra.com> <9DC91218-B255-4CA2-8337-41F7135A90BD@vpnc.org> <20130617141409.GB23594@mercury.ccil.org> <7CF56357-6A86-4BAA-BFD8-225019A11980@vpnc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <7CF56357-6A86-4BAA-BFD8-225019A11980@vpnc.org> User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Cc: json@ietf.org Subject: Re: [Json] Proposal for strings/Unicode text X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 17 Jun 2013 14:32:38 -0000 Paul Hoffman scripsit: > > Where's the contradiction? The prose says exactly what the ABNF says. > > %22 (quotation mark), %5C (backslash), and %D800 through %DFFF (surrogate > > pairs) are left out of the full Unicode range. > > U+0000-0019 is not the entire list of Unicode control characters? U+0022 > is not the only Unicode quotation mark. I assume by "19" you mean "1F". If you want to say "C0 control characters", fine. But there is only one Unicode character named "QUOTATION MARK", and it is the only one relevant to JSON. > Did we not learn anything from the IDN WG work 13 years ago? I don't see what that has to do with the price of pídàn in China. Other quotation marks and control characters need not be escaped in JSON. -- John Cowan cowan@ccil.org http://ccil.org/~cowan "The exception proves the rule." Dimbulbs think: "Your counterexample proves my theory." Latin students think "'Probat' means 'tests': the exception puts the rule to the proof." But legal historians know it means "Evidence for an exception is evidence of the existence of a rule in cases not excepted from." From paul.hoffman@vpnc.org Mon Jun 17 07:43:33 2013 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 0544621F9CB2 for ; Mon, 17 Jun 2013 07:43:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.492 X-Spam-Level: X-Spam-Status: No, score=-102.492 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g8r0RtmEPW60 for ; Mon, 17 Jun 2013 07:43:32 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id E63C021F9C97 for ; Mon, 17 Jun 2013 07:43:27 -0700 (PDT) Received: from [10.20.30.90] (50-0-66-165.dsl.dynamic.sonic.net [50.0.66.165]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r5HEhQio034341 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 17 Jun 2013 07:43:27 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Paul Hoffman In-Reply-To: <20130617143232.GC23594@mercury.ccil.org> Date: Mon, 17 Jun 2013 07:43:26 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <0CF14E73-C52E-4595-922E-296C13D5A3DD@vpnc.org> References: <20130613121620.GB11739@mercury.ccil.org> <255B9BB34FB7D647A506DC292726F6E1151B931064@WSMSG3153V.srv.dir.telstra.com> <9DC91218-B255-4CA2-8337-41F7135A90BD@vpnc.org> <20130617141409.GB23594@mercury.ccil.org> <7CF56357-6A86-4BAA-BFD8-225019A11980@vpnc.org> <20130617143232.GC23594@mercury.ccil.org> To: John Cowan X-Mailer: Apple Mail (2.1508) Cc: json@ietf.org Subject: Re: [Json] Proposal for strings/Unicode text X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 17 Jun 2013 14:43:33 -0000 On Jun 17, 2013, at 7:32 AM, John Cowan wrote: > Paul Hoffman scripsit: >=20 >>> Where's the contradiction? The prose says exactly what the ABNF = says. >>> %22 (quotation mark), %5C (backslash), and %D800 through %DFFF = (surrogate >>> pairs) are left out of the full Unicode range. >>=20 >> U+0000-0019 is not the entire list of Unicode control characters? = U+0022 >> is not the only Unicode quotation mark. >=20 > I assume by "19" you mean "1F". =20 Yes. :-) > If you want to say "C0 control > characters", fine. =20 That would work for me. But I suspect that some people will say "no, all = control characters". > But there is only one Unicode character named > "QUOTATION MARK", and it is the only one relevant to JSON. Then we should say that. Or, better, not have a comment that is open to = misinterpretation. >> Did we not learn anything from the IDN WG work 13 years ago? >=20 > I don't see what that has to do with the price of p=EDd=E0n in China. An excellent accidental analogy! I was referring to the fact that = "everyone" understood that the "dot" between DNS labels was U+002E... = except the Japanese. And we had to put a complicated exception in for = them, late in the process. > Other quotation marks and control characters need not be escaped in = JSON. If everyone agrees with that, then we do not need the comment at all. = But I suspect that "everyone" does not. --Paul Hoffman= From jhildebr@cisco.com Mon Jun 17 10:21:52 2013 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 43B0821F9D01 for ; Mon, 17 Jun 2013 10:21:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.799 X-Spam-Level: X-Spam-Status: No, score=-10.799 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oe5BYT0m8ZVu for ; Mon, 17 Jun 2013 10:21:43 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id E6F1821F940D for ; Mon, 17 Jun 2013 10:21:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=861; q=dns/txt; s=iport; t=1371489703; x=1372699303; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=rNUH/rWsDLvw+b2v4OrzZAIdP438RPNawA2riLrrvqM=; b=JtjH39kLVuS4n6auU23e1AHc7V4iqWDeOJgoYPBXrf7hNwUlgjTSWnfo 82GAxlXfAd7dOSstLkcBa6ot1ayFV4Y7Jumg5qstxgelUbsuus7NSjBK1 Q42+JjKzhZR6Tmen/uwI1YN783HpU51NNuQesuY2AxmK9uLlRww0otXL9 c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkYFABxFv1GtJXG8/2dsb2JhbABagwl6gji8QH4WdIIlAQQ6UQEIIhRCJQIEARIIh3QDD7EhHYhCjxY4gn9hA6kEgw+CKA X-IronPort-AV: E=Sophos;i="4.87,882,1363132800"; d="scan'208";a="223787253" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-2.cisco.com with ESMTP; 17 Jun 2013 17:21:42 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r5HHLg4f016761 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 17 Jun 2013 17:21:42 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.56]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.02.0318.004; Mon, 17 Jun 2013 12:21:42 -0500 From: "Joe Hildebrand (jhildebr)" To: "Manger, James H" , "json@ietf.org" Thread-Topic: [Json] Proposal for strings/Unicode text Thread-Index: AQHOZ51Gb76aHFDldEuIrE325m6ppJkzAdeAgAAdpYCAAKLpAIAAIdEA///3qYCABYBx4IAAwfEA Date: Mon, 17 Jun 2013 17:21:41 +0000 Message-ID: In-Reply-To: <255B9BB34FB7D647A506DC292726F6E1151B931064@WSMSG3153V.srv.dir.telstra.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [64.101.72.72] Content-Type: text/plain; charset="us-ascii" Content-ID: <222330342135DC4491460B04062986C8@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Json] Proposal for strings/Unicode text X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 17 Jun 2013 17:21:52 -0000 On 6/16/13 11:02 PM, "Manger, James H" wrote: >Fixing typos and tweaking the comment: > > unescaped =3D %x20-21 / %x23-5B / %x5D-D7FF / %xE000-10FFFF > ; any Unicode scalar value, except those that must be escaped > ; (control characters, quotation mark, and reverse solidus) After discussion, this? unescaped =3D %x20-21 / %x23-5B / %x5D-D7FF / %xE000-10FFFF ; any Unicode scalar value, except those that must be escaped ; (C0 control characters, ; "QUOTATION MARK" [U+0022], and ; "REVERSE SOLIDUS" [U+005C]) The caps and codepoint references make it clear we're only talking about those precise codepoints. Others may argue that non-C0 control characters should be prohibited, but that's a separate backward-compatibility argument from this starting point. --=20 Joe Hildebrand From paul.hoffman@vpnc.org Mon Jun 17 10:27:49 2013 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 5AC6221F9D49 for ; Mon, 17 Jun 2013 10:27:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.494 X-Spam-Level: X-Spam-Status: No, score=-102.494 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yq6+5ZLLAiB6 for ; Mon, 17 Jun 2013 10:27:48 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 1538621F9D86 for ; Mon, 17 Jun 2013 10:27:47 -0700 (PDT) Received: from [10.20.30.90] (50-0-66-165.dsl.dynamic.sonic.net [50.0.66.165]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r5HHRixK040308 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 17 Jun 2013 10:27:45 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Paul Hoffman In-Reply-To: Date: Mon, 17 Jun 2013 10:27:43 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <52755324-4C8D-452A-9A84-14691ACEEC7E@vpnc.org> References: To: Joe Hildebrand (jhildebr) X-Mailer: Apple Mail (2.1508) Cc: json@ietf.org Subject: Re: [Json] Proposal for strings/Unicode text X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 17 Jun 2013 17:27:49 -0000 On Jun 17, 2013, at 10:21 AM, Joe Hildebrand (jhildebr) = wrote: > On 6/16/13 11:02 PM, "Manger, James H" = > wrote: >=20 >> Fixing typos and tweaking the comment: >>=20 >> unescaped =3D %x20-21 / %x23-5B / %x5D-D7FF / %xE000-10FFFF >> ; any Unicode scalar value, except those that must be escaped >> ; (control characters, quotation mark, and reverse solidus) >=20 > After discussion, this? >=20 > unescaped =3D %x20-21 / %x23-5B / %x5D-D7FF / %xE000-10FFFF > ; any Unicode scalar value, except those that must be escaped > ; (C0 control characters, > ; "QUOTATION MARK" [U+0022], and > ; "REVERSE SOLIDUS" [U+005C]) >=20 > The caps and codepoint references make it clear we're only talking = about > those precise codepoints. >=20 > Others may argue that non-C0 control characters should be prohibited, = but > that's a separate backward-compatibility argument from this starting = point. What value is that comment? Doesn't it invite misinterpretation of the = ABNF, which is exact? --Paul Hoffman= From jhildebr@cisco.com Mon Jun 17 10:31:20 2013 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 02F6A21F9C15 for ; Mon, 17 Jun 2013 10:31:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.766 X-Spam-Level: X-Spam-Status: No, score=-10.766 tagged_above=-999 required=5 tests=[AWL=-0.167, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NSqC8oXBzFm8 for ; Mon, 17 Jun 2013 10:31:14 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 561AE21F9DAC for ; Mon, 17 Jun 2013 10:30:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1407; q=dns/txt; s=iport; t=1371490220; x=1372699820; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=ag/G88nnXzeRt1y8BBvUXW/ajwsaFrKCrUcb/rOMKI4=; b=EpcCKp/lj6z81RbSs9pYoApJgK1N0wBsQwe8PtpiCmGpX53Lx7Ihh1kn orG+14wriR0v52pkNubw7l7BLMml/J1/bBN3RHelH+plAoz5BbIBcK3K2 KTvhBGLUDhPR7FsNauhefr66DHVyX2F9HqMhAinGEseTsf8MfOcRj/O5d g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhUFAJZGv1GtJV2a/2dsb2JhbABagwl6vnh+FnSCIwEBAQQ6PxIBCBgKFEIlAgQOBQiHdAMPsSMdiEKPFjEHgn9hA6kEgw+CKA X-IronPort-AV: E=Sophos;i="4.87,882,1363132800"; d="scan'208";a="223815858" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-8.cisco.com with ESMTP; 17 Jun 2013 17:30:14 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r5HHUET0026255 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 17 Jun 2013 17:30:14 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.56]) by xhc-rcd-x04.cisco.com ([fe80::200:5efe:173.37.183.34%12]) with mapi id 14.02.0318.004; Mon, 17 Jun 2013 12:30:14 -0500 From: "Joe Hildebrand (jhildebr)" To: Paul Hoffman Thread-Topic: [Json] Proposal for strings/Unicode text Thread-Index: AQHOZ51Gb76aHFDldEuIrE325m6ppJkzAdeAgAAdpYCAAKLpAIAAIdEA///3qYCABYBx4IAAwfEAgABmSID//5wcgA== Date: Mon, 17 Jun 2013 17:30:13 +0000 Message-ID: In-Reply-To: <52755324-4C8D-452A-9A84-14691ACEEC7E@vpnc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [64.101.72.72] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "json@ietf.org" Subject: Re: [Json] Proposal for strings/Unicode text X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 17 Jun 2013 17:31:20 -0000 On 6/17/13 11:27 AM, "Paul Hoffman" wrote: >On Jun 17, 2013, at 10:21 AM, Joe Hildebrand (jhildebr) > wrote: > >> On 6/16/13 11:02 PM, "Manger, James H" >> wrote: >>=20 >>> Fixing typos and tweaking the comment: >>>=20 >>> unescaped =3D %x20-21 / %x23-5B / %x5D-D7FF / %xE000-10FFFF >>> ; any Unicode scalar value, except those that must be escaped >>> ; (control characters, quotation mark, and reverse solidus) >>=20 >> After discussion, this? >>=20 >> unescaped =3D %x20-21 / %x23-5B / %x5D-D7FF / %xE000-10FFFF >> ; any Unicode scalar value, except those that must be escaped >> ; (C0 control characters, >> ; "QUOTATION MARK" [U+0022], and >> ; "REVERSE SOLIDUS" [U+005C]) >>=20 >> The caps and codepoint references make it clear we're only talking about >> those precise codepoints. >>=20 >> Others may argue that non-C0 control characters should be prohibited, >>but >> that's a separate backward-compatibility argument from this starting >>point. > >What value is that comment? Doesn't it invite misinterpretation of the >ABNF, which is exact? We have comments after most everything else. Some of the readers of this doc aren't going to be savvy enough to be able to read the ABNF easily without the comment. However, I'd be fine with removing it. --=20 Joe Hildebrand From cabo@tzi.org Mon Jun 17 10:57:01 2013 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 1355F21F93DA for ; Mon, 17 Jun 2013 10:57:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.191 X-Spam-Level: X-Spam-Status: No, score=-106.191 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E40u2ftFx9cr for ; Mon, 17 Jun 2013 10:56:54 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 8060721F93BA for ; Mon, 17 Jun 2013 10:56:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r5HHueck006375; Mon, 17 Jun 2013 19:56:40 +0200 (CEST) Received: from [192.168.217.105] (p54893B55.dip0.t-ipconnect.de [84.137.59.85]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 1693C3C61; Mon, 17 Jun 2013 19:56:40 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <52755324-4C8D-452A-9A84-14691ACEEC7E@vpnc.org> Date: Mon, 17 Jun 2013 19:56:38 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <52755324-4C8D-452A-9A84-14691ACEEC7E@vpnc.org> To: Paul Hoffman X-Mailer: Apple Mail (2.1508) Cc: "Joe Hildebrand \(jhildebr\)" , json@ietf.org Subject: Re: [Json] Proposal for strings/Unicode text X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 17 Jun 2013 17:57:04 -0000 On Jun 17, 2013, at 19:27, Paul Hoffman wrote: > What value is that comment? Well, comments are always evil, because they mislead from the code. > Doesn't it invite misinterpretation of the ABNF, which is exact? The same argument could be made for begin-array =3D ws %x5B ws ; [ left square bracket Actually, I'd argue for keeping in that style. (And I know about U+27E6, U+301A, even U+FF3B.) If we do want to explain, do it like this? unescaped =3D ; any Unicode scalar value, except those that must be = escaped: ; must escape C0 control characters %x0-1F %x20-21 ; must escape %x22 " quotation mark / %x23-5B ; must escape %x5E \ reverse solidus / %x5D-D7FF ; not Unicode scalar values: %xD800-DFFF / %xE000-10FFFF Gr=FC=DFe, Carsten From paul.hoffman@vpnc.org Mon Jun 17 11:24:00 2013 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 8439D21F9C62 for ; Mon, 17 Jun 2013 11:23:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.497 X-Spam-Level: X-Spam-Status: No, score=-102.497 tagged_above=-999 required=5 tests=[AWL=0.102, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KImlx9CUmBUX for ; Mon, 17 Jun 2013 11:23:52 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id C82FF21F99A5 for ; Mon, 17 Jun 2013 11:23:50 -0700 (PDT) Received: from [10.20.30.90] (50-0-66-165.dsl.dynamic.sonic.net [50.0.66.165]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r5HINl10043198 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 17 Jun 2013 11:23:47 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Paul Hoffman In-Reply-To: Date: Mon, 17 Jun 2013 11:23:46 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <8BF89BC7-94E4-419D-BF7B-787022F7E7B2@vpnc.org> References: <52755324-4C8D-452A-9A84-14691ACEEC7E@vpnc.org> To: Carsten Bormann X-Mailer: Apple Mail (2.1508) Cc: "Joe Hildebrand \(jhildebr\)" , json@ietf.org Subject: Re: [Json] Proposal for strings/Unicode text X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 17 Jun 2013 18:24:00 -0000 Even though there are currently comments for all the simple strings, my = personal preference would not to be to add a comment to this more = complex one, and to instead let the ABNF stand on its own.=20 So far, the proposed comment additions have confused what JSON requires = to be *escaped* from what JSON *allows as codepoints* in strings. Adding = comments to spell out the character names will make this = misunderstanding worse, in my opinion. --Paul Hoffman= From mamille2@cisco.com Mon Jun 17 17:15:03 2013 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 A78CB21F9E7D for ; Mon, 17 Jun 2013 17:15:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N-9anGf4psK1 for ; Mon, 17 Jun 2013 17:14:58 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 0F1EC21F9E81 for ; Mon, 17 Jun 2013 17:14:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8647; q=dns/txt; s=iport; t=1371514491; x=1372724091; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=rMD77Ni0HKqRkMzWCLMIrJPU/R6I5CeFTYWtcLD3JM8=; b=ACVrScQQYTUFBXU7MzlA54mk+cj3h6pQHd2k491pAKGAMBzL9zzkJYkG mUNogRuT/DqTmqfXWCqIds5VoOO/0fyAGRhVn/wLgRgTmBy0S8HL3z0XC sRuLa3oXph2r70Ey9UDgGqN+NfQ+QXGWuYAG2J4bmDpsL/tDieqDQ21wj 4=; X-Files: smime.p7s : 4136 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhcFAKGlv1GtJXHB/2dsb2JhbABbgwkxSb8DfhZ0giMBAQEDAQEBAWsLBQsCAQgiJAIlCyUCBA4FCAaHegYMukMEjxYxB4J/YQOQAYEsgkKVFYMPgig X-IronPort-AV: E=Sophos;i="4.87,884,1363132800"; d="p7s'?scan'208";a="223964484" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-8.cisco.com with ESMTP; 18 Jun 2013 00:14:33 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r5I0EXGf019290 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 18 Jun 2013 00:14:33 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.24]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.02.0318.004; Mon, 17 Jun 2013 19:14:33 -0500 From: "Matt Miller (mamille2)" To: Douglas Crockford Thread-Topic: [Json] Two Documents Thread-Index: AQHOaE3TrpyS/+r1l0CLz5/49KZnUJk69M0A Date: Tue, 18 Jun 2013 00:14:32 +0000 Message-ID: References: <51B9EA49.2050604@crockford.com> In-Reply-To: <51B9EA49.2050604@crockford.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.21.148.109] Content-Type: multipart/signed; boundary="Apple-Mail=_ACF489E3-A365-43DF-A4EB-A648D150E4D5"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Cc: "json@ietf.org" Subject: Re: [Json] Two Documents X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 18 Jun 2013 00:15:03 -0000 --Apple-Mail=_ACF489E3-A365-43DF-A4EB-A648D150E4D5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hello Douglas, In order for the WG to fully understand your proposal, we need a more = definitive list of what to expect in each document. As a starting point, can you describe which sections of the current = RFC4627 would be in "JSON Data Interchange Format" and which would be in = the JSON best practices document? Clearly the latter will have many = additions from the recent discussions, but it is less clear which = portions of the current text goes into which document. Thanks, - m&m Matt Miller < mamille2@cisco.com > Cisco Systems, Inc. On Jun 13, 2013, at 9:50 AM, Douglas Crockford = wrote: > The confusion and controversy around this work is due to a mistake = that I > made in RFC 4627. The purpose of the RFC, which is clearly indicated > in the title, was to establish a MIME type. I also gave a description = of > the JSON Data Interchange Format. My mistake was in conflating the = two, > putting details about the MIME type into the description of the = format. My > intention was to add clarity. That obviously was not the result. >=20 > JSON is just a format. It describes a syntax of brackets and commas = that > is useful in many contexts, profiles, and applications. JSON is = agnostic > about all of that stuff. JSON shouldn't even care about character = encoding. > Its only dependence on Unicode in the hex numbers used in the \u = notation. > JSON can be encoded in ASCII or EBCDIC or even Hollerith codes. JSON = can > be used in contexts where there is no character encoding at all, such = as > paper documents and marble monuments. >=20 > There are uses of JSON however in which such choices matter, and where > behavior needs to be attached to or derived from the syntax. That is > important stuff, and it belongs in different documents. Such documents > will place necessary restrictions on JSON's potential. No such = document > can fit all applications, which causes much of the controversy we've = seen > here. One size cannot fit all. JSON the format is universal. But real > applications require reasonable restrictions. >=20 > So we should be working on at least two documents, which is something = we have > discussed earlier. The first is The JSON Data Interchange Format, = which is > a simple grammar. The second is a best practices document, which = recommends > specific conventions of usage. >=20 > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json --Apple-Mail=_ACF489E3-A365-43DF-A4EB-A648D150E4D5 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMezCCBjQw ggQcoAMCAQICAR4wDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDE1NVoX DTE3MTAyNDIxMDE1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMcJg8zOLdgasSmkLhOrlr6KMoOMpohBllVHrdRvEg/q6r8jR+EK 75xCGhR8ToREoqe7zM9/UnC6TS2y9UKTpT1v7RSMzR0t6ndl0TWBuUr/UXBhPk+Kmy7bI4yW4urC +y7P3/1/X7U8ocb8VpH/Clt+4iq7nirMcNh6qJR+xjOhV+VHzQMALuGYn5KZmc1NbJQYclsGkDxD z2UbFqE2+6vIZoL+jb9x4Pa5gNf1TwSDkOkikZB1xtB4ZqtXThaABSONdfmv/Z1pua3FYxnCFmdr /+N2JLKutIxMYqQOJebr/f/h5t95m4JgrM3Y/w7YX9d7YAL9jvN4SydHsU6n65cCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRTcu2SnODaywFc fH6WNU7y1LhRgjAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBAAqDCH14qywG XLhjjF6uHLkjd02hcdh9hrw+VUsv+q1eeQWB21jWj3kJ96AUlPCoEGZ/ynJNScWy6QMVQjbbMXlt UfO4n4bGGdKo3awPWp61tjAFgraLJgDk+DsSvUD6EowjMTNx25GQgyYJ5RPIzKKR9tQW8gGK+2+R HxkUCTbYFnL6kl8Ch507rUdPPipJ9CgJFws3kDS3gOS5WFMxcjO5DwKfKSETEPrHh7p5shuuNktv sv6hxHTLhiMKX893gxdT3XLS9OKmCv87vkINQcNEcIIoFWbP9HORz9v3vQwR4e3ksLc2JZOAFK+s sS5XMEoznzpihEP0PLc4dCBYjbvSD7kxgDwZ+Aj8Q9PkbvE9sIPP7ON0fz095HdThKjiVJe6vofq +n6b1NBc8XdrQvBmunwxD5nvtTW4vtN6VY7mUCmxsCieuoBJ9OlqmsVWQvifIYf40dJPZkk9YgGT zWLpXDSfLSplbY2LL9C9U0ptvjcDjefLTvqSFc7tw1sEhF0n/qpA2r0GpvkLRDmcSwVyPvmjFBGq Up/pNy8ZuPGQmHwFi2/14+xeSUDG2bwnsYJQG2EdJCB6luQ57GEnTA/yKZSTKI8dDQa8Sd3zfXb1 9mOgSF0bBdXbuKhEpuP9wirslFe6fQ1t5j5R0xi72MZ8ikMu1RQZKCyDbMwazlHiMIIGPzCCBSeg AwIBAgIDBoRIMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcN MTMwNDMwMjE1NDQyWhcNMTQwNTAyMDUzOTA0WjBbMRkwFwYDVQQNExBiN2F6NndOY0t0R3JtMEpF MRswGQYDVQQDDBJtYW1pbGxlMkBjaXNjby5jb20xITAfBgkqhkiG9w0BCQEWEm1hbWlsbGUyQGNp c2NvLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJbKBMsG+9UFTx9uq/bhhXgu vJvO8z7cwKaqqwZhVf5z/kHFyCNijtmTOE+YXjA8mWR4aoBwB5SvGypI/cJUofJ+AlBTC4g+RMx/ K0Ab4/jQqTQz9CDzMOB+Wm+rt8ZJ7A8ZzOJmNDAsf/VvB8l2A1SQz1UsAixgH16NTr8SlblAXEKk 4hwpCudUiNjjQokqJ0H686UBKVorcZSgXaza8XMqGtJF/8mNhR9GQYi7Xht1ky+9LFOrto2daZto KJRwMeVusVdHUeKEQSu7jztw8HchH3KEb7Q+r5X+hhDZoddfKE8d5eyPuhiZdrzv7OlNZ0fSLdx7 3AE3nx9/R5YlXucCAwEAAaOCAtgwggLUMAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQW MBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQUxGd+/qrdVudHrIKkw5xOMY7eaLUwHwYD VR0jBBgwFoAUU3Ltkpzg2ssBXHx+ljVO8tS4UYIwHQYDVR0RBBYwFIESbWFtaWxsZTJAY2lzY28u Y29tMIIBTAYDVR0gBIIBQzCCAT8wggE7BgsrBgEEAYG1NwECAzCCASowLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0 Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBp c3N1ZWQgYWNjb3JkaW5nIHRvIHRoZSBDbGFzcyAxIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9m IHRoZSBTdGFydENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBw dXJwb3NlIGluIGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMDYG A1UdHwQvMC0wK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUxLWNybC5jcmwwgY4G CCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIv Y2xhc3MxL2NsaWVudC9jYTBCBggrBgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2Vy dHMvc3ViLmNsYXNzMS5jbGllbnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRz c2wuY29tLzANBgkqhkiG9w0BAQUFAAOCAQEAlDhXbGEI7lbqUcu5r2JHZaMsbRZda/99ZqODzWGX 0llou9jGccsAWDPPwRRe2+ROpXfH4cuJZElTcLDeZSp/qpXKhjYieFSX8+Ml9sKEj5UOSqQLyoLk PtrIJV12Jk3nuG2Jc0UeEnGwK/aqtzy7+bfEVI0ziyVM2gChHh0RH74KyiwYWknbOTRIkZcz/ulE DVFQp63uj6wfmDNvAUHBAdhKVqA1S/rfP1KcDZpf1NfvwXJibiqTRA6K1EOxTJOP41n/XdvHqHXL RWL2xrOUI9/URANr/ok3OrsuZEMFnAAGefS1bWS/hFtUGVkHGiKEBbyDW7da2ULXbuC7umrQnzGC A28wggNrAgEBMIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkG A1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwaESDAJBgUrDgMCGgUA oIIBrzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMzA2MTgwMDE0 MjhaMCMGCSqGSIb3DQEJBDEWBBRY5KTf+Dc0Wv9O6Y1vzpIWWDgwnzCBpQYJKwYBBAGCNxAEMYGX MIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3Mg MSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwaESDCBpwYLKoZIhvcNAQkQAgsxgZeg gZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1 cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAx IFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDBoRIMA0GCSqGSIb3DQEBAQUABIIBACGT QEPrzGlLNVSzLYRwwMiFWcoF7R0D6emhQBxwZjSMrcTCFcVtlEpDfCu+Y142PNEEkR6XCS/vZ31M NbUJ2pVuYCLNvNZyDR5lG2uMCKKKoihSjMXk92qRx7Ffsxy35Q2OEow3XGptji8fgPVFS2pgIpl1 Yt1tHMGq4ZjzumBm58tn7t0YQAMR21rQ5/jfHTD71BZt3h9TIBY2ZUsAshe65rJclN4Gd1fLo1Ho xKZuUf8nRe8P4tmjUZtSHTPG3SS28pXoQeKXy59+9fuQTOowXhkjqfzDhzoTn02Vr190rTLH0nGa iQmNSc0wNA6PjQNI/Uxr/c+QSivYCTpjCDYAAAAAAAA= --Apple-Mail=_ACF489E3-A365-43DF-A4EB-A648D150E4D5-- From jsontest@yahoo.com Mon Jun 17 20:20:07 2013 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 A662F21F9B9F for ; Mon, 17 Jun 2013 20:20:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.47 X-Spam-Level: X-Spam-Status: No, score=-0.47 tagged_above=-999 required=5 tests=[AWL=0.734, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bSkWlSRHq1cj for ; Mon, 17 Jun 2013 20:20:02 -0700 (PDT) Received: from nm38-vm6.bullet.mail.gq1.yahoo.com (nm38-vm6.bullet.mail.gq1.yahoo.com [98.136.217.77]) by ietfa.amsl.com (Postfix) with ESMTP id DB79C21F9B8E for ; Mon, 17 Jun 2013 20:20:01 -0700 (PDT) Received: from [98.137.12.55] by nm38.bullet.mail.gq1.yahoo.com with NNFMP; 18 Jun 2013 03:19:56 -0000 Received: from [208.71.42.193] by tm15.bullet.mail.gq1.yahoo.com with NNFMP; 18 Jun 2013 03:19:56 -0000 Received: from [127.0.0.1] by smtp204.mail.gq1.yahoo.com with NNFMP; 18 Jun 2013 03:19:56 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1371525596; bh=bz4OK4i6wshlW7W94JxhUxn3jiLSn2VZdQWj9EJb+OY=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:References:In-Reply-To:Mime-Version:Content-Type:Content-Transfer-Encoding:Message-Id:Cc:X-Mailer:From:Subject:Date:To; b=Cu7sOqeYPlTg+aHT5O9KkXgoLU1Ry/bB6hocNebJrf7iJG88xnLmroxCeKrGvJ4rZrzZgepInJ5gkefcnra8FZ3MZNjE4Ee4JDTzSGROBM0Or9+QKUJ2MmlrNHeB4nAnzc8sBgOQA1vHiH5FmPOGSLH88phHrwz0vszLzmeiLt4= X-Yahoo-Newman-Id: 371631.23211.bm@smtp204.mail.gq1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: _ZaGbH4VM1mgrum7q5QyL4oe2h9pK8VvPQ21lD4v1PKopST Lzkg3K2Y70TIlQqLcce1PLOSr0mi0RUsoDIyEkuIIn9vmk5dAu2qs2f__dE2 TBjXM1SAQIOvkq0n5QRy.EWQa9QWB0NFZ8Zqj_0lsO9SSdnY00fQzoiaYToK J0ww154cshSs8h0oK6zTX3f1CurG3L_.S22Pa8jZgvORC1.3QjwgdcygYayZ XIj.y08dBj4qjjhMkuB4lbD5xqx7wNLtWHdbQb7_rXalhxdlyhDyhBvqXMI3 amU.rGeh5FrdrrqAWHICnFS95KUgybQfrioGSm.1TzrRsfJAZSZPL0QFS997 2Bw.zVLU_RdOuHiIuY8AYl46FPp1ZA7Mvr.majNGYVjwH.VS9ZQhF1cS2UYO y8VOzi7.WygXWVyGkGv9AGeO_xeGYxxxSpOaqHlzUWpDzk0xzq7viDCo3QGa iuBLVSXjI0zJ3fCNxrP5iC8z_xuwejn4af8VozLrVgevvbhf7sUHVEXVJMsW 4hBP4suYEPlReKf9s3LZKPeiS X-Yahoo-SMTP: indQcmSswBC8IKsm6t4aCAPskK3T X-Rocket-Received: from [192.168.0.102] (jsontest@76.29.100.42 with ) by smtp204.mail.gq1.yahoo.com with SMTP; 17 Jun 2013 20:19:56 -0700 PDT References: <51B9EA49.2050604@crockford.com> In-Reply-To: Mime-Version: 1.0 (1.0) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <5FBB0E3C-E538-48F9-AD32-45AD00151C12@yahoo.com> X-Mailer: iPod Mail (9B206) From: Vinny A Date: Mon, 17 Jun 2013 22:19:52 -0500 To: "Matt Miller (mamille2)" Cc: Douglas Crockford , "json@ietf.org" Subject: Re: [Json] Two Documents X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 18 Jun 2013 03:20:07 -0000 On Jun 17, 2013, at 7:14 PM, "Matt Miller (mamille2)" w= rote: > Hello Douglas, >=20 > In order for the WG to fully understand your proposal, we need a more defi= nitive list of what to expect in each document. >=20 > As a starting point, can you describe which sections of the current RFC462= 7 would be in "JSON Data Interchange Format" and which would be in the JSON b= est practices document? Clearly the latter will have many additions from th= e recent discussions, but it is less clear which portions of the current tex= t goes into which document. Obviously I'm not Douglas, but I'd like to make a proposal in this departmen= t. The simplicity of the JSON standard has proven to be one of the many reasons= why it's so popular. It would be a shame if we ended up bloating the offici= al standard with miscellaneous nitpicks and advice. Clearly the standard nee= ds some touch-up work (duplicate keys, for instance) - but it should be limi= ted to just that, touch up work. Everything else should be reserved for the best practices document; basicall= y the rule of thumb would be that any new topics should be moved to best pra= ctices, while any current topics in the RFC should stay. Here's a short list= of potential best practice topic candidates (additions/deletions welcome):=20= - Unicode processing - Runtime/Wire format recommendations - Streaming parser recommendations - Additional MIME types - Comments - String comparison - Miscellaneous ----------------- Vinny www.jsontest.com From ietf@lindenbergsoftware.com Mon Jun 17 23:07:12 2013 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 2DFBF21F9DE0 for ; Mon, 17 Jun 2013 23:07:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.541 X-Spam-Level: X-Spam-Status: No, score=-4.541 tagged_above=-999 required=5 tests=[AWL=1.058, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WswpUBFWNoNJ for ; Mon, 17 Jun 2013 23:07:07 -0700 (PDT) Received: from mirach.lunarpages.com (mirach.lunarpages.com [216.97.235.70]) by ietfa.amsl.com (Postfix) with ESMTP id F217621F9DD3 for ; Mon, 17 Jun 2013 23:07:06 -0700 (PDT) Received: from 50-0-136-241.dsl.dynamic.sonic.net ([50.0.136.241]:62872 helo=[192.168.0.5]) by mirach.lunarpages.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1Uop4K-0014Jr-0d; Mon, 17 Jun 2013 23:07:04 -0700 From: Norbert Lindenberg Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Mon, 17 Jun 2013 23:07:00 -0700 Message-Id: <8FDBF4EF-B2DF-458E-834E-5707ED7B27C9@lindenbergsoftware.com> To: Paul Hoffman Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - mirach.lunarpages.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - lindenbergsoftware.com X-Get-Message-Sender-Via: mirach.lunarpages.com: authenticated_id: ietf@lindenbergsoftware.com Cc: Norbert Lindenberg , json@ietf.org Subject: [Json] Ambiguous character references X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 18 Jun 2013 06:07:12 -0000 The existing text in section 2.5 of RFC 4627, first through third = paragraph, has the same ambiguous character references as discussed = below. Do they need to be fixed? quotation marks -> quotation marks (U+0022) quotation mark -> quotation mark (U+0022) reverse solidus -> reverse solidus (U+005C) control characters (U+0000 through U+001F) -> control characters U+0000 = through U+001F lowercase letter u -> Latin small letter u (U+0075) hexadecimal digits -> hexadecimal digits U+0030 through U+0039, U+0041 = through U+0046, U+0061 through U+0066 Norbert On Jun 17, 2013, at 7:43 , Paul Hoffman wrote: > On Jun 17, 2013, at 7:32 AM, John Cowan = wrote: >=20 >> Paul Hoffman scripsit: >>=20 >>>> Where's the contradiction? The prose says exactly what the ABNF = says. >>>> %22 (quotation mark), %5C (backslash), and %D800 through %DFFF = (surrogate >>>> pairs) are left out of the full Unicode range. >>>=20 >>> U+0000-0019 is not the entire list of Unicode control characters? = U+0022 >>> is not the only Unicode quotation mark. >>=20 >> I assume by "19" you mean "1F". =20 >=20 > Yes. :-) >=20 >> If you want to say "C0 control >> characters", fine. =20 >=20 > That would work for me. But I suspect that some people will say "no, = all control characters". >=20 >> But there is only one Unicode character named >> "QUOTATION MARK", and it is the only one relevant to JSON. >=20 > Then we should say that. Or, better, not have a comment that is open = to misinterpretation. >=20 >>> Did we not learn anything from the IDN WG work 13 years ago? >>=20 >> I don't see what that has to do with the price of p=EDd=E0n in China. >=20 > An excellent accidental analogy! I was referring to the fact that = "everyone" understood that the "dot" between DNS labels was U+002E... = except the Japanese. And we had to put a complicated exception in for = them, late in the process. >=20 >> Other quotation marks and control characters need not be escaped in = JSON. >=20 > If everyone agrees with that, then we do not need the comment at all. = But I suspect that "everyone" does not. >=20 > --Paul Hoffman > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json From ietf@lindenbergsoftware.com Mon Jun 17 23:18:14 2013 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 695AD21F9AE8 for ; Mon, 17 Jun 2013 23:18:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.692 X-Spam-Level: X-Spam-Status: No, score=-4.692 tagged_above=-999 required=5 tests=[AWL=0.907, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E1PMdjzoUzKp for ; Mon, 17 Jun 2013 23:18:08 -0700 (PDT) Received: from mirach.lunarpages.com (mirach.lunarpages.com [216.97.235.70]) by ietfa.amsl.com (Postfix) with ESMTP id 996FD21F9AE1 for ; Mon, 17 Jun 2013 23:18:08 -0700 (PDT) Received: from 50-0-136-241.dsl.dynamic.sonic.net ([50.0.136.241]:62909 helo=[192.168.0.5]) by mirach.lunarpages.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1UopF1-0015UG-66; Mon, 17 Jun 2013 23:18:07 -0700 From: Norbert Lindenberg Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 17 Jun 2013 23:18:03 -0700 Message-Id: To: json@ietf.org Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - mirach.lunarpages.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - lindenbergsoftware.com X-Get-Message-Sender-Via: mirach.lunarpages.com: authenticated_id: ietf@lindenbergsoftware.com Cc: Norbert Lindenberg Subject: [Json] Typo: A though F X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 18 Jun 2013 06:18:14 -0000 Section 2.5 of RFC 4627, second paragraph, has "hexadecimal letters A = though F". "though" should be "through". Norbert From ietf@lindenbergsoftware.com Tue Jun 18 00:19:17 2013 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 AD7F521F9D22 for ; Tue, 18 Jun 2013 00:19:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.805 X-Spam-Level: X-Spam-Status: No, score=-4.805 tagged_above=-999 required=5 tests=[AWL=0.794, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7YdUjhYk+C3e for ; Tue, 18 Jun 2013 00:19:13 -0700 (PDT) Received: from mirach.lunarpages.com (mirach.lunarpages.com [216.97.235.70]) by ietfa.amsl.com (Postfix) with ESMTP id A42C421F9D21 for ; Tue, 18 Jun 2013 00:19:09 -0700 (PDT) Received: from 50-0-136-241.dsl.dynamic.sonic.net ([50.0.136.241]:63031 helo=[192.168.0.5]) by mirach.lunarpages.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1UoqC4-001CwH-Eh; Tue, 18 Jun 2013 00:19:08 -0700 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=windows-1252 From: Norbert Lindenberg In-Reply-To: Date: Tue, 18 Jun 2013 00:19:03 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <99C11E2A-FE05-4C6E-B68D-DA5E9D0493B9@lindenbergsoftware.com> References: To: Tim Bray X-Mailer: Apple Mail (2.1283) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - mirach.lunarpages.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - lindenbergsoftware.com X-Get-Message-Sender-Via: mirach.lunarpages.com: authenticated_id: ietf@lindenbergsoftware.com Cc: Norbert Lindenberg , "json@ietf.org" Subject: Re: [Json] Proposal for strings/Unicode text X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 18 Jun 2013 07:19:17 -0000 On Jun 12, 2013, at 15:54 , Tim Bray wrote: > On Wed, Jun 12, 2013 at 3:46 PM, Norbert Lindenberg = wrote: > The JSON RFC seems to use Unicode character names, in this case case = "reverse solidus". >=20 > We=92re not allowed to change JSON but we are allowed to improve the = spec. The term =93solidus=94 is obscure and off-putting. If that's how you feel: Is there a proposal then to replace all = occurrences of "solidus" and "reverse solidus" in the RFC? There are = more, and the issue doesn't seem connected to the character vs. code = point issue. =20 >> > 16-bit quantities (normally Unicode characters from the Basic = Multingual Pane(U+0000 through U+FFFF) may be =93escaped=94, or = represented as a six-character sequence: a backslash (U+005C REVERSE = SOLIDUS), followed by the lowercase letter u, followed by four = hexadecimal digits that encode the character's code point. The = hexadecimal letters A though F can be upper or lower case. So, for = example, a string containing only a single backslash may be represented = as "\u005C". >>=20 >> These escape sequences aren't about 16-bit quantities - they = represent Unicode BMP code points. > =20 > They also represent surrogates. Thus they combine fish and bicycles, = and I think the only accurate way to describe what you can escape is = =9316-bit quantities=94 Surrogate code points are BMP code points (see = http://www.unicode.org/glossary). They are an awkward kind of code point = and are best avoided, but I don't see what fish or bicycles have to do = with them. Also, as I explained before, in some environments there are no 16-bit = quantities in either input or output. Norbert From ietf@lindenbergsoftware.com Tue Jun 18 00:44:03 2013 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 D25B321F9C69 for ; Tue, 18 Jun 2013 00:44:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.893 X-Spam-Level: X-Spam-Status: No, score=-4.893 tagged_above=-999 required=5 tests=[AWL=0.706, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j6HSGz58nGnK for ; Tue, 18 Jun 2013 00:43:59 -0700 (PDT) Received: from mirach.lunarpages.com (mirach.lunarpages.com [216.97.235.70]) by ietfa.amsl.com (Postfix) with ESMTP id 1A3B621F9C50 for ; Tue, 18 Jun 2013 00:43:59 -0700 (PDT) Received: from 50-0-136-241.dsl.dynamic.sonic.net ([50.0.136.241]:63054 helo=[192.168.0.5]) by mirach.lunarpages.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1Uoqa5-001GAA-T4; Tue, 18 Jun 2013 00:43:58 -0700 From: Norbert Lindenberg Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 18 Jun 2013 00:43:53 -0700 Message-Id: <05A7D2E5-C119-4900-B52B-54B0F1206300@lindenbergsoftware.com> To: json@ietf.org Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - mirach.lunarpages.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - lindenbergsoftware.com X-Get-Message-Sender-Via: mirach.lunarpages.com: authenticated_id: ietf@lindenbergsoftware.com Cc: Norbert Lindenberg Subject: [Json] Proposal: Code points and surrogates X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 18 Jun 2013 07:44:04 -0000 This proposal attempts to clarify that JSON allows all Unicode code = points, but also which issues exist with surrogate code points. It = proposes no normative changes so as to remain compatible with the = ECMAScript specification, but recommends that clients carefully consider = whether to allow surrogate code points in their uses of JSON. Details: - changed from "character" to "code point", unless specific characters = are referenced, - added paragraph with information about surrogate code points, - rearranged paragraphs so that escape sequences for BMP and non-BMP = code points are discussed side by side. Compared to Tim's proposal [1], this proposal - says what the specification actually allows (code points) rather than = what may be intended (characters), - gets rid of the term "16-bit quantities", - provides more concrete information about surrogate code points than = just "breakage", - doesn't discuss the need, or lack thereof, to update the RFC in the = future. Section 1, Introduction: Before: A string is a sequence of zero or more Unicode characters [UNICODE]. After: A string is a sequence of zero or more Unicode code points = [UNICODE]. Section 2.5, Strings: A string begins and ends with quotation marks. All Unicode code points = may be placed within the quotation marks except for the characters that = must be escaped: quotation mark, reverse solidus, and the control = characters (U+0000 through U+001F). Any code point may be escaped. If the code point is in the Basic = Multilingual Plane (U+0000 through U+FFFF), then it may be represented = as a six-character sequence: a reverse solidus, followed by the = lowercase letter u, followed by four hexadecimal digits that encode the = code point. The hexadecimal letters A though F can be upper or = lowercase. So, for example, a string containing only a single reverse = solidus character may be represented as "\u005C". To escape a code point that is not in the Basic Multilingual Plane, the = code point is represented as a twelve-character sequence, encoding the = UTF-16 surrogate pair. So, for example, a string containing only the G = clef character (U+1D11E) may be represented as "\uD834\uDD1E". Alternatively, there are two-character sequence escape representations = of some popular characters. So, for example, a string containing only a = single reverse solidus character may be represented more compactly as = "\\". Note that this specification allows the inclusion of surrogate code = points (U+D800 through U+DFFF) in JSON text, both directly and through = escape sequences. However, Unicode code unit sequences containing = surrogate code points are not well-formed, are prohibited by standards = such as [RFC 3629], and may be rejected or modified by software such as = character encoding converters. Developers and specification authors = should carefully consider whether to allow surrogate code points in = their uses of JSON. [continue with grammar] Section 4, Parsers: Before: An implementation may set limits on the length and character contents = of strings. After: An implementation may set limits on the length and code point = contents of strings. [1] http://www.ietf.org/mail-archive/web/json/current/msg00814.html Norbert From ietf@lindenbergsoftware.com Tue Jun 18 00:44:06 2013 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 56A8521F9CFE for ; Tue, 18 Jun 2013 00:44:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.964 X-Spam-Level: X-Spam-Status: No, score=-3.964 tagged_above=-999 required=5 tests=[AWL=-0.365, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AATILJsjUS7n for ; Tue, 18 Jun 2013 00:43:59 -0700 (PDT) Received: from mirach.lunarpages.com (mirach.lunarpages.com [216.97.235.70]) by ietfa.amsl.com (Postfix) with ESMTP id 8B54A21F9CD0 for ; Tue, 18 Jun 2013 00:43:59 -0700 (PDT) Received: from 50-0-136-241.dsl.dynamic.sonic.net ([50.0.136.241]:63054 helo=[192.168.0.5]) by mirach.lunarpages.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1Uoqa6-001GAA-EF; Tue, 18 Jun 2013 00:43:58 -0700 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Norbert Lindenberg In-Reply-To: <20130613181955.GH29284@mercury.ccil.org> Date: Tue, 18 Jun 2013 00:43:56 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130613003213.GA26989@mercury.ccil.org> <20130613121620.GB11739@mercury.ccil.org> <20130613181955.GH29284@mercury.ccil.org> To: John Cowan X-Mailer: Apple Mail (2.1283) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - mirach.lunarpages.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - lindenbergsoftware.com X-Get-Message-Sender-Via: mirach.lunarpages.com: authenticated_id: ietf@lindenbergsoftware.com Cc: Norbert Lindenberg , Bjoern Hoehrmann , Tim Bray , "json@ietf.org" Subject: Re: [Json] Proposal for strings/Unicode text X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 18 Jun 2013 07:44:06 -0000 On Jun 13, 2013, at 11:19 , John Cowan wrote: > Tim Bray scripsit: >=20 >> This will break lots of things, not just UTF-8 decoders (most of = which, >> I bet, will never actually notice). -T >=20 > Modern ones that pay attention to spoofing most definitely will. I did a bit of testing: In the current versions of the major desktop = browsers (Firefox, Chrome, Safari, Explorer, Opera) the UTF-8 decoders = used for external scripts and XMLHttpRequest replace CESU-8 encoded = surrogate code points with replacement character sequences of varying = lengths. In the current version of Node.js, the UTF-8 decoder used for = external scripts will pass them through, with the effect that a sequence = of CESU-8 encoded surrogate code points can turn into a valid = supplementary character in UTF-16. Norbert= From duerst@it.aoyama.ac.jp Tue Jun 18 03:24:22 2013 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 6918221F9B57 for ; Tue, 18 Jun 2013 03:24:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.99 X-Spam-Level: X-Spam-Status: No, score=-100.99 tagged_above=-999 required=5 tests=[AWL=-1.800, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_45=0.6, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PD5h066r+o5b for ; Tue, 18 Jun 2013 03:24:16 -0700 (PDT) Received: from scintmta01.scbb.aoyama.ac.jp (scintmta01.scbb.aoyama.ac.jp [133.2.253.33]) by ietfa.amsl.com (Postfix) with ESMTP id B70D721F9DAC for ; Tue, 18 Jun 2013 03:24:15 -0700 (PDT) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta01.scbb.aoyama.ac.jp (secret/secret) with SMTP id r5IAO9lC004161; Tue, 18 Jun 2013 19:24:10 +0900 Received: from (unknown [133.2.206.134]) by scmse02.scbb.aoyama.ac.jp with smtp id 2bc9_8000_3650eb16_d801_11e2_8948_001e6722eec2; Tue, 18 Jun 2013 19:24:08 +0900 Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id 7C3CBBF550; Tue, 18 Jun 2013 19:22:49 +0900 (JST) Message-ID: <51C0353C.3010100@it.aoyama.ac.jp> Date: Tue, 18 Jun 2013 19:23:56 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: John Cowan References: <6FC6B441-B74D-4B9F-B883-065C05890880@lindenbergsoftware.com> <51BE8DEA.7030307@it.aoyama.ac.jp> <118A7923-5D66-4EF5-8A78-CAE125032010@lindenbergsoftware.com> <20130617115453.GC19150@mercury.ccil.org> In-Reply-To: <20130617115453.GC19150@mercury.ccil.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Norbert Lindenberg , json@ietf.org Subject: Re: [Json] Scope: Wire format or runtime format? X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 18 Jun 2013 10:24:22 -0000 On 2013/06/17 20:54, John Cowan wrote: > Norbert Lindenberg scripsit: > >> Maybe you have a better term for it: What I mean in the ECMAScript >> context is the format that the functions JSON.parse and JSON.stringify >> parse and produce [1]. > > This simply is the description of JSON at the level of characters. Expressed as UTF-16 because that's what ECMAScript uses. Regards, Martin. From paul.hoffman@vpnc.org Tue Jun 18 07:04:32 2013 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 F3D9C21F949F for ; Tue, 18 Jun 2013 07:04:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.504 X-Spam-Level: X-Spam-Status: No, score=-102.504 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kOxtxcsuyvBK for ; Tue, 18 Jun 2013 07:04:31 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 7AF7721F93E0 for ; Tue, 18 Jun 2013 07:04:31 -0700 (PDT) Received: from [10.20.30.90] (50-0-66-165.dsl.dynamic.sonic.net [50.0.66.165]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r5IE4RoL083325 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 18 Jun 2013 07:04:28 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Paul Hoffman In-Reply-To: <5FBB0E3C-E538-48F9-AD32-45AD00151C12@yahoo.com> Date: Tue, 18 Jun 2013 07:04:28 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <44704970-2F3A-43B6-B9B8-5D6052B51361@vpnc.org> References: <51B9EA49.2050604@crockford.com> <5FBB0E3C-E538-48F9-AD32-45AD00151C12@yahoo.com> To: Vinny A X-Mailer: Apple Mail (2.1508) Cc: Douglas Crockford , json@ietf.org Subject: Re: [Json] Two Documents X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 18 Jun 2013 14:04:32 -0000 On Jun 17, 2013, at 8:19 PM, Vinny A wrote: > On Jun 17, 2013, at 7:14 PM, "Matt Miller (mamille2)" = wrote: >=20 >> In order for the WG to fully understand your proposal, we need a more = definitive list of what to expect in each document. >>=20 >> As a starting point, can you describe which sections of the current = RFC4627 would be in "JSON Data Interchange Format" and which would be in = the JSON best practices document? Clearly the latter will have many = additions from the recent discussions, but it is less clear which = portions of the current text goes into which document. >=20 >=20 > Obviously I'm not Douglas, but I'd like to make a proposal in this = department. Not only are you not Douglas (who made the original proposal, and thus = the question was directed at him), you did not even answer Matt's = request. Douglas proposed two documents but did not clearly state what = might be removed from the current WG draft; knowing that will help the = WG decide whether or not to adopt Douglas' proposal. Your list of ideas = for the new document is fine, but is out of scope for the current = charter *unless* you are proposing to remove sections from the current = WG draft. --Paul Hoffman= From paul.hoffman@vpnc.org Tue Jun 18 07:05:31 2013 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 A875F21F9ACC for ; Tue, 18 Jun 2013 07:05:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.505 X-Spam-Level: X-Spam-Status: No, score=-103.505 tagged_above=-999 required=5 tests=[AWL=1.094, BAYES_00=-2.599, GB_I_LETTER=-2, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XDosuaq6V8ob for ; Tue, 18 Jun 2013 07:05:28 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 26F3021F949F for ; Tue, 18 Jun 2013 07:05:25 -0700 (PDT) Received: from [10.20.30.90] (50-0-66-165.dsl.dynamic.sonic.net [50.0.66.165]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r5IE4RoM083325 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 18 Jun 2013 07:05:19 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Paul Hoffman In-Reply-To: <8FDBF4EF-B2DF-458E-834E-5707ED7B27C9@lindenbergsoftware.com> Date: Tue, 18 Jun 2013 07:05:20 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <8FDBF4EF-B2DF-458E-834E-5707ED7B27C9@lindenbergsoftware.com> To: "json@ietf.org" X-Mailer: Apple Mail (2.1508) Subject: Re: [Json] Ambiguous character references X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 18 Jun 2013 14:05:31 -0000 On Jun 17, 2013, at 11:07 PM, Norbert Lindenberg = wrote: > The existing text in section 2.5 of RFC 4627, first through third = paragraph, has the same ambiguous character references as discussed = below. Do they need to be fixed? >=20 > quotation marks -> quotation marks (U+0022) >=20 > quotation mark -> quotation mark (U+0022) >=20 > reverse solidus -> reverse solidus (U+005C) >=20 > control characters (U+0000 through U+001F) -> control characters = U+0000 through U+001F >=20 > lowercase letter u -> Latin small letter u (U+0075) >=20 > hexadecimal digits -> hexadecimal digits U+0030 through U+0039, U+0041 = through U+0046, U+0061 through U+0066 +1 --Paul Hoffman= From jorge@jorgechamorro.com Tue Jun 18 07:10:35 2013 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 C550F21F9F4B for ; Tue, 18 Jun 2013 07:10:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.303 X-Spam-Level: X-Spam-Status: No, score=-0.303 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_45=0.6, MIME_8BIT_HEADER=0.3, WEIRD_QUOTING=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id abMth2czlxbD for ; Tue, 18 Jun 2013 07:10:35 -0700 (PDT) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) by ietfa.amsl.com (Postfix) with ESMTP id BDC6821E8054 for ; Tue, 18 Jun 2013 07:10:32 -0700 (PDT) Received: by mail-wi0-f178.google.com with SMTP id k10so3274352wiv.5 for ; Tue, 18 Jun 2013 07:10:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=ZMs4MOAXsHN1fVehwhk7+lGnVhdN9gGi86uh8bgh214=; b=ZJ3asS8niTjQ1qds/BOqakuTV1kIB37y/wzpRPhRSK1BfDV8c55OFVcb414cTnvgz+ Lr4/g+5cFmCWPC6bZXH+UBqgehNnmb6I0yzcBc958m0TTQ6/X4P80OxfOFaII6PlJMLt S/btgYav9db6voUvXGdn0IR0AevE+VsMK4Ew65b+enzmanm/mqAewiq99Dt5DdllRh5s +AqiUmEzHkgCw0PaqgFEGoDUMJKJTnvCNJwzXY/wHATEOH9wZAlAG2NmJkd02wol5Gs7 9a/XacckEdxyKUS6mB2sJgdvVtOEf37QCMoM+O87zPwBEHHhpZknvKU4KJ/tfB7/4NRR 9nHQ== X-Received: by 10.180.182.229 with SMTP id eh5mr7782340wic.63.1371564631732; Tue, 18 Jun 2013 07:10:31 -0700 (PDT) Received: from [192.168.10.50] (31.Red-83-54-170.dynamicIP.rima-tde.net. [83.54.170.31]) by mx.google.com with ESMTPSA id r9sm2375597wik.1.2013.06.18.07.10.30 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 18 Jun 2013 07:10:31 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=utf-8 From: Jorge In-Reply-To: <51C0353C.3010100@it.aoyama.ac.jp> Date: Tue, 18 Jun 2013 16:10:28 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <6FC6B441-B74D-4B9F-B883-065C05890880@lindenbergsoftware.com> <51BE8DEA.7030307@it.aoyama.ac.jp> <118A7923-5D66-4EF5-8A78-CAE125032010@lindenbergsoftware.com> <20130617115453.GC19150@mercury.ccil.org> <51C0353C.3010100@it.aoyama.ac.jp> To: =?iso-8859-1?Q?Martin_J=2E_D=FCrst?= X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQlIlJsGVFP731odqXC1iRcf84VvWtJ3q45X7ID8uP3qxdgzp0+jCBhwXFzD1lFDGjy3yit9 Cc: Norbert Lindenberg , John Cowan , json@ietf.org Subject: Re: [Json] Scope: Wire format or runtime format? X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 18 Jun 2013 14:10:36 -0000 On 18/06/2013, at 12:23, Martin J. D=C3=BCrst wrote: > On 2013/06/17 20:54, John Cowan wrote: >> Norbert Lindenberg scripsit: >>=20 >>> Maybe you have a better term for it: What I mean in the ECMAScript >>> context is the format that the functions JSON.parse and = JSON.stringify >>> parse and produce [1]. >>=20 >> This simply is the description of JSON at the level of characters. >=20 > Expressed as UTF-16 because that's what ECMAScript uses. Note what JSON.stringify() produces is a subset of JSON, a subset of = what JSON.stringify() accepts: ```javascript a=3D '"\\'+'u2603"' ""\u2603"" b=3D '"\u2603"' ""=E2=98=83"" JSON.parse(a) =3D=3D=3D JSON.parse(b) true Because JSON.stringify("=E2=98=83") won't ever give you an ""\u2603"", = even though it's as valid JSON as ""=E2=98=83"", and .parse()s to the = same value. --=20 ( Jorge )();= From jhildebr@cisco.com Tue Jun 18 11:27:33 2013 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 AF5D321F9C87 for ; Tue, 18 Jun 2013 11:27:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.442 X-Spam-Level: X-Spam-Status: No, score=-10.442 tagged_above=-999 required=5 tests=[AWL=-0.443, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oxb2ukRQoapT for ; Tue, 18 Jun 2013 11:27:28 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id DEB3E21F9C3E for ; Tue, 18 Jun 2013 11:27:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2815; q=dns/txt; s=iport; t=1371580044; x=1372789644; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=2pPoVzeXod2x57s+bwhERX4hQZRcto1RzCNT9naAWqk=; b=GpVHWjwX8CzKeqWbIv9rJK24yA2jRe3v68Wvo8pMXBNbtY1oYJBpbTIX NNz8Dz4Cqma4ziLsY1gQYidgM6Gokjc87OTJ1jZ8arDIxLuDt4zdiDOSL lfayc+r8VBjTwfL85J3oLSTEVOXcPLjhHhaPyf9rfk3orn3M7Eri1J7r6 g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmYGAJ2lwFGtJXHA/2dsb2JhbABZgwkxSb8PgQIWbQeCJQEEOlEBKhRCJwQbAYgFmj+gRI8KgzhhA5Nvj3SFIYMPgig X-IronPort-AV: E=Sophos;i="4.87,890,1363132800"; d="scan'208";a="221410292" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-9.cisco.com with ESMTP; 18 Jun 2013 18:27:23 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r5IIRNAR015700 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 18 Jun 2013 18:27:23 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.56]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.02.0318.004; Tue, 18 Jun 2013 13:27:22 -0500 From: "Joe Hildebrand (jhildebr)" To: "json@ietf.org" Thread-Topic: Encoding Schemes Thread-Index: AQHObFF5M05aOqj6pkC704hlIeI8tg== Date: Tue, 18 Jun 2013 18:27:22 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [64.101.72.72] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [Json] Encoding Schemes X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 18 Jun 2013 18:27:33 -0000 Background: the word "encoding" is somewhat imprecise. From the Unicode Glossary (http://www.unicode.org/glossary/): """ Character Encoding Scheme. A character encoding form plus byte serialization. There are seven character encoding schemes in Unicode: UTF-8, UTF-16, UTF-16BE, UTF-16LE, UTF-32, UTF-32BE, and UTF-32LE. Unicode Encoding Form. A character encoding form that assigns each Unicode scalar value to a unique code unit sequence. The Unicode Standard defines three Unicode encoding forms: UTF-8, UTF-16, and UTF-32. Unicode Encoding Scheme. A specified byte serialization for a Unicode encoding form, including the specification of the handling of a byte order mark (BOM), if allowed. """ In UTF-16 and UTF-32 (note: *not* BE or LE), you SHOULD include a Byte Order Mark, but if it's not there, you assume BE. From Unicode 6.2, section 3.10, D98: """ The BOM is not considered part of the content of the text. The UTF-16 encoding scheme may or may not begin with a BOM. However, when there is no BOM, and in the absence of a higher-level protocol, the byte order of the UTF-16 encoding scheme is big-endian. """ and from D101: """ The BOM is not considered part of the content of the text. The UTF-32 encoding scheme may or may not begin with a BOM. However, when there is no BOM, and in the absence of a higher-level protocol, the byte order of the UTF-32 encoding scheme is big-endian. """ One could argue that the current table in section 3 of 4627 constitutes such a higher-level protocol, but since we haven't specified either UTF-16 or UTF-32 in the table, nor have we specified what to do with BOMs, I don't think that 4627 currently acts as that higher-level protocol. As such, I believe that the phrase from section 3 of 4627 that says: "JSON text SHALL be encoded in Unicode. The default encoding is UTF-8." needs a little help. We probably want to include only the 5 encoding schemes currently mentioned in the draft, not all 7. Some suggest text: "When serialized to an octet stream, JSON text SHALL be encoded in one of the following Unicode encoding schemes: UTF-8, UTF-16BE, UTF-16LE, UTF-32BE, and UTF-32LE. The default and RECOMMENDED encoding is UTF-8. Byte Order Marks MUST NOT be used to signal byte order in any encoding." and then on with the changed version of the table that we've discussed. This text intentionally allows U+FEFF in strings (where they've been allowed to date as zero width no-break space), but NOT as the first codepoint in the stream, where, since U+FEFF isn't in the ws production, they can't be used. As well, if Unicode adds another encoding scheme one day, I don't want 4627bis to automatically require support for it unintentionally. --=20 Joe Hildebrand From cowan@ccil.org Tue Jun 18 11:39:31 2013 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 8AA1911E80F8 for ; Tue, 18 Jun 2013 11:39:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.451 X-Spam-Level: X-Spam-Status: No, score=-3.451 tagged_above=-999 required=5 tests=[AWL=0.148, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8V5TEnnxYLPN for ; Tue, 18 Jun 2013 11:39:27 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id 3488221E8083 for ; Tue, 18 Jun 2013 11:39:27 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1Up0oQ-0008Fb-9P; Tue, 18 Jun 2013 14:39:26 -0400 Date: Tue, 18 Jun 2013 14:39:26 -0400 From: John Cowan To: "Joe Hildebrand (jhildebr)" Message-ID: <20130618183926.GG12085@mercury.ccil.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Cc: "json@ietf.org" Subject: Re: [Json] Encoding Schemes X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 18 Jun 2013 18:39:31 -0000 Joe Hildebrand (jhildebr) scripsit: > "When serialized to an octet stream, JSON text SHALL be encoded in one of > the following Unicode encoding schemes: UTF-8, UTF-16BE, UTF-16LE, > UTF-32BE, and UTF-32LE. The default and RECOMMENDED encoding is UTF-8. Oh no, that SHALL will not fly. Any encoding (which means "encoding scheme" in a media-type context) can be used to represent JSON. Including an EBCDIC variant. -- John Cowan cowan@ccil.org http://ccil.org/~cowan Half the lies they tell about me are true. --Tallulah Bankhead, American actress From jhildebr@cisco.com Tue Jun 18 11:54:43 2013 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 CA4FE11E80FA for ; Tue, 18 Jun 2013 11:54:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.686 X-Spam-Level: X-Spam-Status: No, score=-10.686 tagged_above=-999 required=5 tests=[AWL=-0.087, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p-7buehh+lZs for ; Tue, 18 Jun 2013 11:54:38 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 4C56D11E80F9 for ; Tue, 18 Jun 2013 11:54:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1346; q=dns/txt; s=iport; t=1371581677; x=1372791277; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=mxbp9kJoVWL6N6VOqdfxnydUcu7czfXQA9P8XEjQSUY=; b=mcSSC259rTqkuHqQjvpW3qgWvdRq/7VagNyllr5R0p4j0l0cKmXmb/5p geuBD3yxS7dCiO3Tfn3PtB2hn4l+xp0hMfBx5c69shBovJbQzEsCrfQOD uSyNd7JfTG/tF5sDkI/vKUaIPA0SlE3/JvYXSlHtMvWP/Y7zolkwOwN4h Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag0FALSrwFGtJXHA/2dsb2JhbABZgwl6vw+BAxZ0giUBBDo/EgEIIhRCJQIEDgUIiAa7A48KMQeDAGEDqQSDD4Io X-IronPort-AV: E=Sophos;i="4.87,890,1363132800"; d="scan'208";a="224422072" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-3.cisco.com with ESMTP; 18 Jun 2013 18:54:37 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r5IIsane020122 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 18 Jun 2013 18:54:36 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.56]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.02.0318.004; Tue, 18 Jun 2013 13:54:36 -0500 From: "Joe Hildebrand (jhildebr)" To: John Cowan Thread-Topic: [Json] Encoding Schemes Thread-Index: AQHObFF5M05aOqj6pkC704hlIeI8tpk8IX8A//+fpgA= Date: Tue, 18 Jun 2013 18:54:35 +0000 Message-ID: In-Reply-To: <20130618183926.GG12085@mercury.ccil.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [64.101.72.72] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "json@ietf.org" Subject: Re: [Json] Encoding Schemes X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 18 Jun 2013 18:54:43 -0000 On 6/18/13 12:39 PM, "John Cowan" wrote: >Joe Hildebrand (jhildebr) scripsit: > >> "When serialized to an octet stream, JSON text SHALL be encoded in one >>of >> the following Unicode encoding schemes: UTF-8, UTF-16BE, UTF-16LE, >> UTF-32BE, and UTF-32LE. The default and RECOMMENDED encoding is UTF-8. > >Oh no, that SHALL will not fly. Any encoding (which means "encoding >scheme" in a media-type context) can be used to represent JSON. >Including an EBCDIC variant. I assume you're talking about UTF-EBCDIC from tr16? I don't see how you could auto-determine the encoding for that. How about this: """ Without an external mechanism that specifies encoding, when serialized to an octet stream, JSON text SHALL be encoded in one of the following Unicode encoding schemes: UTF-8, UTF-16BE, UTF-16LE, UTF-32BE, and UTF-32LE. The default and RECOMMENDED encoding is UTF-8. Note: the MIME type registered in section 6 does not specify a mechanism to specify the encoding scheme, so when used in a MIME context, one of the above encoding schemes MUST be used. Other Unicode encoding schemes MAY be used, but such octet streams cannot have their encoding scheme automatically detected and SHOULD NOT be assumed to interoperate with existing software. """ --=20 Joe Hildebrand From tsaloranta@gmail.com Tue Jun 18 12:11:51 2013 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 0459221E8092 for ; Tue, 18 Jun 2013 12:11:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.48 X-Spam-Level: X-Spam-Status: No, score=-2.48 tagged_above=-999 required=5 tests=[AWL=0.119, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mx7eougLj0P4 for ; Tue, 18 Jun 2013 12:11:50 -0700 (PDT) Received: from mail-wg0-x231.google.com (mail-wg0-x231.google.com [IPv6:2a00:1450:400c:c00::231]) by ietfa.amsl.com (Postfix) with ESMTP id EF74B11E80EE for ; Tue, 18 Jun 2013 12:11:49 -0700 (PDT) Received: by mail-wg0-f49.google.com with SMTP id a12so3736589wgh.28 for ; Tue, 18 Jun 2013 12:11:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=2TsrfonbPcBZkR82YLkWPX058VTyFFF+l+mbPD8y25w=; b=g+6fYamr7NYUuRQsscgewCxgcwOB1GxwVNG/anVDhWZzTNvKigyH/2blxYR9EU0Gn+ 1NMDntf/yag053IXnQh5xm/CTP63UZ/klsdg1kJQvgb07PKPocsxMiO0SeJhwbMOAZFy bIMwoMInmAa9lmpQbKGP+5BoRVoQrNTjynbEZbNQjAlu8/1o2QLxgiWz0JgZxKToFcU8 Bbmhp8aWqReFrEMFrpmb53aOcpPQ4yWkhsTrk2f2+mqea89uvRccleK90PrWsdwbrc4Z leXucC9Nu1HN+DZ2MXlfdKjvXZVkMLymwzsdUAf0+ajDd1Hi35b/XXTZCNRnIdIwIPLR 9faQ== MIME-Version: 1.0 X-Received: by 10.194.90.244 with SMTP id bz20mr12102227wjb.69.1371582709019; Tue, 18 Jun 2013 12:11:49 -0700 (PDT) Received: by 10.227.72.74 with HTTP; Tue, 18 Jun 2013 12:11:48 -0700 (PDT) In-Reply-To: References: <20130618183926.GG12085@mercury.ccil.org> Date: Tue, 18 Jun 2013 20:11:48 +0100 Message-ID: From: Tatu Saloranta To: "Joe Hildebrand (jhildebr)" Content-Type: multipart/alternative; boundary=047d7bfd090a26bd8304df727cdd Cc: John Cowan , "json@ietf.org" Subject: Re: [Json] Encoding Schemes X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 18 Jun 2013 19:11:51 -0000 --047d7bfd090a26bd8304df727cdd Content-Type: text/plain; charset=ISO-8859-1 On Tue, Jun 18, 2013 at 7:54 PM, Joe Hildebrand (jhildebr) < jhildebr@cisco.com> wrote: > On 6/18/13 12:39 PM, "John Cowan" wrote: > > >Joe Hildebrand (jhildebr) scripsit: > > > >> "When serialized to an octet stream, JSON text SHALL be encoded in one > >>of > >> the following Unicode encoding schemes: UTF-8, UTF-16BE, UTF-16LE, > >> UTF-32BE, and UTF-32LE. The default and RECOMMENDED encoding is UTF-8. > > > >Oh no, that SHALL will not fly. Any encoding (which means "encoding > >scheme" in a media-type context) can be used to represent JSON. > >Including an EBCDIC variant. > > I assume you're talking about UTF-EBCDIC from tr16? I don't see how you > could auto-determine the encoding for that. How about this: > > """ > Without an external mechanism that specifies encoding, when serialized to > an octet stream, JSON text SHALL be encoded in one of the following > Unicode encoding schemes: UTF-8, UTF-16BE, UTF-16LE, UTF-32BE, and > UTF-32LE. The default and RECOMMENDED encoding is UTF-8. > > Note: the MIME type registered in section 6 does not specify a mechanism > to specify the encoding scheme, so when used in a MIME context, one of the > above encoding schemes MUST be used. > > > Other Unicode encoding schemes MAY be used, but such octet streams cannot > have their encoding scheme automatically detected and SHOULD NOT be > assumed to interoperate with existing software. > """ > > I like this wording, because it is somewhat compatible with the current state of affairs. Unlike XML, where most encodings can be detected from content (including even EBCDIC, given xml declaration), JSON decoders have to rely on small subset of encodings for auto-detection, and external encoding information for others. -+ Tatu +- --047d7bfd090a26bd8304df727cdd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, Jun 18, 2013 at 7:54 PM, Joe Hildebrand (jhildebr)= <jhildebr@cisco.com> wrote:
=
On 6/18/13 12:39 PM, "= ;John Cowan" <cowan@mercu= ry.ccil.org> wrote:

>Joe Hildebrand (jhildebr) scripsit:
>
>> "When serialized to an octet stream, JSON text SHALL be encod= ed in one
>>of
>> the following Unicode encoding schemes: UTF-8, =A0UTF-16BE, UTF-16= LE,
>> UTF-32BE, and UTF-32LE. =A0The default and RECOMMENDED encoding is= UTF-8.
>
>Oh no, that SHALL will not fly. =A0Any encoding (which means "enco= ding
>scheme" in a media-type context) can be used to represent JSON. >Including an EBCDIC variant.

I assume you're talking about UTF-EBCDIC from tr16? =A0I don'= t see how you
could auto-determine the encoding for that. =A0How about this:

"""
Without an external mechanism that specifies encoding, when serialized to
an octet stream, JSON text SHALL be encoded in one of the= following
Unicode encoding schemes: UTF-8, =A0UTF-16BE, UTF-16LE, UTF-32BE, and
UTF-32LE. =A0The default and RECOMMENDED encoding is UTF-8.

Note: the MIME type registered in section 6 does not specify a mechan= ism
to specify the encoding scheme, so when used in a MIME context, one of the<= br> above encoding schemes MUST be used.


Other Unicode encoding schemes MAY be used, but such octet streams cannot have their encoding scheme automatically detected and SHOULD NOT be
assumed to interoperate with existing software.
"""

<= br>
I like this wording, because it is somewhat compatible with t= he current state of affairs.
Unlike XML, where most encodings= can be detected from content (including even EBCDIC, given xml declaration= ), JSON decoders have to rely on small subset of encodings for auto-detecti= on, and external encoding information for others.

-+ Tatu +-
=A0
--047d7bfd090a26bd8304df727cdd-- From ietf@lindenbergsoftware.com Tue Jun 18 12:19:03 2013 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 7AE7021E80A8 for ; Tue, 18 Jun 2013 12:19:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.931 X-Spam-Level: X-Spam-Status: No, score=-3.931 tagged_above=-999 required=5 tests=[AWL=-0.332, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V4Jk5XE8JNXR for ; Tue, 18 Jun 2013 12:18:57 -0700 (PDT) Received: from mirach.lunarpages.com (mirach.lunarpages.com [216.97.235.70]) by ietfa.amsl.com (Postfix) with ESMTP id 8445421E8092 for ; Tue, 18 Jun 2013 12:18:57 -0700 (PDT) Received: from 50-0-136-241.dsl.dynamic.sonic.net ([50.0.136.241]:63876 helo=[192.168.0.5]) by mirach.lunarpages.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1Up1Qd-0031jT-EL; Tue, 18 Jun 2013 12:18:55 -0700 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Norbert Lindenberg In-Reply-To: <20130618183926.GG12085@mercury.ccil.org> Date: Tue, 18 Jun 2013 12:18:51 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130618183926.GG12085@mercury.ccil.org> To: John Cowan X-Mailer: Apple Mail (2.1283) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - mirach.lunarpages.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - lindenbergsoftware.com X-Get-Message-Sender-Via: mirach.lunarpages.com: authenticated_id: ietf@lindenbergsoftware.com Cc: Norbert Lindenberg , "Joe Hildebrand \(jhildebr\)" , "json@ietf.org" Subject: Re: [Json] Encoding Schemes X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 18 Jun 2013 19:19:03 -0000 On Jun 18, 2013, at 11:39 , John Cowan wrote: > Joe Hildebrand (jhildebr) scripsit: >=20 >> "When serialized to an octet stream, JSON text SHALL be encoded in = one of >> the following Unicode encoding schemes: UTF-8, UTF-16BE, UTF-16LE, >> UTF-32BE, and UTF-32LE. The default and RECOMMENDED encoding is = UTF-8. >=20 > Oh no, that SHALL will not fly. Any encoding (which means "encoding > scheme" in a media-type context) can be used to represent JSON. > Including an EBCDIC variant. Do you mean JSON embedded in some other document format, or = application/json? How do you align this statement with the current "JSON = text SHALL be encoded in Unicode" in section 3 and with the encoding = considerations and the lack of a charset parameter in section 6? Norbert From cabo@tzi.org Tue Jun 18 12:21:22 2013 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 D497521F9954 for ; Tue, 18 Jun 2013 12:21:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.196 X-Spam-Level: X-Spam-Status: No, score=-106.196 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ys0OzNicy45 for ; Tue, 18 Jun 2013 12:21:05 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id EFF0921F8F7B for ; Tue, 18 Jun 2013 12:21:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r5IJKvLt013668; Tue, 18 Jun 2013 21:20:57 +0200 (CEST) Received: from [192.168.217.105] (p54893361.dip0.t-ipconnect.de [84.137.51.97]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id C9FD63501; Tue, 18 Jun 2013 21:20:56 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <20130618183926.GG12085@mercury.ccil.org> Date: Tue, 18 Jun 2013 21:20:56 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130618183926.GG12085@mercury.ccil.org> To: John Cowan X-Mailer: Apple Mail (2.1508) Cc: "Joe Hildebrand \(jhildebr\)" , "json@ietf.org" Subject: Re: [Json] Encoding Schemes X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 18 Jun 2013 19:21:22 -0000 > Any encoding (which means "encoding > scheme" in a media-type context) can be used to represent JSON. > Including an EBCDIC variant. We are confusing JSON with JSON again. JSON the interchange format, which specifies a sequence of characters, = certainly can be encoded in any character encoding scheme that is able = to represent the characters that are needed in a specific case. JSON the media type (application/json) is specifically limited to UTF-8 = (and theoretically the two or possibly four other character encoding = schemes listed in RFC 4627; the RFC isn't quite consistent here). There is no way to use another encoding in that media type as there is = no charset parameter in the media type. (This is intentional and certainly is not a candidate for change.) Gr=FC=DFe, Carsten From paul.hoffman@vpnc.org Tue Jun 18 12:34:14 2013 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 6128721E8088 for ; Tue, 18 Jun 2013 12:34:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yi4d6J0+1JjT for ; Tue, 18 Jun 2013 12:34:13 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id DD26221E805D for ; Tue, 18 Jun 2013 12:34:13 -0700 (PDT) Received: from [165.227.249.247] (sn80.proper.com [75.101.18.80]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r5IJYCv7094981 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 18 Jun 2013 12:34:13 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Paul Hoffman In-Reply-To: Date: Tue, 18 Jun 2013 12:34:12 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <4626FCFD-90CE-4CE7-A123-ED3E12E7FF0A@vpnc.org> References: <20130618183926.GG12085@mercury.ccil.org> To: Carsten Bormann X-Mailer: Apple Mail (2.1508) Cc: json@ietf.org Subject: Re: [Json] Encoding Schemes X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 18 Jun 2013 19:34:14 -0000 On Jun 18, 2013, at 12:20 PM, Carsten Bormann wrote: > JSON the interchange format, which specifies a sequence of characters, = certainly can be encoded in any character encoding scheme that is able = to represent the characters that are needed in a specific case. ...as long as the receiver can determine the encoding scheme. Otherwise, = there is no chance for meaningful interop. > JSON the media type (application/json) is specifically limited to = UTF-8 (and theoretically the two or possibly four other character = encoding schemes listed in RFC 4627; the RFC isn't quite consistent = here). Can you point to the text in the draft that supports that statement? I = see the opposite: Encoding considerations: 8bit if UTF-8; binary if UTF-16 or UTF-32 JSON may be represented using UTF-8, UTF-16, or UTF-32. When JSON is written in UTF-8, JSON is 8bit compatible. When JSON is written in UTF-16 or UTF-32, the binary content-transfer-encoding must be used. > There is no way to use another encoding in that media type as there is = no charset parameter in the media type. > (This is intentional and certainly is not a candidate for change.) It would certainly be my preference to not add a charset parameter in = the -bis document; that would seem like a major change. --Paul Hoffman= From cowan@ccil.org Tue Jun 18 12:56:05 2013 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 E23B621F998F for ; Tue, 18 Jun 2013 12:56:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.454 X-Spam-Level: X-Spam-Status: No, score=-3.454 tagged_above=-999 required=5 tests=[AWL=0.145, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pONr+ukxUTso for ; Tue, 18 Jun 2013 12:56:01 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id 87C7621F9982 for ; Tue, 18 Jun 2013 12:56:01 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1Up20W-0007XW-5T; Tue, 18 Jun 2013 15:56:00 -0400 Date: Tue, 18 Jun 2013 15:56:00 -0400 From: John Cowan To: Norbert Lindenberg Message-ID: <20130618195600.GH12085@mercury.ccil.org> References: <20130618183926.GG12085@mercury.ccil.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Cc: "Joe Hildebrand \(jhildebr\)" , "json@ietf.org" Subject: Re: [Json] Encoding Schemes X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 18 Jun 2013 19:56:06 -0000 Norbert Lindenberg scripsit: > Do you mean JSON embedded in some other document format, or > application/json? Either. > How do you align this statement with the current "JSON > text SHALL be encoded in Unicode" in section 3 Like Alice, I don't believe there's an atom of meaning in it. "Unicode" is not the name of an encoding. > and with the encoding > considerations and the lack of a charset parameter in section 6? If there's no charset parameter, there isn't one. Otherwise, section 6 only explains what Content-Transfer-Encoding to use in various cases, without saying that no other cases are supported. -- John Cowan http://www.ccil.org/~cowan Pour moi, les villes du Silmarillion ont plus de réalité que Babylone. --Christopher Tolkien, as interviewed by Le Monde From cabo@tzi.org Tue Jun 18 12:57:45 2013 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 632D621E805E for ; Tue, 18 Jun 2013 12:57:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.198 X-Spam-Level: X-Spam-Status: No, score=-106.198 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pJBFkCfCxxyX for ; Tue, 18 Jun 2013 12:57:39 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 4793621F843F for ; Tue, 18 Jun 2013 12:57:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r5IJvT3e016502; Tue, 18 Jun 2013 21:57:29 +0200 (CEST) Received: from [192.168.217.105] (p54893361.dip0.t-ipconnect.de [84.137.51.97]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 4ED133521; Tue, 18 Jun 2013 21:57:29 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <4626FCFD-90CE-4CE7-A123-ED3E12E7FF0A@vpnc.org> Date: Tue, 18 Jun 2013 21:57:28 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <4EC0C40B-CFEE-438C-A30F-1F43C017E24E@tzi.org> References: <20130618183926.GG12085@mercury.ccil.org> <4626FCFD-90CE-4CE7-A123-ED3E12E7FF0A@vpnc.org> To: Paul Hoffman X-Mailer: Apple Mail (2.1508) Cc: json@ietf.org Subject: Re: [Json] Encoding Schemes X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 18 Jun 2013 19:57:45 -0000 On Jun 18, 2013, at 21:34, Paul Hoffman wrote: >> JSON the media type (application/json) is specifically limited to = UTF-8 (and theoretically the two or possibly four other character = encoding schemes listed in RFC 4627; the RFC isn't quite consistent = here). >=20 > Can you point to the text in the draft that supports that statement? I = see the opposite: > Encoding considerations: 8bit if UTF-8; binary if UTF-16 or UTF-32 >=20 > JSON may be represented using UTF-8, UTF-16, or UTF-32. When JSON > is written in UTF-8, JSON is 8bit compatible. When JSON is > written in UTF-16 or UTF-32, the binary content-transfer-encoding > must be used. You listed two of the three places, the third is in section 3, which = doesn't really list UTF-16 but UTF-16 "BE or LE" (same for UTF-32). = Note that these are three different character encoding schemes (CESs), = so it is not clear which ones are actually meant. Since the first two characters of a JSON text will always be ASCII characters [RFC0020], it is possible to determine whether an octet stream is UTF-8, UTF-16 (BE or LE), or UTF-32 (BE or LE) by looking at the pattern of nulls in the first four octets. 00 00 00 xx UTF-32BE 00 xx 00 xx UTF-16BE xx 00 00 00 UTF-32LE xx 00 xx 00 UTF-16LE xx xx xx xx UTF-8 [Obligatory Unicode bashing: Giving one of the three encoding schemes = (CESs) for the encoding form (CEF) UTF-16 the same name, i.e., "UTF-16", = must have been decided by a very cruel person.] (Strictly speaking, the other mentions of UTF-16/-32 might be the = encoding form, not the scheme, but the RFC simply isn't completely = specified here. I think the only reasonable way to read this has the = same result as what Joe is proposing, but some text interpretation is = required. Clearly, the text in section 3 does not work with the = BOM-based CESs. But you might also read the text in 6 as asking for = UTF-16 CES and the text in 3 then excluding BOMs so the UTF-16 CES is = implicitly big-endian. So much effort for something so theoretical.) Gr=FC=DFe, Carsten From cowan@ccil.org Tue Jun 18 13:05:48 2013 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 6CE0521F9733 for ; Tue, 18 Jun 2013 13:05:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.457 X-Spam-Level: X-Spam-Status: No, score=-3.457 tagged_above=-999 required=5 tests=[AWL=0.142, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KDuqR5+yZkgJ for ; Tue, 18 Jun 2013 13:05:44 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id 124FC21F96F5 for ; Tue, 18 Jun 2013 13:05:43 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1Up29t-0000me-4N; Tue, 18 Jun 2013 16:05:41 -0400 Date: Tue, 18 Jun 2013 16:05:41 -0400 From: John Cowan To: Carsten Bormann Message-ID: <20130618200541.GK12085@mercury.ccil.org> References: <20130618183926.GG12085@mercury.ccil.org> <4626FCFD-90CE-4CE7-A123-ED3E12E7FF0A@vpnc.org> <4EC0C40B-CFEE-438C-A30F-1F43C017E24E@tzi.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4EC0C40B-CFEE-438C-A30F-1F43C017E24E@tzi.org> User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Cc: Paul Hoffman , json@ietf.org Subject: Re: [Json] Encoding Schemes X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 18 Jun 2013 20:05:48 -0000 Carsten Bormann scripsit: > Clearly, the text in section 3 does not work with the > BOM-based CESs. But you might also read the text in 6 as asking for > UTF-16 CES and the text in 3 then excluding BOMs so the UTF-16 CES is > implicitly big-endian. So much effort for something so theoretical.) Unfortunately, it isn't even clear that it means that. It could simply mean "UTF-16, either big-endian or little-endian". I am always astonished when people hold up RFC 4627 as some kind of masterpiece of standards writing. -- John Cowan cowan@ccil.org http://ccil.org/~cowan Original line from The Warrior's Apprentice by Lois McMaster Bujold: "Only on Barrayar would pulling a loaded needler start a stampede toward one." English-to-Russian-to-English mangling thereof: "Only on Barrayar you risk to lose support instead of finding it when you threat with the charged weapon." From nico@cryptonector.com Tue Jun 18 13:32:41 2013 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 9453121E8094 for ; Tue, 18 Jun 2013 13:32:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.965 X-Spam-Level: X-Spam-Status: No, score=-1.965 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kO7ez+o5eJeQ for ; Tue, 18 Jun 2013 13:32:36 -0700 (PDT) Received: from homiemail-a26.g.dreamhost.com (mailbigip.dreamhost.com [208.97.132.5]) by ietfa.amsl.com (Postfix) with ESMTP id 2900011E80F5 for ; Tue, 18 Jun 2013 13:32:36 -0700 (PDT) Received: from homiemail-a26.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a26.g.dreamhost.com (Postfix) with ESMTP id A5599B806D for ; Tue, 18 Jun 2013 13:32:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=VHn7f/ETvV5U8yE4ay9/ xGNLsSk=; b=qtsxghBs8HP1st1WdWnrCyr2C1855yIGkSljMuIwhr+a4NttksH/ poqt3A4pS3YsfdYD0mMzNVmpwS9sLA9JFfL+SLlcZCshMM7Oz0GwGhB3t19q7IwP gUzkfp+g1+AqPqlJ0D9hEzaA026mENQ5Bl2M3VgCnR2VqoLCpCSKUjI= Received: from mail-wg0-f53.google.com (mail-wg0-f53.google.com [74.125.82.53]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a26.g.dreamhost.com (Postfix) with ESMTPSA id 37D7DB805C for ; Tue, 18 Jun 2013 13:32:32 -0700 (PDT) Received: by mail-wg0-f53.google.com with SMTP id y10so3852536wgg.8 for ; Tue, 18 Jun 2013 13:32:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=vnvysx8IB94KWy6ldFsqk2T4cCxWxJk7W3AY/HmEhT8=; b=Q1iMsNedeuAUGMKxK0UOfM/eqATIFSrkrhifsjxUeVlOOEfOSsgC5i48Q5OPmrjfBl RGfANfeZAtUWyw8UcmoXHLGObXfDz2dOF3j/BJgQFkb+2k6N/IZJ4TX58QqE1EkGdKhN nf52/WVcxB8AVTZPEZqZbN4tMAKD89ua2veHf6/ZLQOlAJ9fAWsxXgdwAmots5GCCqMg /3cBtuvkw4ynJRyqPoM2ROfc9h+m2/sSZc5uIezjADM462f5xxclmyk98JHGEXO8zrMY iVn2eIZY4CtxzfTiRLoK4CVd67BJqcEPSyyutugAuTMt0TkNovqbPWGNEK2CBW2nwqzp e1Og== MIME-Version: 1.0 X-Received: by 10.180.109.195 with SMTP id hu3mr8696021wib.13.1371587551679; Tue, 18 Jun 2013 13:32:31 -0700 (PDT) Received: by 10.216.29.5 with HTTP; Tue, 18 Jun 2013 13:32:31 -0700 (PDT) In-Reply-To: <20130618200541.GK12085@mercury.ccil.org> References: <20130618183926.GG12085@mercury.ccil.org> <4626FCFD-90CE-4CE7-A123-ED3E12E7FF0A@vpnc.org> <4EC0C40B-CFEE-438C-A30F-1F43C017E24E@tzi.org> <20130618200541.GK12085@mercury.ccil.org> Date: Tue, 18 Jun 2013 15:32:31 -0500 Message-ID: From: Nico Williams To: John Cowan Content-Type: text/plain; charset=UTF-8 Cc: Carsten Bormann , Paul Hoffman , json@ietf.org Subject: Re: [Json] Encoding Schemes X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 18 Jun 2013 20:32:41 -0000 On Tue, Jun 18, 2013 at 3:05 PM, John Cowan wrote: > Carsten Bormann scripsit: > >> Clearly, the text in section 3 does not work with the >> BOM-based CESs. But you might also read the text in 6 as asking for >> UTF-16 CES and the text in 3 then excluding BOMs so the UTF-16 CES is >> implicitly big-endian. So much effort for something so theoretical.) > > Unfortunately, it isn't even clear that it means that. It could simply > mean "UTF-16, either big-endian or little-endian". I read it as "UTF-16, big-endian or little-endian, without BOMs". I read the RFC as specifying that JSON encodings are (not normative) UTF-8, UTF-16 (either endianness, no BOM), or UTF-32 (either endianness). It may well be that JSON is only ever sent as UTF-8... ...But then, following the thread on what a JSON string is, I now understand that JSON strings generally contain Unicode character data but really they may contain any codepoints from the BMP, and, really, any 16-bit values, with some values having to be escaped. Of course, given the whole discussion re: surrogates, JSON uses neither UTF-8 nor CESU-8, but an amalgam of sorts, so, to wrap it up, JSON is intended to be encoded in UTF-8 (and maybe -16 and -32), with all the caveats about surrogates getting smuggled in because bad Unicode character data in JSON strings bleeds into the encoding. Nico -- From jhildebr@cisco.com Tue Jun 18 13:40:43 2013 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 6F6FD21F8E6E for ; Tue, 18 Jun 2013 13:40:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.677 X-Spam-Level: X-Spam-Status: No, score=-10.677 tagged_above=-999 required=5 tests=[AWL=-0.078, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oIAdhhhODTpg for ; Tue, 18 Jun 2013 13:40:37 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 78EDA11E8100 for ; Tue, 18 Jun 2013 13:40:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1463; q=dns/txt; s=iport; t=1371588037; x=1372797637; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=Kw3A9xSkiQEBGxh20EpmXgpV0KCD9vcn5BQZ8G8qwyo=; b=ZHi0tFgppfmfiAjTuX0jtonGQna0F16X/wCL/XFAliGKWRjDIRGqN5NJ gj4kb8Vh1Z2noEaXg/qveF1Y/Y+yUxeinNdBzG0KCZpvXO4cQY66v84FD GYmAL9dOUMhMPzHqKH+Zti0Y0/uRd65a6vhjeOvL19eWsk0IcCxqSe7By 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmUGAHnFwFGtJXG8/2dsb2JhbABagwl6vw+BBBZtB4IlAQQ6UQEqFEInBBuIBppMoDiPCoM4YQOpBIMPgig X-IronPort-AV: E=Sophos;i="4.87,891,1363132800"; d="scan'208";a="224434158" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-7.cisco.com with ESMTP; 18 Jun 2013 20:40:23 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r5IKeNXs025817 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 18 Jun 2013 20:40:23 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.56]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.02.0318.004; Tue, 18 Jun 2013 15:40:23 -0500 From: "Joe Hildebrand (jhildebr)" To: "json@ietf.org" Thread-Topic: Complete section 3 proposal Thread-Index: AQHObGQOe+q+3fshkkqz/+DniugiRQ== Date: Tue, 18 Jun 2013 20:40:22 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [64.101.72.72] Content-Type: text/plain; charset="us-ascii" Content-ID: <74A55F06E9F4E141957074041777DEA1@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [Json] Complete section 3 proposal X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 18 Jun 2013 20:40:43 -0000 Combining the threads """ Without an external mechanism that specifies encoding, when serialized to an octet stream, JSON text SHALL be encoded in one of the following Unicode encoding schemes: UTF-8, UTF-16BE, UTF-16LE, UTF-32BE, or UTF-32LE. The default and RECOMMENDED encoding is UTF-8. Note: the MIME type registered in [Section 6] does not specify such an external mechanism, so when used in a MIME context, one of the above encoding schemes MUST be used. Since the first code point of JSON text will always be an ASCII character [RFC0020], it is possible to determine whether an octet stream is UTF-8, UTF-16BE, UTF-16LE, UTF-32BE, or UTF-32LE by looking at the pattern of nulls in the first four octets of a stream. In the following table "00" corresponds to an octet with value zero, "xx" corresponds to an octet known to be non-zero, and "??" corresponds to an octet that is not checked. 00 00 00 xx UTF-32BE 00 xx ?? xx UTF-16BE xx 00 00 00 UTF-32LE xx 00 xx ?? UTF-16LE xx xx ?? ?? UTF-8 Note: streams less than four octets long are not UTF-32BE or UTF-32LE, and streams less than two octets long are UTF-8. Other Unicode encoding schemes MAY be used, but such octet streams cannot have their encoding scheme automatically detected as required by the MIME type in [Section 6], and SHOULD NOT be assumed to interoperate with existing software. """ --=20 Joe Hildebrand From cabo@tzi.org Tue Jun 18 13:50:10 2013 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 6C03721F9A93 for ; Tue, 18 Jun 2013 13:50:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.199 X-Spam-Level: X-Spam-Status: No, score=-106.199 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nf1pJ9xD1SWR for ; Tue, 18 Jun 2013 13:49:53 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 3252521F9A91 for ; Tue, 18 Jun 2013 13:49:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r5IKnnmS016948; Tue, 18 Jun 2013 22:49:49 +0200 (CEST) Received: from [192.168.217.105] (p54893361.dip0.t-ipconnect.de [84.137.51.97]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 4ADA93562; Tue, 18 Jun 2013 22:49:49 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: Date: Tue, 18 Jun 2013 22:49:48 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <85B201F6-42DC-4EB8-B868-79BFB218DF1F@tzi.org> References: To: "Joe Hildebrand (jhildebr)" X-Mailer: Apple Mail (2.1508) Cc: "json@ietf.org" Subject: Re: [Json] Complete section 3 proposal X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 18 Jun 2013 20:50:11 -0000 Looks great, except that the phrase > in a MIME context may be not quite what is meant here. (This paragraph is specifically about application/json; if I want to go = ahead and register an application/json-in-zos-ebcdic tomorrow, there = should be no problem with me using that once I've been released from the = asylum.) Gr=FC=DFe, Carsten From nico@cryptonector.com Tue Jun 18 13:52:36 2013 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 F34EE21F9ABA for ; Tue, 18 Jun 2013 13:52:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.966 X-Spam-Level: X-Spam-Status: No, score=-1.966 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 71jwwux+1w1X for ; Tue, 18 Jun 2013 13:52:30 -0700 (PDT) Received: from homiemail-a77.g.dreamhost.com (caiajhbdcahe.dreamhost.com [208.97.132.74]) by ietfa.amsl.com (Postfix) with ESMTP id 3E8DE21F962D for ; Tue, 18 Jun 2013 13:52:30 -0700 (PDT) Received: from homiemail-a77.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a77.g.dreamhost.com (Postfix) with ESMTP id 00D3B94075 for ; Tue, 18 Jun 2013 13:52:30 -0700 (PDT) Received: from mail-wg0-f45.google.com (mail-wg0-f45.google.com [74.125.82.45]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a77.g.dreamhost.com (Postfix) with ESMTPSA id 9DA429406E for ; Tue, 18 Jun 2013 13:52:29 -0700 (PDT) Received: by mail-wg0-f45.google.com with SMTP id j13so3921093wgh.12 for ; Tue, 18 Jun 2013 13:52:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=yN5Xx5pGTWvLS/u3gRyGtxJF2p6phWVvgpMPFCsLQkk=; b=hReZAKEmYhhIoyMEBWPvw8f8PRWZ9lOq6GEL9nE17JD1s1jdtrZGvieGd1msTnoAhj BQ83+zBvgH5LjKDIxfKL7+qt3WEoOPkj0TeYlWhVWXcxnFOH7KnWOOLdrjAopMRZ4RBH JTjY3nB8Vl8gEyeuudm92yhHMyXLPeKHpUPV0Vb7h9q+KaR0QgpaE4hifRn3U44yrkbT i14pXu88zT007F6/NSJzFe7jNALdCduDOMhGGFx175almARMTzZzVqN7scAPrOE43b4P cHOe7ZE2dzzSJ1q/tbIW7Gfaa23SHsPvMx52xkqrt2ZUjuscOXscsoyacR+741nhq3zy ORVA== MIME-Version: 1.0 X-Received: by 10.180.99.162 with SMTP id er2mr832430wib.36.1371588748407; Tue, 18 Jun 2013 13:52:28 -0700 (PDT) Received: by 10.216.29.5 with HTTP; Tue, 18 Jun 2013 13:52:28 -0700 (PDT) In-Reply-To: References: Date: Tue, 18 Jun 2013 15:52:28 -0500 Message-ID: From: Nico Williams To: "Joe Hildebrand (jhildebr)" Content-Type: text/plain; charset=UTF-8 Cc: "json@ietf.org" Subject: Re: [Json] Complete section 3 proposal X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 18 Jun 2013 20:52:36 -0000 On Tue, Jun 18, 2013 at 3:40 PM, Joe Hildebrand (jhildebr) wrote: > Combining the threads > > """ > Without an external mechanism that specifies encoding, when serialized to > an octet stream, JSON text SHALL be encoded in one of the following > Unicode encoding schemes: UTF-8, UTF-16BE, UTF-16LE, UTF-32BE, or > UTF-32LE. The default and RECOMMENDED encoding is UTF-8. Note that if a JSON string in JSON data contains unescaped naked surrogates then the encoding of that data will not be valid UTF-8, UTF-16, nor, for that matter, CESU-8. And some implementations probably produce CESU-8-encoded data. I'm not sure whether that's worth stating here or elsewhere, but the fact that there's not-quite-UTF-8 JSON out there means this SHALL is either interop-breaking or the matter must be mentioned nearby. With this caveat, +1. > Note: the MIME type registered in [Section 6] does not specify such an > external mechanism, so when used in a MIME context, one of the above > encoding schemes MUST be used. Agreed. Nico -- From jhildebr@cisco.com Tue Jun 18 15:01:13 2013 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 94F4021F84F2 for ; Tue, 18 Jun 2013 15:01:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.669 X-Spam-Level: X-Spam-Status: No, score=-10.669 tagged_above=-999 required=5 tests=[AWL=-0.070, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EfsTXqBJpLoF for ; Tue, 18 Jun 2013 15:01:07 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 6DE6621F91BF for ; Tue, 18 Jun 2013 15:01:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=493; q=dns/txt; s=iport; t=1371592867; x=1372802467; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=PFbOPgbBzvqIlGTED9c2KEgIv0+rcd7B0jUavUtK8lI=; b=Ay46wTyY3T9X6Yp0Uo0ZNc0q+GWH+4jmhAb/Ay4rUBvjp6TlZhKOXy9i 6UOksCfFUL4CIIFu/TIZ4/WnO5/ydd23b3yT8diFQIuc89Az9Huh8m8bV UQMcitfW3pxCxq9Ocsqug25Skde8/3SOSgZDXeHXa3MX1SE4JDMhw+EiL o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Al4FAErXwFGtJV2Z/2dsb2JhbABagwl6gjq8VoEEFnSCJQEEOj8SAQgOFBRCJQIEDgUIiAa7Do8KMQeDAGEDqQSDD4Io X-IronPort-AV: E=Sophos;i="4.87,891,1363132800"; d="scan'208";a="224482905" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-6.cisco.com with ESMTP; 18 Jun 2013 22:00:58 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r5IM0vCY028635 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 18 Jun 2013 22:00:57 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.56]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.02.0318.004; Tue, 18 Jun 2013 17:00:57 -0500 From: "Joe Hildebrand (jhildebr)" To: Carsten Bormann Thread-Topic: [Json] Complete section 3 proposal Thread-Index: AQHObGQOe+q+3fshkkqz/+DniugiRZk8RccA//+vR4A= Date: Tue, 18 Jun 2013 22:00:56 +0000 Message-ID: In-Reply-To: <85B201F6-42DC-4EB8-B868-79BFB218DF1F@tzi.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [64.101.72.72] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "json@ietf.org" Subject: Re: [Json] Complete section 3 proposal X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 18 Jun 2013 22:01:13 -0000 On 6/18/13 2:49 PM, "Carsten Bormann" wrote: >Looks great, except that the phrase > >> in a MIME context > >may be not quite what is meant here. > >(This paragraph is specifically about application/json; if I want to go >ahead and register an application/json-in-zos-ebcdic tomorrow, there >should be no problem with me using that once I've been released from the >asylum.) Hm. Maybe the bulk of that graf should be moved to section 6? --=20 Joe Hildebrand From jhildebr@cisco.com Tue Jun 18 15:05:36 2013 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 060BB21E80D1 for ; Tue, 18 Jun 2013 15:05:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.663 X-Spam-Level: X-Spam-Status: No, score=-10.663 tagged_above=-999 required=5 tests=[AWL=-0.064, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6AB-gjJ34ere for ; Tue, 18 Jun 2013 15:05:30 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id D92A921E80D6 for ; Tue, 18 Jun 2013 15:05:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1167; q=dns/txt; s=iport; t=1371593125; x=1372802725; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=XvQei1pivcTFcsi+pS8nKsAbQ9H6Q4PfDdmqf8fILkU=; b=A4HsEt8voBSrEJkGGDxj5QhWTEhNNtg+6UITb03MZsmUrEnyT3ENQzHw Bk88UJynZ/djzw8hfaXVLUlihMrtKmJu6RYpoDXAZX+nmcMeff4TwGVwj GHKh0RCx7cM84uMSOsmoZPzZpctH+qfmlAQsIASFtg/LCrdjQ9PjoRnYo 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag0FADrYwFGtJV2c/2dsb2JhbABagwl6vxCBBBZ0giUBBDo/EgEIIhRCJQIEDgUIiAa7D48KMQeDAGEDqQSDD4Io X-IronPort-AV: E=Sophos;i="4.87,891,1363132800"; d="scan'208";a="224556606" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-4.cisco.com with ESMTP; 18 Jun 2013 22:05:24 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r5IM5OhF007172 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 18 Jun 2013 22:05:24 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.56]) by xhc-rcd-x04.cisco.com ([fe80::200:5efe:173.37.183.34%12]) with mapi id 14.02.0318.004; Tue, 18 Jun 2013 17:05:24 -0500 From: "Joe Hildebrand (jhildebr)" To: Nico Williams Thread-Topic: [Json] Complete section 3 proposal Thread-Index: AQHObGQOe+q+3fshkkqz/+DniugiRZk8RoYA//+vxgA= Date: Tue, 18 Jun 2013 22:05:23 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [64.101.72.72] Content-Type: text/plain; charset="us-ascii" Content-ID: <78809B74E899194F80D3EC30186A1A4C@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "json@ietf.org" Subject: Re: [Json] Complete section 3 proposal X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 18 Jun 2013 22:05:36 -0000 On 6/18/13 2:52 PM, "Nico Williams" wrote: >Note that if a JSON string in JSON data contains unescaped naked >surrogates then the encoding of that data will not be valid UTF-8, >UTF-16, nor, for that matter, CESU-8. And some implementations >probably produce CESU-8-encoded data. I think the spirit of 4627 was that it literally be UTF-8, and that all of those other odd encodings are already non-conformant. We could always add a note that says that there has been a history of encodings not being quite adequately specified, so old software may produce octet streams that this document doesn't describe. >I'm not sure whether that's >worth stating here or elsewhere, but the fact that there's >not-quite-UTF-8 JSON out there means this SHALL is either >interop-breaking or the matter must be mentioned nearby. I agree it might be interop-breaking, but I don't think that's necessarily the spec's fault. People will write bad software, particularly when they don't have test vectors easily at hand for them to probe what they originally thought were edge cases. >With this caveat, +1. --=20 Joe Hildebrand From paul.hoffman@vpnc.org Tue Jun 18 15:16:40 2013 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 78FB611E8106 for ; Tue, 18 Jun 2013 15:16:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.524 X-Spam-Level: X-Spam-Status: No, score=-102.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 80NvIbdAglBE for ; Tue, 18 Jun 2013 15:16:40 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 0089521F8F6E for ; Tue, 18 Jun 2013 15:16:39 -0700 (PDT) Received: from [10.20.30.90] (50-0-66-165.dsl.dynamic.sonic.net [50.0.66.165]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r5IMGb0u099548 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 18 Jun 2013 15:16:37 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Paul Hoffman In-Reply-To: Date: Tue, 18 Jun 2013 15:16:36 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Joe Hildebrand (jhildebr) X-Mailer: Apple Mail (2.1508) Cc: "json@ietf.org" Subject: Re: [Json] Complete section 3 proposal X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 18 Jun 2013 22:16:40 -0000 On Jun 18, 2013, at 1:40 PM, Joe Hildebrand (jhildebr) = wrote: > Since the first code point of JSON text will always be an ASCII > character [RFC0020], You were so good with using "encoding schemes", then you fell into this. = :-) While the reference to RFC 20 is cute, it actually doesn't help = here. A more direct statement would be: =3D=3D=3D=3D=3D Because the first code point of a JSON text will always be a character = in the range U+0022 to U+007B, =3D=3D=3D=3D=3D On Jun 18, 2013, at 1:49 PM, Carsten Bormann wrote: > Looks great, except that the phrase >=20 >> in a MIME context >=20 > may be not quite what is meant here. >=20 > (This paragraph is specifically about application/json; if I want to = go ahead and register an application/json-in-zos-ebcdic tomorrow, there = should be no problem with me using that once I've been released from the = asylum.) =3D=3D=3D=3D=3D so when used in the application/json MIME context,=20 =3D=3D=3D=3D=3D From nico@cryptonector.com Tue Jun 18 15:17:42 2013 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 BCD8721E80D3 for ; Tue, 18 Jun 2013 15:17:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.966 X-Spam-Level: X-Spam-Status: No, score=-1.966 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xOxdR5PtI-tF for ; Tue, 18 Jun 2013 15:17:37 -0700 (PDT) Received: from homiemail-a55.g.dreamhost.com (mailbigip.dreamhost.com [208.97.132.5]) by ietfa.amsl.com (Postfix) with ESMTP id 7814111E8106 for ; Tue, 18 Jun 2013 15:17:37 -0700 (PDT) Received: from homiemail-a55.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a55.g.dreamhost.com (Postfix) with ESMTP id 5D3D2400FDB2F for ; Tue, 18 Jun 2013 15:17:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=KkifQEh105uuLiRrWquO pFA7tks=; b=Pboc1VkvOggfaT0ShvGiXbQQUESMKr5fYGjsZfh43+5BOIDA8Ct7 IdXG+9QKgVigUN+E3DtbB0QHfngLCLPQy6WSfpsNh15B4ku4cg1StXgezbEkjv5d 2ejk1Dp8uaKO2dMYVI+FUm4jjbc3nRYofJQcOI6HC5aQi3uWKv1VFXI= Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a55.g.dreamhost.com (Postfix) with ESMTPSA id 0E951400FDB2B for ; Tue, 18 Jun 2013 15:17:31 -0700 (PDT) Received: by mail-wg0-f50.google.com with SMTP id k14so3982377wgh.29 for ; Tue, 18 Jun 2013 15:17:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=aTcIhT57Hkq0YYptxNfSNrtesc+B0c9R7gUY/5OSw8c=; b=NkgwePN6C4kBbH8aBru83dhov9TG44wT+HR9vb3qUj89KsM53JXA2MZbMNDk/Xbp8/ b0y2GR0Ky6RVS3+BBRyUkcDxZv9Go9fT9RrSieQnPIiyNZPXe7SPKCKWfHa+CONLXL8d tqNrCJbxiJhIlu5WnNTxt2wEhh5ii35yGBsCCetUUIedVBeIXG045bIkqrDrJ12MFQsX vU8qhtoYMvl31DtQJA0hPcHH1JaURoW2wz2R04Ei5OW16KCBeJ13wANW5V/8Euxbb/BM NF8rWtwXSADHzd4NL4muERf5huMX5HKlLwRTQotG2meUUM3/dvhAKjSbJ6bE/zIB1zE5 Vuvg== MIME-Version: 1.0 X-Received: by 10.194.8.163 with SMTP id s3mr12230481wja.41.1371593849131; Tue, 18 Jun 2013 15:17:29 -0700 (PDT) Received: by 10.216.29.5 with HTTP; Tue, 18 Jun 2013 15:17:29 -0700 (PDT) In-Reply-To: References: Date: Tue, 18 Jun 2013 17:17:29 -0500 Message-ID: From: Nico Williams To: "Joe Hildebrand (jhildebr)" Content-Type: text/plain; charset=UTF-8 Cc: "json@ietf.org" Subject: Re: [Json] Complete section 3 proposal X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 18 Jun 2013 22:17:42 -0000 On Tue, Jun 18, 2013 at 5:05 PM, Joe Hildebrand (jhildebr) wrote: > On 6/18/13 2:52 PM, "Nico Williams" wrote: > >>Note that if a JSON string in JSON data contains unescaped naked >>surrogates then the encoding of that data will not be valid UTF-8, >>UTF-16, nor, for that matter, CESU-8. And some implementations >>probably produce CESU-8-encoded data. > > I think the spirit of 4627 was that it literally be UTF-8, and that all of > those other odd encodings are already non-conformant. We could always add > a note that says that there has been a history of encodings not being > quite adequately specified, so old software may produce octet streams that > this document doesn't describe. We've been over this. The spirit was that strings were of Unicode characters, but really they're of code points. And so on. And there's no consensus to break existing encoders. And so I don't think we can get consensus for that MUST w/o that note. >>I'm not sure whether that's >>worth stating here or elsewhere, but the fact that there's >>not-quite-UTF-8 JSON out there means this SHALL is either >>interop-breaking or the matter must be mentioned nearby. > > I agree it might be interop-breaking, but I don't think that's necessarily > the spec's fault. People will write bad software, particularly when they > don't have test vectors easily at hand for them to probe what they > originally thought were edge cases. Well, if you can get consensus for it... It's not that people write bad code. It's that bad *data* exists and why should encoders look for it (particularly naked surrogates, why look for them)? I think in practice not much can be done about this but note the problem and encourage encoders not to add to this (i.e., encoders should escape naked surrogates). Nico -- From douglas@crockford.com Tue Jun 18 19:07:01 2013 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 7B88321E8082 for ; Tue, 18 Jun 2013 19:07:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.98 X-Spam-Level: X-Spam-Status: No, score=-1.98 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5TeIkopT0gYv for ; Tue, 18 Jun 2013 19:06:55 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id 7B38621E8063 for ; Tue, 18 Jun 2013 19:06:52 -0700 (PDT) Received: from [10.59.3.87] ([109.174.139.135]) by mrelay.perfora.net (node=mrus3) with ESMTP (Nemesis) id 0MCtad-1UyESq0ipP-008qNO; Tue, 18 Jun 2013 22:06:51 -0400 Message-ID: <51C1121E.8050004@crockford.com> Date: Tue, 18 Jun 2013 19:06:22 -0700 From: Douglas Crockford User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "Matt Miller (mamille2)" References: <51B9EA49.2050604@crockford.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V02:K0:yhKCaxmmf3JkL50pt5Cwn91jLXMR9C0Llq1UuYxjOVv ufwwf3ES8DpVUOjp8YufdbbyWMKcfiPYaQYjPRfvqicOPlM9tf aTuwEga4mYyyH3LaQy4AKrRPNiyWprAW6QOAHw4GrUl2KRMrBY 3OvLBytZ2G+z6kNI6GWnmUCa/ubyblnfFWkIOCc53lOAWRqzuS 30KneRZsOWglQgNnovVETShykcjphFYJU6jH9b2bAs7P3MLnis 3uyZYTC11XNHXxEdz313BP3kvKbhlIfOe0bJOCfUgao9zqG1EN n4VTt0mQapi+pl+MXVjqYlb94elGlBsZ8EdzHJGwBG/MYKeJwa I0A5yV+KjETPH/q4ENTY= Cc: "json@ietf.org" Subject: Re: [Json] Two Documents X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 19 Jun 2013 02:07:01 -0000 On 6/17/2013 5:14 PM, Matt Miller (mamille2) wrote: > Hello Douglas, > > In order for the WG to fully understand your proposal, we need a more definitive list of what to expect in each document. > > As a starting point, can you describe which sections of the current RFC4627 would be in "JSON Data Interchange Format" and which would be in the JSON best practices document? Clearly the latter will have many additions from the recent discussions, but it is less clear which portions of the current text goes into which document. > Please excuse the lateness of this reply. I am traveling. I am proposing that The JSON Data Interchange Format document contain only the material that is universal to all applications of JSON. So, for example, the only dependency on any character encoding is the interpretation of the four hex digits in the \u notation, where Unicode determines the meaning of the numbers. It includes an abstract, an introduction, the detailing of the elements (object, array, string, etc), and security considerations. No parsers or generators, no octets, no MIME types. This provides a standard description of JSON that all other standards and practices may refer to. I think this is the standard that ECMA wants to publish. We can then consider other documents that constrain or interpret JSON for specific purposes. The poorly named application/json is one. JSON as a file format, JSON as a streaming format, and JSON as an embedded data representation are others. From paul.hoffman@vpnc.org Tue Jun 18 20:01:58 2013 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 C786411E812F for ; Tue, 18 Jun 2013 20:01:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.526 X-Spam-Level: X-Spam-Status: No, score=-102.526 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id voJfRlKy-5ZJ for ; Tue, 18 Jun 2013 20:01:54 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id D059111E8133 for ; Tue, 18 Jun 2013 20:01:49 -0700 (PDT) Received: from [10.20.30.90] (50-0-66-165.dsl.dynamic.sonic.net [50.0.66.165]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r5J31iPo007100 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 18 Jun 2013 20:01:45 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Paul Hoffman In-Reply-To: <51C1121E.8050004@crockford.com> Date: Tue, 18 Jun 2013 20:01:44 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <51B9EA49.2050604@crockford.com> <51C1121E.8050004@crockford.com> To: Douglas Crockford X-Mailer: Apple Mail (2.1508) Cc: json@ietf.org Subject: [Json] On representing what ECMA wants X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 19 Jun 2013 03:01:59 -0000 On Jun 18, 2013, at 7:06 PM, Douglas Crockford = wrote: > I think this is the standard that ECMA wants to publish. As you know from our earlier off-list discussions, you do not represent = ECMA, nor even TC39, to the IETF, nor even to this WG. Everyone from = TC39 represents themselves here. Your statement above still implies = authority that doesn't exist. ECMA and TC39 leadership has had, and probably will continue to have, = discussions about whether ECMA wants to have an official position on = what they want to see from the IETF. Until we hear that from those = higher-ups, no one speaks for ECMA here (and no one speaks for the IETF = in TC39). Please try harder to refrain from suggesting that particular = technical or process decisions would be what ECMA wants. Thanks in = advance. --Matt and Paul From paul.hoffman@vpnc.org Tue Jun 18 20:14:24 2013 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 28CCE21F9B20 for ; Tue, 18 Jun 2013 20:14:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.527 X-Spam-Level: X-Spam-Status: No, score=-102.527 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fm9aNLUwc3VR for ; Tue, 18 Jun 2013 20:14:23 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id A11B221F9B4D for ; Tue, 18 Jun 2013 20:14:04 -0700 (PDT) Received: from [10.20.30.90] (50-0-66-165.dsl.dynamic.sonic.net [50.0.66.165]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r5J3E3Sf007325 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 18 Jun 2013 20:14:04 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Paul Hoffman In-Reply-To: <51C1121E.8050004@crockford.com> Date: Tue, 18 Jun 2013 20:14:03 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <51B9EA49.2050604@crockford.com> <51C1121E.8050004@crockford.com> To: "json@ietf.org" X-Mailer: Apple Mail (2.1508) Subject: Re: [Json] Two Documents X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 19 Jun 2013 03:14:24 -0000 On Jun 18, 2013, at 7:06 PM, Douglas Crockford = wrote: > It includes an abstract, an introduction, the detailing of the = elements (object, array, string, etc), and security considerations. No = parsers or generators, no octets, no MIME types. The parser and generator sections define interoperability = specifications. Removing them is a huge change to the technical = specification, one that feels well outside of the "minimal changes" in = our charter. I still want the WG to later work on an implementation guidance document = after we have finished work on refining the current technical = specification; in fact, it is probably negligent if we don't make a run = at that. But calling requirements on parsers and generators = "implementation guidance" at this late date seems like a very bad move. --Paul Hoffman= From waldron.rick@gmail.com Tue Jun 18 20:23:23 2013 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 BBD6F21E8082 for ; Tue, 18 Jun 2013 20:23:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fft9QFohqrD4 for ; Tue, 18 Jun 2013 20:23:15 -0700 (PDT) Received: from mail-vc0-f170.google.com (mail-vc0-f170.google.com [209.85.220.170]) by ietfa.amsl.com (Postfix) with ESMTP id 3183411E8131 for ; Tue, 18 Jun 2013 20:23:14 -0700 (PDT) Received: by mail-vc0-f170.google.com with SMTP id hf12so3488496vcb.1 for ; Tue, 18 Jun 2013 20:23:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=+GW+FWylczZrNvi+q/XrrzSeSE0fc1AJ56jkJDfnrss=; b=JxHxhbjj+ZeMTt5ui06iJ5TEx5ZutfY/wsTiQFAIthjmoC14qgVaTbplVhNBi20KfQ HMa/8rExNayC8vsIYTVUxUg0JhcG4ZEIVso3oN/Qo57NbFOzygGt8RuhJ7CKL+Hh3mjm EpN3xQoZBJfU9MR8fqpKZfhpBLXfEptiOUVsPE2N8lzopCcnpyj+UwLiIETVksF7jK/2 D4Ur6vmbShJkAYJrhNTFuK8VBQk/fuECooZhToWyGUFCZrCPekduP9GNKRng5nLjfHcy 13QQcZz7Wudipwd3G7rDP5AygqtSKaFCUK6cohOo5toRhKWmTAGjURb7S/W1pjHp8MOP zR3A== X-Received: by 10.220.73.135 with SMTP id q7mr30918vcj.33.1371612194315; Tue, 18 Jun 2013 20:23:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.137.140 with HTTP; Tue, 18 Jun 2013 20:22:54 -0700 (PDT) In-Reply-To: References: <51B9EA49.2050604@crockford.com> <51C1121E.8050004@crockford.com> From: Rick Waldron Date: Tue, 18 Jun 2013 23:22:54 -0400 Message-ID: To: Paul Hoffman Content-Type: multipart/alternative; boundary=001a11c2917c9cabb504df79594f Cc: es-discuss , Douglas Crockford , "json@ietf.org" Subject: Re: [Json] On representing what ECMA wants X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 19 Jun 2013 03:23:23 -0000 --001a11c2917c9cabb504df79594f Content-Type: text/plain; charset=ISO-8859-1 cc es-discuss On Tue, Jun 18, 2013 at 11:01 PM, Paul Hoffman wrote: > > > On Jun 18, 2013, at 7:06 PM, Douglas Crockford > wrote: > > > I think this is the standard that ECMA wants to publish. > > As you know from our earlier off-list discussions, you do not represent > ECMA, nor even TC39, to the IETF, nor even to this WG. Everyone from TC39 > represents themselves here. Your statement above still implies authority > that doesn't exist. > > ECMA and TC39 leadership has had, and probably will continue to have, > discussions about whether ECMA wants to have an official position on what > they want to see from the IETF. Until we hear that from those higher-ups, > no one speaks for ECMA here (and no one speaks for the IETF in TC39). > Please try harder to refrain from suggesting that particular technical or > process decisions would be what ECMA wants. Thanks in advance. > > --Matt and Paul > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > --001a11c2917c9cabb504df79594f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
cc es-discuss


On Tue, Jun 18, 2013 at 11:01 PM, Paul Hoffman <paul.hoffman@vpnc.org> wrote:
<two chair hats on>

On Jun 18, 2013, at 7:06 PM, Douglas Crockford <douglas@crockford.com> wrote:

> I think this is the standard that ECMA wants to publish.

As you know from our earlier off-list discussions, you do not represent ECM= A, nor even TC39, to the IETF, nor even to this WG. Everyone from TC39 repr= esents themselves here. Your statement above still implies authority that d= oesn't exist.

ECMA and TC39 leadership has had, and probably will continue to have, discu= ssions about whether ECMA wants to have an official position on what they w= ant to see from the IETF. Until we hear that from those higher-ups, no one = speaks for ECMA here (and no one speaks for the IETF in TC39). Please try h= arder to refrain from suggesting that particular technical or process decis= ions would be what ECMA wants. Thanks in advance.

--Matt and Paul

_______________________________________________
json mailing list
json@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/json

--001a11c2917c9cabb504df79594f-- From mamille2@cisco.com Tue Jun 18 20:27:09 2013 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 5A8C321E80A1 for ; Tue, 18 Jun 2013 20:27:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Td5Q1OJyNB8 for ; Tue, 18 Jun 2013 20:27:01 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 2EFC821E804C for ; Tue, 18 Jun 2013 20:27:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7989; q=dns/txt; s=iport; t=1371612421; x=1372822021; h=from:to:subject:date:message-id:mime-version; bh=zaXMQNOHaTs2GNEhER/6BY8+dD8wpMtMBm7659ptmkM=; b=Y63Tnad3eh3uum6IWQe9BjwekRJ1LEyKvEKxgG/GurG0yvCSANeuw+AR TFQ2NErC2E3sx/30d0NPVrdNR16GZF2CEQuIjzTXSX8JaN+GkEgCrU/P/ i+CLSK6BebRtPnWECbpnBSZa1t2oqsDdrIB3ic1pPaHR2KbCIo2fmWuxi Y=; X-Files: smime.p7s : 4136 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApsHAKwkwVGtJV2d/2dsb2JhbABagwl6vxiBCBZtB4IlAQSBCwEqJjAnBBsGiACaKKA/jgOBB4M4YQOQAYEsl1eDD4FoQA X-IronPort-AV: E=Sophos;i="4.87,894,1363132800"; d="p7s'?scan'208";a="224634448" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-4.cisco.com with ESMTP; 19 Jun 2013 03:26:52 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r5J3QqRA031188 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 19 Jun 2013 03:26:52 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.24]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.02.0318.004; Tue, 18 Jun 2013 22:26:51 -0500 From: "Matt Miller (mamille2)" To: "json@ietf.org" Thread-Topic: About the Upcoming Consensus Calls Thread-Index: AQHObJzW/5uiyo8eL0ipfgEQaf4VwQ== Date: Wed, 19 Jun 2013 03:26:51 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.21.82.151] Content-Type: multipart/signed; boundary="Apple-Mail=_B0F7AD77-F29E-4108-8ACD-C923DCFB93BC"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Subject: [Json] About the Upcoming Consensus Calls X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 19 Jun 2013 03:27:09 -0000 --Apple-Mail=_B0F7AD77-F29E-4108-8ACD-C923DCFB93BC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hello All, Paul and I will soon be sending out calls for consensus on various = topics the Working Group has discussed. We've already sent out = "PROPOSAL LAST CHANCE" emails for some topics; others will be coming as = the chairs determine the topic's discussion has abated. These missives = each describe all of the proposals for a given topic, so there should be = no surprises during each consensus call. The chairs ask that we all keep our charter in mind, particularly: The JSON working group will have as its only initial task the minor revision of RFC 4627 to bring it onto the Standards Track. As noted above, RFC 4627 is a mature and widely cited specification. The work = is essentially a reclassification in place, with minimal changes. The working group will review errata and update the document as needed = to incorporate those, and will correct significant errors and inconsistencies, but will keep changes to a minimum. These consensus calls may initially seem like voting, especially for = those topics we've only gathered a single proposal. However, the chairs = are using these calls to understand the consensus of the WG. This model = is the one we feel provides the clearest understanding of what the WG = wants changed with as limited a scope as possible. As we expect many people can accept many proposals, we will ask that you = indicate which proposal or proposals you prefer to see in the document, = ordered from most favorable to least favorable. You should list all = proposals that you can accept, and leave off the ones you can't. One of the proposals will always be "Leave the document as-is"; do not = hesitate to select this if you can live with the document's current = wording, particularly if you believe none of the proposals would be an = improvement. Thank you all, Paul Hoffman and Matt Miller --Apple-Mail=_B0F7AD77-F29E-4108-8ACD-C923DCFB93BC Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMezCCBjQw ggQcoAMCAQICAR4wDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDE1NVoX DTE3MTAyNDIxMDE1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMcJg8zOLdgasSmkLhOrlr6KMoOMpohBllVHrdRvEg/q6r8jR+EK 75xCGhR8ToREoqe7zM9/UnC6TS2y9UKTpT1v7RSMzR0t6ndl0TWBuUr/UXBhPk+Kmy7bI4yW4urC +y7P3/1/X7U8ocb8VpH/Clt+4iq7nirMcNh6qJR+xjOhV+VHzQMALuGYn5KZmc1NbJQYclsGkDxD z2UbFqE2+6vIZoL+jb9x4Pa5gNf1TwSDkOkikZB1xtB4ZqtXThaABSONdfmv/Z1pua3FYxnCFmdr /+N2JLKutIxMYqQOJebr/f/h5t95m4JgrM3Y/w7YX9d7YAL9jvN4SydHsU6n65cCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRTcu2SnODaywFc fH6WNU7y1LhRgjAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBAAqDCH14qywG XLhjjF6uHLkjd02hcdh9hrw+VUsv+q1eeQWB21jWj3kJ96AUlPCoEGZ/ynJNScWy6QMVQjbbMXlt UfO4n4bGGdKo3awPWp61tjAFgraLJgDk+DsSvUD6EowjMTNx25GQgyYJ5RPIzKKR9tQW8gGK+2+R HxkUCTbYFnL6kl8Ch507rUdPPipJ9CgJFws3kDS3gOS5WFMxcjO5DwKfKSETEPrHh7p5shuuNktv sv6hxHTLhiMKX893gxdT3XLS9OKmCv87vkINQcNEcIIoFWbP9HORz9v3vQwR4e3ksLc2JZOAFK+s sS5XMEoznzpihEP0PLc4dCBYjbvSD7kxgDwZ+Aj8Q9PkbvE9sIPP7ON0fz095HdThKjiVJe6vofq +n6b1NBc8XdrQvBmunwxD5nvtTW4vtN6VY7mUCmxsCieuoBJ9OlqmsVWQvifIYf40dJPZkk9YgGT zWLpXDSfLSplbY2LL9C9U0ptvjcDjefLTvqSFc7tw1sEhF0n/qpA2r0GpvkLRDmcSwVyPvmjFBGq Up/pNy8ZuPGQmHwFi2/14+xeSUDG2bwnsYJQG2EdJCB6luQ57GEnTA/yKZSTKI8dDQa8Sd3zfXb1 9mOgSF0bBdXbuKhEpuP9wirslFe6fQ1t5j5R0xi72MZ8ikMu1RQZKCyDbMwazlHiMIIGPzCCBSeg AwIBAgIDBoRIMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcN MTMwNDMwMjE1NDQyWhcNMTQwNTAyMDUzOTA0WjBbMRkwFwYDVQQNExBiN2F6NndOY0t0R3JtMEpF MRswGQYDVQQDDBJtYW1pbGxlMkBjaXNjby5jb20xITAfBgkqhkiG9w0BCQEWEm1hbWlsbGUyQGNp c2NvLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJbKBMsG+9UFTx9uq/bhhXgu vJvO8z7cwKaqqwZhVf5z/kHFyCNijtmTOE+YXjA8mWR4aoBwB5SvGypI/cJUofJ+AlBTC4g+RMx/ K0Ab4/jQqTQz9CDzMOB+Wm+rt8ZJ7A8ZzOJmNDAsf/VvB8l2A1SQz1UsAixgH16NTr8SlblAXEKk 4hwpCudUiNjjQokqJ0H686UBKVorcZSgXaza8XMqGtJF/8mNhR9GQYi7Xht1ky+9LFOrto2daZto KJRwMeVusVdHUeKEQSu7jztw8HchH3KEb7Q+r5X+hhDZoddfKE8d5eyPuhiZdrzv7OlNZ0fSLdx7 3AE3nx9/R5YlXucCAwEAAaOCAtgwggLUMAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQW MBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQUxGd+/qrdVudHrIKkw5xOMY7eaLUwHwYD VR0jBBgwFoAUU3Ltkpzg2ssBXHx+ljVO8tS4UYIwHQYDVR0RBBYwFIESbWFtaWxsZTJAY2lzY28u Y29tMIIBTAYDVR0gBIIBQzCCAT8wggE7BgsrBgEEAYG1NwECAzCCASowLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0 Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBp c3N1ZWQgYWNjb3JkaW5nIHRvIHRoZSBDbGFzcyAxIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9m IHRoZSBTdGFydENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBw dXJwb3NlIGluIGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMDYG A1UdHwQvMC0wK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUxLWNybC5jcmwwgY4G CCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIv Y2xhc3MxL2NsaWVudC9jYTBCBggrBgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2Vy dHMvc3ViLmNsYXNzMS5jbGllbnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRz c2wuY29tLzANBgkqhkiG9w0BAQUFAAOCAQEAlDhXbGEI7lbqUcu5r2JHZaMsbRZda/99ZqODzWGX 0llou9jGccsAWDPPwRRe2+ROpXfH4cuJZElTcLDeZSp/qpXKhjYieFSX8+Ml9sKEj5UOSqQLyoLk PtrIJV12Jk3nuG2Jc0UeEnGwK/aqtzy7+bfEVI0ziyVM2gChHh0RH74KyiwYWknbOTRIkZcz/ulE DVFQp63uj6wfmDNvAUHBAdhKVqA1S/rfP1KcDZpf1NfvwXJibiqTRA6K1EOxTJOP41n/XdvHqHXL RWL2xrOUI9/URANr/ok3OrsuZEMFnAAGefS1bWS/hFtUGVkHGiKEBbyDW7da2ULXbuC7umrQnzGC A28wggNrAgEBMIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkG A1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwaESDAJBgUrDgMCGgUA oIIBrzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMzA2MTkwMzI2 NTBaMCMGCSqGSIb3DQEJBDEWBBQCzLm/aW54QVHLPN3wutcv7fY+LTCBpQYJKwYBBAGCNxAEMYGX MIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3Mg MSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwaESDCBpwYLKoZIhvcNAQkQAgsxgZeg gZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1 cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAx IFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDBoRIMA0GCSqGSIb3DQEBAQUABIIBAF9k TkmF94jrBCGtxkcbilmmkpnW3TgOt8iUzpAt91XQ6pSgM3QY4LbWTHhoLwreX+sTiINDtFcptMh1 990xAQDXx1S2UM15C6sc/1YmvSuN5Q/znr9Y/V4o5B3LBUpbuvARIk/N3lYTd6JOQTYudmktdyX2 tBHwb0Woiff5M83amOneI5OlnzCW/3V9uzZGyzyaeC7SPGmz39nm4nZYxbY1CBvpn9JpBwMX67RB FHoE6KdrsbBjmBqRkiRxAzL4GtB70AoMxgpoE2qj5QFMtDmzqB/ugwntBThoAnyBEcHbYFW0D1dh 2u/Ie6HL6xtwHcHccfSOPegEyzfCX4BpiBkAAAAAAAA= --Apple-Mail=_B0F7AD77-F29E-4108-8ACD-C923DCFB93BC-- From erights@gmail.com Tue Jun 18 20:39:50 2013 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 71A4821E80B7 for ; Tue, 18 Jun 2013 20:39:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.765 X-Spam-Level: X-Spam-Status: No, score=-2.765 tagged_above=-999 required=5 tests=[AWL=0.833, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ukdkhz+oPTPl for ; Tue, 18 Jun 2013 20:39:46 -0700 (PDT) Received: from mail-vc0-f169.google.com (mail-vc0-f169.google.com [209.85.220.169]) by ietfa.amsl.com (Postfix) with ESMTP id 3BDCA21E8056 for ; Tue, 18 Jun 2013 20:39:44 -0700 (PDT) Received: by mail-vc0-f169.google.com with SMTP id ia10so3494913vcb.28 for ; Tue, 18 Jun 2013 20:39:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=/Rd8A2AR8Xl1xUrlFYNoTmO33eW8pA+vq/p4/Bdx52c=; b=04s1fQbn61NKsGEbAjtG/sWuEZHxiRBlw2UpX3P9tiMRScGOLlcGlYkJY46/D34lL1 Gb5fCDnh0Q6hxNVXRDgN5PgV2Jc0hrqJRGphTSLtB5Z/Tw/PIkV0QQBtajER6tsxLNS0 DGTabm/xVYycBGSzry7gkhr/oLt0TSaGuFFExM3ccUtyEsiin9dl2CzHrQ4YD/ijHvNu sF3CZ28kwlUvqRoMjb0Cfwb9M+6czLZ7lNVdCPCwLuThIKHD2hirspjDyDf3t526lEnl ufBSJijVaaQy6Aqz6lQ7QUhy/1eHiin3PYSS+c8Xsq5ff8SMmDpCrvHOqyyMyCQSJUBy 3lYA== MIME-Version: 1.0 X-Received: by 10.58.182.103 with SMTP id ed7mr339016vec.70.1371613183669; Tue, 18 Jun 2013 20:39:43 -0700 (PDT) Received: by 10.52.0.202 with HTTP; Tue, 18 Jun 2013 20:39:43 -0700 (PDT) In-Reply-To: References: <51B9EA49.2050604@crockford.com> <51C1121E.8050004@crockford.com> Date: Tue, 18 Jun 2013 20:39:43 -0700 Message-ID: From: Mark Miller To: Rick Waldron Content-Type: multipart/alternative; boundary=047d7b676e1c9500ce04df7994d8 Cc: "json@ietf.org" , Paul Hoffman , Douglas Crockford , es-discuss Subject: Re: [Json] On representing what ECMA wants X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 19 Jun 2013 03:39:50 -0000 --047d7b676e1c9500ce04df7994d8 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Jun 18, 2013 at 8:22 PM, Rick Waldron wrote: > cc es-discuss > > > On Tue, Jun 18, 2013 at 11:01 PM, Paul Hoffman wrote: > >> >> >> On Jun 18, 2013, at 7:06 PM, Douglas Crockford >> wrote: >> >> > I think this is the standard that ECMA wants to publish. >> >> As you know from our earlier off-list discussions, you do not represent >> ECMA, nor even TC39, to the IETF, nor even to this WG. Everyone from TC39 >> represents themselves here. Your statement above still implies authority >> that doesn't exist. >> > Hi Paul, I'm missing all the context, but from this out of context fragment, your response seems inappropriate. A statement like Doug's "I think this is the standard that ECMA wants to publish" sounds to me like speculation on how TC39 will react to some proposed standard. Whether coming from someone on TC39 or not, I do not see that any assertion of authority is involved. Here on es-discuss, both members and non-members of TC39 speculate and argue all the time on what kinds of things TC39 might approve of. Member of TC39 participate in these discussions, not to speak for TC39 as a whole, but to speak a) for themselves as participants in TC39, and b) as someone who is more informed than most, but still fallible, speculating about howTC39 might react to something. Perhaps this line gets blurry sometimes, but a statement like "I think this is the standard that ECMA wants to publish" seems to me clearly on the non-blurry side of that line. If the context changes how all this would be interpreted, my apologies. > >> ECMA and TC39 leadership has had, and probably will continue to have, >> discussions about whether ECMA wants to have an official position on what >> they want to see from the IETF. Until we hear that from those higher-ups, >> no one speaks for ECMA here (and no one speaks for the IETF in TC39). >> Please try harder to refrain from suggesting that particular technical or >> process decisions would be what ECMA wants. Thanks in advance. >> >> --Matt and Paul >> >> _______________________________________________ >> json mailing list >> json@ietf.org >> https://www.ietf.org/mailman/listinfo/json >> > > > _______________________________________________ > es-discuss mailing list > es-discuss@mozilla.org > https://mail.mozilla.org/listinfo/es-discuss > > -- Text by me above is hereby placed in the public domain Cheers, --MarkM --047d7b676e1c9500ce04df7994d8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, Jun 18, 2013 at 8:22 PM, Rick Waldron <waldr= on.rick@gmail.com> wrote:
cc es-discuss


On Tue, Jun 1= 8, 2013 at 11:01 PM, Paul Hoffman <paul.hoffman@vpnc.org> wrote:
<two chair hats on>

On Jun 18, 2013, at 7:06 PM, Douglas Crockford <douglas@crockford.com> wrote:

> I think this is the standard that ECMA wants to publish.

As you know from our earlier off-list discussions, you do not represent ECM= A, nor even TC39, to the IETF, nor even to this WG. Everyone from TC39 repr= esents themselves here. Your statement above still implies authority that d= oesn't exist.

Hi Paul, I= 'm missing all the context, but from this out of context fragment, your= response seems inappropriate. A statement like Doug's "I think th= is is the standard that ECMA wants to publish" sounds to me like specu= lation on how TC39 will react to some proposed standard. Whether coming fro= m someone on TC39 or not, I do not see that any assertion of authority is i= nvolved. Here on es-discuss, both members and non-members of TC39 speculate= and argue all the time on what kinds of things TC39 might approve of. Memb= er of TC39 participate in these discussions, not to speak for TC39 as a who= le, but to speak a) for themselves as participants in TC39, and b) as someo= ne who is more informed than most, but still fallible, speculating about ho= wTC39 might react to something. Perhaps this line gets blurry sometimes, bu= t a statement like "I think this is the standard that ECMA wants to pu= blish" seems to me clearly on the non-blurry side of that line.

If th= e context changes how all this would be interpreted, my apologies.
=A0

ECMA and TC39 leadership has had, and probably will continue to have, discu= ssions about whether ECMA wants to have an official position on what they w= ant to see from the IETF. Until we hear that from those higher-ups, no one = speaks for ECMA here (and no one speaks for the IETF in TC39). Please try h= arder to refrain from suggesting that particular technical or process decis= ions would be what ECMA wants. Thanks in advance.

--Matt and Paul

_______________________________________________
json mailing list
json@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/json


_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
= https://mail.mozilla.org/listinfo/es-discuss




--
Text by = me above is hereby placed in the public domain

=A0 Cheers,
=A0 --= MarkM
--047d7b676e1c9500ce04df7994d8-- From paul.hoffman@vpnc.org Tue Jun 18 20:47:57 2013 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 05A1B21E80B3 for ; Tue, 18 Jun 2013 20:47:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.528 X-Spam-Level: X-Spam-Status: No, score=-102.528 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0CImaJsUDD2r for ; Tue, 18 Jun 2013 20:47:56 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 6BAAE21E8056 for ; Tue, 18 Jun 2013 20:47:56 -0700 (PDT) Received: from [10.20.30.90] (50-0-66-165.dsl.dynamic.sonic.net [50.0.66.165]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r5J3lsOo007940 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 18 Jun 2013 20:47:55 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Paul Hoffman In-Reply-To: Date: Tue, 18 Jun 2013 20:47:54 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <51B9EA49.2050604@crockford.com> <51C1121E.8050004@crockford.com> To: es-discuss , "json@ietf.org" X-Mailer: Apple Mail (2.1508) Subject: Re: [Json] On representing what ECMA wants X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 19 Jun 2013 03:47:57 -0000 On Jun 18, 2013, at 8:39 PM, Mark Miller wrote: > Hi Paul, I'm missing all the context, but from this out of context = fragment, your response seems inappropriate. A statement like Doug's "I = think this is the standard that ECMA wants to publish" sounds to me like = speculation on how TC39 will react to some proposed standard. If that's truly the case, such speculation from a random person is fine. = Clearly, Douglas is not a random person: he is both the author of RFC = 4627 and a TC39 member. If he meant to make that statement as neither, = he needs to have said so. > Whether coming from someone on TC39 or not, I do not see that any = assertion of authority is involved. Here on es-discuss, both members and = non-members of TC39 speculate and argue all the time on what kinds of = things TC39 might approve of. Member of TC39 participate in these = discussions, not to speak for TC39 as a whole, but to speak a) for = themselves as participants in TC39, and b) as someone who is more = informed than most, but still fallible, speculating about howTC39 might = react to something. Perhaps this line gets blurry sometimes, but a = statement like "I think this is the standard that ECMA wants to publish" = seems to me clearly on the non-blurry side of that line. Different SDOs have different customs, and in the IETF, custom says that = you make clear when you are speculating and when you are representing. = Douglas' earlier statement about ECMA was misinterpreted by WG members, = so it felt worthwhile for the chairs to make clear who is and is not = representing whom to the IETF. --Paul Hoffman= From cabo@tzi.org Wed Jun 19 00:36:27 2013 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 462B021F8EB3 for ; Wed, 19 Jun 2013 00:36:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.201 X-Spam-Level: X-Spam-Status: No, score=-106.201 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Arl9cRrMDBuo for ; Wed, 19 Jun 2013 00:36:21 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 64D3921F9EE5 for ; Wed, 19 Jun 2013 00:36:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r5J7a6Ho018104; Wed, 19 Jun 2013 09:36:06 +0200 (CEST) Received: from [192.168.217.105] (p54893A31.dip0.t-ipconnect.de [84.137.58.49]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 32143368D; Wed, 19 Jun 2013 09:36:06 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: Date: Wed, 19 Jun 2013 09:36:05 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <210C6860-3EAA-423B-93FD-926D71151C07@tzi.org> References: To: Paul Hoffman X-Mailer: Apple Mail (2.1508) Cc: "Joe Hildebrand \(jhildebr\)" , "json@ietf.org" Subject: Re: [Json] Complete section 3 proposal X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 19 Jun 2013 07:36:27 -0000 On Jun 19, 2013, at 00:16, Paul Hoffman wrote: > Because the first code point of a JSON text will always be a character = in the range U+0022 to U+007B, The following six characters can occur at the start of a JSON text: %x20 ; Space %x09 ; Horizontal tab %x0A ; Line feed or New line %x0D ; Carriage return %x5B ; [ left square bracket %x7B ; { left curly bracket Four of those six characters are not in that range. They are all in the ASCII subset of Unicode. (Of course, that set might increase if we redefine what a JSON text is, = but it is likely to stay ASCII.) Gr=FC=DFe, Carsten From markus.lanthaler@gmx.net Wed Jun 19 00:41:04 2013 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 2217B21F9A43 for ; Wed, 19 Jun 2013 00:41:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.15 X-Spam-Level: X-Spam-Status: No, score=-1.15 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FmOc3GfiUYIx for ; Wed, 19 Jun 2013 00:40:58 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) by ietfa.amsl.com (Postfix) with ESMTP id 0544221F9A35 for ; Wed, 19 Jun 2013 00:40:57 -0700 (PDT) Received: from mailout-de.gmx.net ([10.1.76.19]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0M8cSj-1U3Ay32Hlz-00wI0x for ; Wed, 19 Jun 2013 09:40:56 +0200 Received: (qmail invoked by alias); 19 Jun 2013 07:40:56 -0000 Received: from 84-115-182-43.dynamic.surfer.at (EHLO Vostro3500) [84.115.182.43] by mail.gmx.net (mp019) with SMTP; 19 Jun 2013 09:40:56 +0200 X-Authenticated: #419883 X-Provags-ID: V01U2FsdGVkX18JOvk+B0gJmuYb1hBAwKS0D3Xx9p1hyVlNmjnCF2 4qbaYY9eB2wgM+ From: "Markus Lanthaler" To: References: <51B9EA49.2050604@crockford.com> <51C1121E.8050004@crockford.com> In-Reply-To: Date: Wed, 19 Jun 2013 09:40:49 +0200 Message-ID: <00c301ce6cc0$52d84970$f888dc50$@lanthaler@gmx.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac5smxunFEMXs5GYSUi9FXDB0oNhrwAJTGJw Content-Language: de X-Y-GMX-Trusted: 0 Subject: Re: [Json] Two Documents X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 19 Jun 2013 07:41:04 -0000 On Wednesday, June 19, 2013 5:14 AM, Paul Hoffman wrote: > The parser and generator sections define interoperability > specifications. Removing them is a huge change to the technical > specification, one that feels well outside of the "minimal changes" in > our charter. > > I still want the WG to later work on an implementation guidance > document after we have finished work on refining the current technical > specification; in fact, it is probably negligent if we don't make a run > at that. But calling requirements on parsers and generators > "implementation guidance" at this late date seems like a very bad move. +1 -- Markus Lanthaler @markuslanthaler From stefan@drees.name Wed Jun 19 04:13:14 2013 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 C128821F944C for ; Wed, 19 Jun 2013 04:13:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xJ2BI9lMMhsm for ; Wed, 19 Jun 2013 04:13:09 -0700 (PDT) Received: from mout.web.de (mout.web.de [212.227.17.11]) by ietfa.amsl.com (Postfix) with ESMTP id B25E321F946C for ; Wed, 19 Jun 2013 04:13:08 -0700 (PDT) Received: from newyork.local.box ([93.197.218.44]) by smtp.web.de (mrweb002) with ESMTPSA (Nemesis) id 0MGRMG-1V2TkQ1XqS-00DEp6; Wed, 19 Jun 2013 13:13:06 +0200 Message-ID: <51C19241.6050003@drees.name> Date: Wed, 19 Jun 2013 13:13:05 +0200 From: Stefan Drees User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Markus Lanthaler References: <51B9EA49.2050604@crockford.com> <51C1121E.8050004@crockford.com> <51c16094.a3da440a.212b.ffffbdc5SMTPIN_ADDED_BROKEN@mx.google.com> In-Reply-To: <51c16094.a3da440a.212b.ffffbdc5SMTPIN_ADDED_BROKEN@mx.google.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:0IdIK4CXZkLm3Pv0aCFPGGeuYaL7RkYrgxT6LtBpJupWubd8XNZ 1GeCV4AEKqfwq+LzUcuQSsyBt8PuuGiBAcYKkRhprLHYokUJYm6qjM7EDxtVpuGvDgDXrM4 rktFATeU5cHGTVt0ZXJLHF/QQTN5c/dRJ9c+QtRvSuXNQTsNQR3tdZ9uCkZleBwtEOYN1ST G9OXkpNFR1JAUN1xzo8GA== Cc: json@ietf.org Subject: Re: [Json] Two Documents X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stefan@drees.name List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2013 11:13:14 -0000 On 2013-06-19 09:40 +02:00, Markus Lanthaler wrote: > On Wednesday, June 19, 2013 5:14 AM, Paul Hoffman wrote: >> The parser and generator sections define interoperability >> specifications. Removing them is a huge change to the technical >> specification, one that feels well outside of the "minimal changes" in >> our charter. >> >> I still want the WG to later work on an implementation guidance >> document after we have finished work on refining the current technical >> specification; in fact, it is probably negligent if we don't make a run >> at that. But calling requirements on parsers and generators >> "implementation guidance" at this late date seems like a very bad move. > > +1 +1 From petejson@codalogic.com Wed Jun 19 06:26:05 2013 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 F0B0921F84AA for ; Wed, 19 Jun 2013 06:26:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.768 X-Spam-Level: * X-Spam-Status: No, score=1.768 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_50=0.001, SARE_HEAD_XUNSENT=1.666, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pnGp-a4lGKFz for ; Wed, 19 Jun 2013 06:26:01 -0700 (PDT) Received: from codalogic.com (codalogic.com [94.136.60.219]) by ietfa.amsl.com (Postfix) with ESMTP id B065121F9962 for ; Wed, 19 Jun 2013 06:26:00 -0700 (PDT) Received: (qmail 14083 invoked from network); 19 Jun 2013 14:25:59 +0100 Received: from host86-169-212-62.range86-169.btcentralplus.com (HELO codalogic) (86.169.212.62) by codalogic.com with (RC4-MD5 encrypted) SMTP; 19 Jun 2013 14:25:59 +0100 Message-ID: <4556367B73674E6FAB1E92C7CF3A2125@codalogic> From: "Pete Cordell" To: "Joe Hildebrand \(jhildebr\)" , References: X-Unsent: 1 x-vipre-scanned: 0130216C0049A6013022B9 Date: Wed, 19 Jun 2013 14:26:08 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Subject: Re: [Json] Complete section 3 proposal X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 19 Jun 2013 13:26:06 -0000 Original Message From: "Joe Hildebrand (jhildebr)" > Since the first code point of JSON text will always be an ASCII > character [RFC0020], it is possible to determine whether an octet stream > is UTF-8, UTF-16BE, UTF-16LE, UTF-32BE, or UTF-32LE by looking at the > pattern of nulls in the first four octets of a stream. In the following > table "00" corresponds to an octet with value zero, "xx" corresponds to an > octet known to be non-zero, and "??" corresponds to an octet that is not > checked. > > 00 00 00 xx UTF-32BE > 00 xx ?? xx UTF-16BE > xx 00 00 00 UTF-32LE > xx 00 xx ?? UTF-16LE > xx xx ?? ?? UTF-8 > > Note: streams less than four octets long are not UTF-32BE or UTF-32LE, and > streams less than two octets long are UTF-8. To nit-pic, I think in the UTF-16BE case, by the time you've seen 00 xx you don't need anymore characters, so it's line should be: 00 xx ?? ?? UTF-16BE Or is the idea to include some redundancy in the detection? Pete Cordell Codalogic Ltd C++ tools for C++ programmers, http://codalogic.com Read & write XML in C++, http://www.xml2cpp.com From paul.hoffman@vpnc.org Wed Jun 19 06:39:49 2013 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 8F1F021F9BAF for ; Wed, 19 Jun 2013 06:39:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.529 X-Spam-Level: X-Spam-Status: No, score=-102.529 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8CXIpV0KzD6A for ; Wed, 19 Jun 2013 06:39:49 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 1C76221F91A5 for ; Wed, 19 Jun 2013 06:39:49 -0700 (PDT) Received: from [10.20.30.90] (50-0-66-165.dsl.dynamic.sonic.net [50.0.66.165]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r5JDdiCX032230 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 19 Jun 2013 06:39:45 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Paul Hoffman In-Reply-To: <210C6860-3EAA-423B-93FD-926D71151C07@tzi.org> Date: Wed, 19 Jun 2013 06:39:44 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <210C6860-3EAA-423B-93FD-926D71151C07@tzi.org> To: Carsten Bormann X-Mailer: Apple Mail (2.1508) Cc: "Joe Hildebrand \(jhildebr\)" , "json@ietf.org" Subject: Re: [Json] Complete section 3 proposal X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 19 Jun 2013 13:39:49 -0000 On Jun 19, 2013, at 12:36 AM, Carsten Bormann wrote: > On Jun 19, 2013, at 00:16, Paul Hoffman wrote: >=20 >> Because the first code point of a JSON text will always be a = character in the range U+0022 to U+007B, >=20 > The following six characters can occur at the start of a JSON text: >=20 > %x20 ; Space > %x09 ; Horizontal tab > %x0A ; Line feed or New line > %x0D ; Carriage return >=20 > %x5B ; [ left square bracket > %x7B ; { left curly bracket >=20 > Four of those six characters are not in that range. Very good point. s/U+0022/U+0009/. > They are all in the ASCII subset of Unicode. The "ASCII subset of Unicode" is not well-defined, and for bonus = confusion, includes U+0000. > (Of course, that set might increase if we redefine what a JSON text = is, but it is likely to stay ASCII.) We are trying to deal with one discussion topic at a time. We are not = succeeding, but we are trying. --Paul Hoffman= From cowan@ccil.org Wed Jun 19 06:57:02 2013 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 51B5F21F9C0B for ; Wed, 19 Jun 2013 06:57:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.46 X-Spam-Level: X-Spam-Status: No, score=-3.46 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Il-Hlsx8WmJS for ; Wed, 19 Jun 2013 06:56:58 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id E337321F94DC for ; Wed, 19 Jun 2013 06:56:57 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1UpIsX-0007GE-J4; Wed, 19 Jun 2013 09:56:53 -0400 Date: Wed, 19 Jun 2013 09:56:53 -0400 From: John Cowan To: Paul Hoffman Message-ID: <20130619135653.GA24889@mercury.ccil.org> References: <210C6860-3EAA-423B-93FD-926D71151C07@tzi.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Cc: Carsten Bormann , "Joe Hildebrand \(jhildebr\)" , "json@ietf.org" Subject: Re: [Json] Complete section 3 proposal X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 19 Jun 2013 13:57:02 -0000 Paul Hoffman scripsit: > > They are all in the ASCII subset of Unicode. > > The "ASCII subset of Unicode" is not well-defined, and for bonus > confusion, includes U+0000. Of course it does. ASCII = ECMA-6 = ISO 646:1991 is, as it proclaims, a set of 128 characters. Where's the lack of well-definition? Or as Irving Berlin didn't quite write: There's no ASCII but US-ASCII, The only ASCII, I know; Everything about it is US-based, Everything about it's seven-bit. You do that X-three-dot-four wheeler-dealing, When you're feeling Retro-fit. There's no ASCII but US-ASCII, It's Unicode's first half-row; Though it is a turkey that we know must die, While systems chop off the bits that are high, It is the only charset that will always fly, ASCII, backward we go, ASCII, on with the show! -- Verbogeny is one of the pleasurettes John Cowan of a creatific thinkerizer. http://www.ccil.org/~cowan --Peter da Silva From tbray@textuality.com Wed Jun 19 07:33:28 2013 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 0D05021F9C35 for ; Wed, 19 Jun 2013 07:33:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.31 X-Spam-Level: X-Spam-Status: No, score=-1.31 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fNztUPNTl47v for ; Wed, 19 Jun 2013 07:33:23 -0700 (PDT) Received: from mail-vc0-f178.google.com (mail-vc0-f178.google.com [209.85.220.178]) by ietfa.amsl.com (Postfix) with ESMTP id A65CE21F9C0B for ; Wed, 19 Jun 2013 07:33:23 -0700 (PDT) Received: by mail-vc0-f178.google.com with SMTP id m17so3887901vca.9 for ; Wed, 19 Jun 2013 07:33:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=tMuYw/8CrU1NMdJriCWOOm7TktgErzTmRUfTbmrsHWA=; b=V2fFztRWleinOXAC4ZxbfjtHRjs3OSRWZ2kvC7ou5SypVSEvZJ9+8ALie6+av/05Zt mfk5YY9GbPfgZ2Fm4wMzqj3o6DhN2+ej1aLQDGdr8ffprB2nLIvAWSbhzlMDD44vISJq i5+lKpLnM70SSEIU+bE/mTGjbWPcj1ifjK08xdOI5mLWHf6OWQsmkFL2AWMzZVQ0RKAY 6Hl8lJ/HjnsNeGr578A/qVezMshQLGXR0Xnp2DheJpsuEULjIDLT3LjwkAv82mAKENEF haey8mdEewRcIFAi457yHGnRZm/oZP00IkKLiDYVetbaUOxGSbIgabGu7RMm9tRsSdqS znrQ== MIME-Version: 1.0 X-Received: by 10.220.48.73 with SMTP id q9mr705259vcf.36.1371652402266; Wed, 19 Jun 2013 07:33:22 -0700 (PDT) Received: by 10.220.219.200 with HTTP; Wed, 19 Jun 2013 07:33:21 -0700 (PDT) X-Originating-IP: [172.19.42.63] In-Reply-To: <51C1121E.8050004@crockford.com> References: <51B9EA49.2050604@crockford.com> <51C1121E.8050004@crockford.com> Date: Wed, 19 Jun 2013 07:33:21 -0700 Message-ID: From: Tim Bray To: Douglas Crockford Content-Type: multipart/alternative; boundary=001a11c2e25831561904df82b629 X-Gm-Message-State: ALoCoQnJjOHcF1AGkca+TDOeeUQZX1cG5A27kEbYDhiL2ZCosM45glLRdN2yM2JV5zaONiETOpbf Cc: "json@ietf.org" , "Matt Miller \(mamille2\)" Subject: Re: [Json] Two Documents X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 19 Jun 2013 14:33:28 -0000 --001a11c2e25831561904df82b629 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Let=E2=80=99s take a moment to consider who our audience is. The RFC will = be used almost exclusively by JSON parser and generator implementors. Out in the general population of JSON users, the only docs they look at are the docs for the parser/generator library they=E2=80=99re using. And if I=E2=80=99m an implementor writing a JSON parser or generator, well,= yeah, I care about the abstract grammar and the security issues, but I also care about what the incoming sequence of bytes is going to look like, and what the outgoing sequence of bytes needs to look like. So I think it would be abusive to our customers to make them read two documents to get their jobs done. I=E2=80=99m scratching my head to think = of anyone who would read one of these documents but not the other, and I=E2=80= =99m coming up empty. -Tim On Tue, Jun 18, 2013 at 7:06 PM, Douglas Crockford w= rote: > On 6/17/2013 5:14 PM, Matt Miller (mamille2) wrote: > >> Hello Douglas, >> >> In order for the WG to fully understand your proposal, we need a more >> definitive list of what to expect in each document. >> >> As a starting point, can you describe which sections of the current >> RFC4627 would be in "JSON Data Interchange Format" and which would be in >> the JSON best practices document? Clearly the latter will have many >> additions from the recent discussions, but it is less clear which portio= ns >> of the current text goes into which document. >> >> Please excuse the lateness of this reply. I am traveling. > > I am proposing that The JSON Data Interchange Format document contain onl= y > the material that is universal to all applications of JSON. So, for > example, the only dependency on any character encoding is the > interpretation of the four hex digits in the \u notation, where Unicode > determines the meaning of the numbers. > > It includes an abstract, an introduction, the detailing of the elements > (object, array, string, etc), and security considerations. No parsers or > generators, no octets, no MIME types. > > This provides a standard description of JSON that all other standards and > practices may refer to. I think this is the standard that ECMA wants to > publish. > > We can then consider other documents that constrain or interpret JSON for > specific purposes. The poorly named application/json is one. JSON as a fi= le > format, JSON as a streaming format, and JSON as an embedded data > representation are others. > > ______________________________**_________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/**listinfo/json > --001a11c2e25831561904df82b629 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Let=E2=80=99s take a moment to consider who= our audience is.=C2=A0 The RFC will be used almost exclusively by JSON par= ser and generator implementors. Out in the general population of JSON users= , the only docs they look at are the docs for the parser/generator library = they=E2=80=99re using.

And if I=E2=80=99m an implementor writing a JSON parser or genera= tor, well, yeah, I care about the abstract grammar and the security issues,= but I also care about what the incoming sequence of bytes is going to look= like, and what the outgoing sequence of bytes needs to look like.

So I think it would be abusive to our customers to make them read= two documents to get their jobs done.=C2=A0 I=E2=80=99m scratching my head= to think of anyone who would read one of these documents but not the other= , and I=E2=80=99m coming up empty.

=C2=A0-Tim


On Tue, Jun 18, 2013 at 7:06 PM, Douglas Crockford <d= ouglas@crockford.com> wrote:
On 6/17/2013 5:14 PM, Matt= Miller (mamille2) wrote:
Hello Douglas,

In order for the WG to fully understand your proposal, we need a more defin= itive list of what to expect in each document.

As a starting point, can you describe which sections of the current RFC4627= would be in "JSON Data Interchange Format" and which would be in= the JSON best practices document? =C2=A0Clearly the latter will have many = additions from the recent discussions, but it is less clear which portions = of the current text goes into which document.

Please excuse the lateness of this reply. I am traveling.

I am proposing that The JSON Data Interchange Format document contain only = the material that is universal to all applications of JSON. So, for example= , the only dependency on any character encoding is the interpretation of th= e four hex digits in the \u notation, where Unicode determines the meaning = of the numbers.

It includes an abstract, an introduction, the detailing of the elements (ob= ject, array, string, etc), and security considerations. No parsers or gener= ators, no octets, no MIME types.

This provides a standard description of JSON that all other standards and p= ractices may refer to. I think this is the standard that ECMA wants to publ= ish.

We can then consider other documents that constrain or interpret JSON for s= pecific purposes. The poorly named application/json is one. JSON as a file = format, JSON as a streaming format, and JSON as an embedded data representa= tion are others.

_______________________________________________
json mailing list
json@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/json

--001a11c2e25831561904df82b629-- From jhildebr@cisco.com Wed Jun 19 07:48:16 2013 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 5B13321F9C4B for ; Wed, 19 Jun 2013 07:48:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mYxwouXhYRfy for ; Wed, 19 Jun 2013 07:48:10 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id B4A9C21F9C57 for ; Wed, 19 Jun 2013 07:48:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1027; q=dns/txt; s=iport; t=1371653290; x=1372862890; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=/A0M6SHAMElqgsIoZ8RK0Qe/IvOuG/P+Tb8mQtc3aO4=; b=RkRE7Liq+z06mzNucpP9HoRiJsEX3nVWtlPuVPo60vJL2LtsGOaMBNvo tB1SUbnRsZosGZaZnaxFua/TPecRxXDGwHh9sdQ94RRvU65U7hXOyFgH+ VeI7xy7J5/RdVoo83xZAFFsjiLF0ObbOdwrM/ibMRJACj+jSHvd30Ut8i c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnEFADHEwVGtJXG9/2dsb2JhbABagwl6vxuBABZ0giMBAQEEOj8SAQgYChRCJQIEDgUIiAa7WY8RMQeDAGEDqQWDD4Io X-IronPort-AV: E=Sophos;i="4.87,896,1363132800"; d="scan'208";a="224900887" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-4.cisco.com with ESMTP; 19 Jun 2013 14:47:48 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r5JElmR4009279 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 19 Jun 2013 14:47:48 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.56]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.02.0318.004; Wed, 19 Jun 2013 09:47:48 -0500 From: "Joe Hildebrand (jhildebr)" To: Paul Hoffman Thread-Topic: [Json] Complete section 3 proposal Thread-Index: AQHObGQOe+q+3fshkkqz/+DniugiRZk8XgcAgACwWIA= Date: Wed, 19 Jun 2013 14:47:47 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [10.129.24.242] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "json@ietf.org" Subject: Re: [Json] Complete section 3 proposal X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 19 Jun 2013 14:48:16 -0000 On 6/18/13 4:16 PM, "Paul Hoffman" wrote: >On Jun 18, 2013, at 1:40 PM, Joe Hildebrand (jhildebr) > wrote: > >> Since the first code point of JSON text will always be an ASCII >> character [RFC0020], > >You were so good with using "encoding schemes", then you fell into this. >:-) While the reference to RFC 20 is cute, it actually doesn't help here. I wasn't trying to be cute, I was trying to reduce the size of the diff from 4627. I'm fine with changing the proposed text to be more precise. >A more direct statement would be: > >=3D=3D=3D=3D=3D >Because the first code point of a JSON text will always be a character in >the range U+0022 to U+007B, >=3D=3D=3D=3D=3D With the suggestion of tab, etc, needing to be included, my preference would be to say U+0001 to U+007F, rather than calling out all of the possibilities; this allows us to decouple the "what values can occur at the top level" conversation from this one. --=20 Joe Hildebrand From jhildebr@cisco.com Wed Jun 19 07:48:25 2013 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 5304121F9C4B for ; Wed, 19 Jun 2013 07:48:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KQrc9T+uHok7 for ; Wed, 19 Jun 2013 07:48:19 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 999B121F9CE3 for ; Wed, 19 Jun 2013 07:48:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=340; q=dns/txt; s=iport; t=1371653299; x=1372862899; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=iOvAriRyvyKc4oqlL7zf8xXLoAVp3GkPupeI/j4Toik=; b=COeeMJiL/J/npXI5HH0V5r3MRxleHHXwOVGncEh2m7jWskV3I3afoOZv DDcDiWi08njxlui5uypqSjE2/fel4i3y5qphJbur7ZUapN3FbhzUypwrj C1jBFl05bt+1T9ImwEOsAOt/GIJkOfSzg2SVXDuQia58rAOaENmXLPhXC Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApYGAInDwVGtJV2b/2dsb2JhbABagwl6gju8YIEAFnSCJQEEOlEBCCIUQiUCBAESCIgGu1iPETiDAGEDqQWDD4Io X-IronPort-AV: E=Sophos;i="4.87,896,1363132800"; d="scan'208";a="221844283" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-9.cisco.com with ESMTP; 19 Jun 2013 14:48:19 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r5JEmJuH020178 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 19 Jun 2013 14:48:19 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.56]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.02.0318.004; Wed, 19 Jun 2013 09:48:18 -0500 From: "Joe Hildebrand (jhildebr)" To: Pete Cordell , "json@ietf.org" Thread-Topic: [Json] Complete section 3 proposal Thread-Index: AQHObGQOe+q+3fshkkqz/+DniugiRZk9CE09gAAGNYA= Date: Wed, 19 Jun 2013 14:48:17 +0000 Message-ID: In-Reply-To: <4556367B73674E6FAB1E92C7CF3A2125@codalogic> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [10.129.24.242] Content-Type: text/plain; charset="us-ascii" Content-ID: <243B32EE1A77644089223B80D91F4E0F@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Json] Complete section 3 proposal X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 19 Jun 2013 14:48:25 -0000 On 6/19/13 7:26 AM, "Pete Cordell" wrote: >To nit-pic, I think in the UTF-16BE case, by the time you've seen 00 xx >you=20 >don't need anymore characters, so it's line should be: > > 00 xx ?? ?? UTF-16BE > > >Or is the idea to include some redundancy in the detection? +1 --=20 Joe Hildebrand From cabo@tzi.org Wed Jun 19 07:49:46 2013 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 A633421F9CC8 for ; Wed, 19 Jun 2013 07:49:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.2 X-Spam-Level: X-Spam-Status: No, score=-106.2 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UOQhOJhC0BuC for ; Wed, 19 Jun 2013 07:49:40 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 9080021F9CE2 for ; Wed, 19 Jun 2013 07:49:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r5JEnV9n026574 for ; Wed, 19 Jun 2013 16:49:31 +0200 (CEST) Received: from [192.168.217.105] (p54893A31.dip0.t-ipconnect.de [84.137.58.49]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 88B283B57; Wed, 19 Jun 2013 16:49:31 +0200 (CEST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Carsten Bormann In-Reply-To: Date: Wed, 19 Jun 2013 16:49:30 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <970B7CC5-0726-4BED-94D7-FF91D335E1E3@tzi.org> References: <51B9EA49.2050604@crockford.com> <51C1121E.8050004@crockford.com> To: "json@ietf.org" X-Mailer: Apple Mail (2.1508) Subject: Re: [Json] Two Documents X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 19 Jun 2013 14:49:46 -0000 On Jun 19, 2013, at 05:14, Paul Hoffman wrote: > interoperability That is the operative work here. We write standards track specifications to foster interoperability. If you can't go away with a standards track spec (and the documents it = normatively references) and independently create something that then = interoperates, the spec has missed its mark. The WG is specifically tasked with taking the existing RFC to = standards-track, so any change that counteracts that objective is a = non-starter. So +1 to what Paul and Tim said. Gr=FC=DFe, Carsten From jhildebr@cisco.com Wed Jun 19 08:00:30 2013 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 67CDD21F9C03 for ; Wed, 19 Jun 2013 08:00:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N9aFPvqlMZg6 for ; Wed, 19 Jun 2013 08:00:24 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id ED9A121F9C9E for ; Wed, 19 Jun 2013 08:00:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3230; q=dns/txt; s=iport; t=1371654024; x=1372863624; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=JRsk7eXHiKeYSyRELmC2zVsgt9VjQRMKBBR0Dq1mtWs=; b=FxLsknJu6ek/Sk1iMNSDeutMNXFBw6QFa4TRDYo8ktCnsSSzykMiUFq6 3vcxYnEX+DPPpx8ADF6hM75r1Ez/eDnzioEOzQ6sbMAg/NSElw6o285Yi zqZp8CceGR6K9mWt5VToCpQFhaTXcv/W25xD7WDnUGtjKUczUTfQgzMwX A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnMFAJrGwVGtJV2Z/2dsb2JhbABagwkxSb8bgQAWdIIjAQEBBAEBAWsLEgEIDgoKSwslAgQBDQUIiAYMu0kEjw8CMQeDAGEDiGiLB5UWgw+CKA X-IronPort-AV: E=Sophos;i="4.87,896,1363132800"; d="scan'208";a="224906673" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-4.cisco.com with ESMTP; 19 Jun 2013 15:00:23 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r5JF0N2N028733 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 19 Jun 2013 15:00:23 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.56]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.02.0318.004; Wed, 19 Jun 2013 10:00:22 -0500 From: "Joe Hildebrand (jhildebr)" To: Tim Bray , Douglas Crockford Thread-Topic: [Json] Two Documents Thread-Index: AQHObJG5Rm5370xVp0OPDNBuVIl6G5k9bpOA//+i9AA= Date: Wed, 19 Jun 2013 15:00:22 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [10.129.24.242] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <6E38EC419DD0B0478ACA2CDF28247B13@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Matt Miller \(mamille2\)" , "json@ietf.org" Subject: Re: [Json] Two Documents X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 19 Jun 2013 15:00:31 -0000 I agree with Tim. I think we can make it crystal clear with wording and structural changes at what point a person that already has a stream of codepoints (rather than a stream of octets) starts implementing. Of course, I want to make sure we don't *prohibit* more performant processors that both decode and parse in one pass, but that won't work for JSON.parse unless ECMA allows JSON.parse to also take a typed array in addition to a string or adds JSON.parseBuffer. On 6/19/13 8:33 AM, "Tim Bray" wrote: >Let=B9s take a moment to consider who our audience is. The RFC will be >used almost exclusively by JSON parser and generator implementors. Out in >the general population of JSON users, the only docs they look at are the >docs for the parser/generator library > they=B9re using. > > >And if I=B9m an implementor writing a JSON parser or generator, well, yeah= , >I care about the abstract grammar and the security issues, but I also >care about what the incoming sequence of bytes is going to look like, and >what the outgoing sequence of bytes needs > to look like. > > >So I think it would be abusive to our customers to make them read two >documents to get their jobs done. I=B9m scratching my head to think of >anyone who would read one of these documents but not the other, and I=B9m >coming up empty. > > > -Tim > > > >On Tue, Jun 18, 2013 at 7:06 PM, Douglas Crockford > wrote: > >On 6/17/2013 5:14 PM, Matt Miller (mamille2) wrote: > >Hello Douglas, > >In order for the WG to fully understand your proposal, we need a more >definitive list of what to expect in each document. > >As a starting point, can you describe which sections of the current >RFC4627 would be in "JSON Data Interchange Format" and which would be in >the JSON best practices document? Clearly the latter will have many >additions from the recent discussions, but it is > less clear which portions of the current text goes into which document. > > > > >Please excuse the lateness of this reply. I am traveling. > >I am proposing that The JSON Data Interchange Format document contain >only the material that is universal to all applications of JSON. So, for >example, the only dependency on any character encoding is the >interpretation of the four hex digits in the \u notation, > where Unicode determines the meaning of the numbers. > >It includes an abstract, an introduction, the detailing of the elements >(object, array, string, etc), and security considerations. No parsers or >generators, no octets, no MIME types. > >This provides a standard description of JSON that all other standards and >practices may refer to. I think this is the standard that ECMA wants to >publish. > >We can then consider other documents that constrain or interpret JSON for >specific purposes. The poorly named application/json is one. JSON as a >file format, JSON as a streaming format, and JSON as an embedded data >representation are others. > >_______________________________________________ >json mailing list >json@ietf.org >https://www.ietf.org/mailman/listinfo/json > > > > > > > > --=20 Joe Hildebrand From cowan@ccil.org Wed Jun 19 08:03:39 2013 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 B5B5021F9BF3 for ; Wed, 19 Jun 2013 08:03:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.463 X-Spam-Level: X-Spam-Status: No, score=-3.463 tagged_above=-999 required=5 tests=[AWL=0.136, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PnLQyHCi3tNR for ; Wed, 19 Jun 2013 08:03:34 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id 8B00021F9CA8 for ; Wed, 19 Jun 2013 08:03:34 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1UpJv2-0005yN-MB; Wed, 19 Jun 2013 11:03:32 -0400 Date: Wed, 19 Jun 2013 11:03:32 -0400 From: John Cowan To: Tim Bray Message-ID: <20130619150332.GB24889@mercury.ccil.org> References: <51B9EA49.2050604@crockford.com> <51C1121E.8050004@crockford.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Cc: "Matt Miller \(mamille2\)" , Douglas Crockford , "json@ietf.org" Subject: Re: [Json] Two Documents X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 19 Jun 2013 15:03:39 -0000 Tim Bray scripsit: > So I think it would be abusive to our customers to make them read two > documents to get their jobs done. I’m scratching my head to think of > anyone who would read one of these documents but not the other, and I’m > coming up empty. People who are reading or writing JSON text with general editors are the obvious targets for a syntax-only document. One group would be programmers dealing with JSON literals; another would be people writing books or papers or standards that involve JSON examples. This group doesn't care about encoding or security, but I agree that they would not be injured by an RFC that contains this information, provided it is not intertwingled with the syntax. -- The first thing you learn in a lawin' family John Cowan is that there ain't no definite answers cowan@ccil.org to anything. --Calpurnia in To Kill A Mockingbird From nico@cryptonector.com Wed Jun 19 08:30:52 2013 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 B0CEC21F8F4D for ; Wed, 19 Jun 2013 08:30:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.956 X-Spam-Level: X-Spam-Status: No, score=-1.956 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UUWhn+2Ya8Bs for ; Wed, 19 Jun 2013 08:30:47 -0700 (PDT) Received: from homiemail-a30.g.dreamhost.com (caiajhbdcbef.dreamhost.com [208.97.132.145]) by ietfa.amsl.com (Postfix) with ESMTP id 3A2E921F8459 for ; Wed, 19 Jun 2013 08:30:47 -0700 (PDT) Received: from homiemail-a30.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a30.g.dreamhost.com (Postfix) with ESMTP id A756421DE7D for ; Wed, 19 Jun 2013 08:30:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=F5K96nWR0Q5lJGI8JBR8ps/ZnGA=; b=beCLx0t8NKD w679sIaJfVwC27K7nTYWJXBvKQkVw3HLNEPzwaUhS1M+nL8iHD/PyrXJXNJl9tu5 XY4cO8aDD0ysYLArk2TuoNQ2f5CTectTp2TRj2d9g4hTNIRpMSw4rlQRgQ6oi3dR IGNl+Swng3CjPxVfoZVZhmnFsllI9Uks= Received: from mail-we0-f171.google.com (mail-we0-f171.google.com [74.125.82.171]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a30.g.dreamhost.com (Postfix) with ESMTPSA id 0B4C221DE71 for ; Wed, 19 Jun 2013 08:30:45 -0700 (PDT) Received: by mail-we0-f171.google.com with SMTP id m46so4562712wev.2 for ; Wed, 19 Jun 2013 08:30:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=IfLFykO2+1nil6kazgTpm+OpX0EyIFFebjFpX9P/SEc=; b=Dg8zLgThPRVIm75U5bY/SmuIRpNynBhwSc/r8NDVHDum5j5bBLmHWhUrt8zdotvqyX T1gBK8DqBtgTlLBJjFhCKN6QeFxkzJCth+2Izu0N4lfATo8GEcTq8/fMLIXDOxOxbeaP 0vlVC9ptr4RCN7ZyliQ9oXxKi6ENXwuoc2uv/zydePCxyKL7m+fOgTrEz1TqPgVdZgrn JuATFWJiGD5etB4CN1Vcw5jGJJgGV9EoTeZjpgQcAR224uRH/Ua64ig3AkxqwkshDZeL VW9uMUe+RYZfy9walIrTa+msKNX3sDc9qybq3dY5nqv41k1DEg3thtssFZ3CsO7SR4qK IXhg== MIME-Version: 1.0 X-Received: by 10.180.75.144 with SMTP id c16mr406361wiw.1.1371655844194; Wed, 19 Jun 2013 08:30:44 -0700 (PDT) Received: by 10.216.29.5 with HTTP; Wed, 19 Jun 2013 08:30:44 -0700 (PDT) In-Reply-To: References: <51B9EA49.2050604@crockford.com> <51C1121E.8050004@crockford.com> Date: Wed, 19 Jun 2013 10:30:44 -0500 Message-ID: From: Nico Williams To: Tim Bray Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "Matt Miller \(mamille2\)" , Douglas Crockford , "json@ietf.org" Subject: Re: [Json] Two Documents X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 19 Jun 2013 15:30:52 -0000 On Wed, Jun 19, 2013 at 9:33 AM, Tim Bray wrote: > Let=E2=80=99s take a moment to consider who our audience is. The RFC wil= l be used > almost exclusively by JSON parser and generator implementors. [...] +1. I'd be OK with separating a description of JSON from any text talking about parsers and encoders, but all of that should be in the main doc. (Remember, we already have a second doc: the best practices doc.) From petejson@codalogic.com Wed Jun 19 08:37:06 2013 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 63E8221F9CC9 for ; Wed, 19 Jun 2013 08:37:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.743 X-Spam-Level: * X-Spam-Status: No, score=1.743 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_50=0.001, SARE_HEAD_XUNSENT=1.666, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id grRBw6ZgHY7I for ; Wed, 19 Jun 2013 08:37:01 -0700 (PDT) Received: from codalogic.com (codalogic.com [94.136.60.219]) by ietfa.amsl.com (Postfix) with ESMTP id EBA5121F9CE7 for ; Wed, 19 Jun 2013 08:36:58 -0700 (PDT) Received: (qmail 19860 invoked from network); 19 Jun 2013 16:36:57 +0100 Received: from host86-169-212-62.range86-169.btcentralplus.com (HELO codalogic) (86.169.212.62) by codalogic.com with (RC4-MD5 encrypted) SMTP; 19 Jun 2013 16:36:57 +0100 Message-ID: <2E8AF23771284CF0BE394DBFF12DEB80@codalogic> From: "Pete Cordell" To: "Tim Bray" X-Unsent: 1 References: <51B9EA49.2050604@crockford.com><51C1121E.8050004@crockford.com> x-vipre-scanned: 01A7FB000049A801A7FC4D Date: Wed, 19 Jun 2013 16:37:03 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Cc: json@ietf.org Subject: Re: [Json] Two Documents X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 19 Jun 2013 15:37:06 -0000 Original Message From: "Tim Bray" > So I think it would be abusive to our customers to make them read two > documents to get their jobs done. I’m scratching my head to think of > anyone who would read one of these documents but not the other, and I’m > coming up empty. My feeling is that the current JSON spec has warts, largely due to ambiguity, that many of us would like to see resolved, but by the nature of backwards compatibility we can't fix them with a one document strategy. I'm musing that what I'd ideally like to see is a document to describe JSON as it currently is, warts and all, in a document called "The JSON Data Interchange Format". As much as anything this would highlight ambiguities in the current spec, but not necessarily resolve them. Then have a separate spec named along the lines of "The Good JSON Data Interchange Format" that has a structure similar to the first, but has wording along the lines of "A good JSON parser MUST..." etc. Hopefully the second one can be effectively JSONbis and a single document source for anybody that wants to go that route, and is also less ignorable than an informational BCP for those that like to cut corners on implementation. Pete Cordell Codalogic Ltd C++ tools for C++ programmers, http://codalogic.com Read & write XML in C++, http://www.xml2cpp.com From cabo@tzi.org Wed Jun 19 09:14:41 2013 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 8665021F9DA9 for ; Wed, 19 Jun 2013 09:14:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.201 X-Spam-Level: X-Spam-Status: No, score=-106.201 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TyljOnPxag1w for ; Wed, 19 Jun 2013 09:14:35 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id C2FE321F9DA6 for ; Wed, 19 Jun 2013 09:14:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r5JGER5n023521; Wed, 19 Jun 2013 18:14:27 +0200 (CEST) Received: from [192.168.217.105] (p54893A31.dip0.t-ipconnect.de [84.137.58.49]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id B94543BEB; Wed, 19 Jun 2013 18:14:26 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann X-Priority: 3 In-Reply-To: <2E8AF23771284CF0BE394DBFF12DEB80@codalogic> Date: Wed, 19 Jun 2013 18:14:25 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <2F8332EF-4FE5-43CF-AFA6-D3BACEC11D55@tzi.org> References: <51B9EA49.2050604@crockford.com><51C1121E.8050004@crockford.com> <2E8AF23771284CF0BE394DBFF12DEB80@codalogic> To: "Pete Cordell" X-Mailer: Apple Mail (2.1508) Cc: Tim Bray , json@ietf.org Subject: Re: [Json] Two Documents X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 19 Jun 2013 16:14:41 -0000 On Jun 19, 2013, at 17:37, "Pete Cordell" = wrote: > can't fix them with a one document strategy It is still possible to have a section with behavior that the spec = accepts as legacy but doesn't approve of. Concentrate it into a section so the rest stays readable without a = million exceptions. Cf. the "BWS" (bad white space) in HTTPbis: BWS is used where the grammar allows optional whitespace, for historical reasons, but senders SHOULD NOT generate it in messages; recipients MUST accept such bad optional whitespace and remove it before interpreting the field value or forwarding the message downstream. This is quite different from "best practices" in that it is a = legacy-based addition to the accepted set, not a restriction of the = accepted set based on some "best practices". Not part of the desirable spec Allowed by the desirable spec | _______________ | / | \ /| / / | \ Best / | / Practices / | \ /Barf| / \ bag| \ \___| \ | \_____________ | The main part of the normative spec would describe the vertical line. That special section with legacy behavior we can't get rid of in the = normative spec is marked "Barf bag" for brevity above. The "best practices" are over in desired land, but way more restricted. Gr=FC=DFe, Carsten From paul.hoffman@vpnc.org Fri Jun 21 09:38:48 2013 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 694CD11E81A3 for ; Fri, 21 Jun 2013 09:38:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.518 X-Spam-Level: X-Spam-Status: No, score=-102.518 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vZf500ZoLzuA for ; Fri, 21 Jun 2013 09:38:48 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id EEDA211E81A0 for ; Fri, 21 Jun 2013 09:38:47 -0700 (PDT) Received: from [10.20.30.90] (50-0-66-165.dsl.dynamic.sonic.net [50.0.66.165]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r5LGcjOr040486 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 21 Jun 2013 09:38:45 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) From: Paul Hoffman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <90B659B8-D4AC-41AF-8C06-67FC65C8BD74@vpnc.org> Date: Fri, 21 Jun 2013 09:38:45 -0700 To: JSON WG Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) Subject: [Json] Consensus call: document title X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 21 Jun 2013 16:38:48 -0000 There are three proposals for dealing with the document title: 0) Leave the title in the current draft as-is: The application/json Media Type for JavaScript Object Notation = (JSON) 1) Change the title to The JSON Data Interchange Format 2) Change the title to The JSON Format for Encoding Data Please respond to this message with a list of proposals you could = accept, ordered from highest to lowest. Do not list proposals you cannot = live with. If you cannot accept any of the proposals, please respond and = say why. Based on the responses we receive, we will try to judge the consensus of = the WG. -- The JSON WG co-chairs= From paul.hoffman@vpnc.org Fri Jun 21 09:40:17 2013 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 E360D11E81A2 for ; Fri, 21 Jun 2013 09:40:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.219 X-Spam-Level: X-Spam-Status: No, score=-102.219 tagged_above=-999 required=5 tests=[AWL=-0.220, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9mdca3d0wEav for ; Fri, 21 Jun 2013 09:40:17 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 5B1AD11E8193 for ; Fri, 21 Jun 2013 09:40:17 -0700 (PDT) Received: from [10.20.30.90] (50-0-66-165.dsl.dynamic.sonic.net [50.0.66.165]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r5LGeGu6040529 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 21 Jun 2013 09:40:17 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) From: Paul Hoffman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <9E497099-2B5B-4256-B066-C2E77B558267@vpnc.org> Date: Fri, 21 Jun 2013 09:40:17 -0700 To: JSON WG Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) Subject: [Json] Consensus call: ABNF nits X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 21 Jun 2013 16:40:18 -0000 There are two proposals for dealing with nits in the ABNF: 0) Leave the ABNF in the current draft as-is 1) Change the ABNF in the draft to use the values in "Proposal 1" = below Note that later proposals might make technical changes to the ABNF = itself; those proposals are not what we are discussing in this consensus = call. Please respond to this message with a list of proposals you could = accept, ordered from highest to lowest. Do not list proposals you cannot = live with. If you cannot accept any of the proposals, please respond and = say why. Based on the responses we receive, we will try to judge the consensus of = the WG. -- The JSON WG co-chairs Proposal #1 Note that this ABNF is sprinkled throughout Section 2 of = draft-ietf-json-rfc4627bis-02. Each section below replaces the similar section in the draft. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D JSON-text =3D object / array begin-array =3D ws %x5B ws ; [ left square bracket begin-object =3D ws %x7B ws ; { left curly bracket end-array =3D ws %x5D ws ; ] right square bracket end-object =3D ws %x7D ws ; } right curly bracket name-separator =3D ws %x3A ws ; : colon value-separator =3D ws %x2C ws ; , comma ws =3D *( %x20 / ; Space %x09 / ; Horizontal tab %x0A / ; Line feed or New line %x0D ; Carriage return ) value =3D false / null / true / object / array / number / string false =3D %x66.61.6c.73.65 ; false null =3D %x6e.75.6c.6c ; null true =3D %x74.72.75.65 ; true object =3D begin-object [ member *( value-separator member ) ] end-object member =3D string name-separator value array =3D begin-array [ value *( value-separator value ) ] end-array number =3D [ minus ] int [ frac ] [ exp ] decimal-point =3D %x2E ; . digit1-9 =3D %x31-39 ; 1-9 e =3D %x65 / %x45 ; e E exp =3D e [ minus / plus ] 1*DIGIT frac =3D decimal-point 1*DIGIT int =3D zero / ( digit1-9 *DIGIT ) minus =3D %x2D ; - plus =3D %x2B ; + zero =3D %x30 ; 0 DIGIT =3D %x30-39 ; 0-9 ; DIGIT equivalent to DIGIT rule in [RFC5234] string =3D quotation-mark *char quotation-mark char =3D unescaped / ( escape ( %x22 / ; " quotation mark U+0022 %x5C / ; \ reverse solidus U+005C %x2F / ; / solidus U+002F %x62 / ; b backspace U+0008 %x66 / ; f form feed U+000C %x6E / ; n line feed U+000A %x72 / ; r carriage return U+000D %x74 / ; t tab U+0009 %x75 4HEXDIG ) ) ; uXXXX U+XXXX escape =3D %x5C ; \ U+005C quotation-mark =3D %x22 ; " U+0022 unescaped =3D %x20-21 / %x23-5B / %x5D-10FFFF ; any Unicode scalar ; value, except those that must be escaped (C0 control ; characters, "QUOTATION MARK" [U+0022], and "REVERSE SOLIDUS" ; [U+005C]) HEXDIG =3D DIGIT / %x41-46 / %x61-66 ; 0-9, A-F, or a-f ; HEXDIG equivalent to HEXDIG rule in [RFC5234]= From paul.hoffman@vpnc.org Fri Jun 21 09:42:08 2013 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 73F9321F9EB2 for ; Fri, 21 Jun 2013 09:42:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.516 X-Spam-Level: X-Spam-Status: No, score=-102.516 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id il+Brs4vpKM3 for ; Fri, 21 Jun 2013 09:42:08 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id EA90721F9A41 for ; Fri, 21 Jun 2013 09:42:07 -0700 (PDT) Received: from [10.20.30.90] (50-0-66-165.dsl.dynamic.sonic.net [50.0.66.165]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r5LGg6rC040567 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 21 Jun 2013 09:42:07 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) From: Paul Hoffman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: Date: Fri, 21 Jun 2013 09:42:07 -0700 To: JSON WG Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) Subject: [Json] Consensus call: establishing name equality X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 21 Jun 2013 16:42:08 -0000 There are four proposals for establishing name equality: 0) Leave the current draft as-is, not discussing name equality 1) In Section 2.5 ("Strings"), immediately before the ABNF add: For purpose of establishing name equality, comparisons MUST be = conducted, after all unescaping is done, by comparing numeric character code points. There is to be = no modification of any kind to the characters in names, including case-changing or = combining-form normalization. For example, the following four names MUST be considered equivalent: * "\u002F" * "\u002f" * "\/" * "/" 2) In Section 2.5 ("Strings"), immediately before the ABNF add: For purpose of establishing name equality, comparisons MUST be = conducted, after all unescaping is done, by comparing numeric character code points. There MUST NOT = be any modification of any kind to the characters in names, including change of case or change = between precomposed and decomposed forms. For example, the following four names MUST be considered equivalent: * "\u002F" * "\u002f" * "\/" * "/" 3) In Section 2.5 ("Strings"), immediately before the ABNF add: For purpose of establishing name equality, implementations MUST first = do all unescaping and then MUST compare numeric character code points. There is to be no = modification of any kind to the characters in names, including case-changing or combining-form = normalization. For example, the following four names MUST be considered equivalent: * "\u002F" * "\u002f" * "\/" * "/" Please respond to this message with a list of proposals you could = accept, ordered from highest to lowest. Do not list proposals you cannot = live with. If you cannot accept any of the proposals, please respond and = say why. Based on the responses we receive, we will try to judge the consensus of = the WG. -- The JSON WG co-chairs From cowan@ccil.org Fri Jun 21 09:55:49 2013 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 B9B5D21F9E97 for ; Fri, 21 Jun 2013 09:55:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.465 X-Spam-Level: X-Spam-Status: No, score=-3.465 tagged_above=-999 required=5 tests=[AWL=0.134, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l5IRSBdwPCFM for ; Fri, 21 Jun 2013 09:55:45 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id 627A721F9D71 for ; Fri, 21 Jun 2013 09:55:45 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1Uq4ch-0005bQ-T9 for json@ietf.org; Fri, 21 Jun 2013 12:55:43 -0400 Date: Fri, 21 Jun 2013 12:55:43 -0400 From: John Cowan To: JSON WG Message-ID: <20130621165543.GM5861@mercury.ccil.org> References: <90B659B8-D4AC-41AF-8C06-67FC65C8BD74@vpnc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <90B659B8-D4AC-41AF-8C06-67FC65C8BD74@vpnc.org> User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Subject: Re: [Json] Consensus call: document title X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 21 Jun 2013 16:55:49 -0000 Paul Hoffman scripsit: > There are three proposals for dealing with the document title: > 0) Leave the title in the current draft as-is: > The application/json Media Type for JavaScript Object Notation (JSON) > 1) Change the title to > The JSON Data Interchange Format > 2) Change the title to > The JSON Format for Encoding Data 1, 2 -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org "After all, would you consider a man without honor wealthy, even if his Dinar laid end to end would reach from here to the Temple of Toplat?" "No, I wouldn't", the beggar replied. "Why is that?" the Master asked. "A Dinar doesn't go very far these days, Master. --Kehlog Albran Besides, the Temple of Toplat is across the street." The Profit From tbray@textuality.com Fri Jun 21 09:58:41 2013 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 E1E0A21F9EA7 for ; Fri, 21 Jun 2013 09:58:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.709 X-Spam-Level: X-Spam-Status: No, score=0.709 tagged_above=-999 required=5 tests=[AWL=-1.248, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c57sAqWdm2qU for ; Fri, 21 Jun 2013 09:58:37 -0700 (PDT) Received: from mail-ve0-x232.google.com (mail-ve0-x232.google.com [IPv6:2607:f8b0:400c:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id 92EE421F9E21 for ; Fri, 21 Jun 2013 09:58:37 -0700 (PDT) Received: by mail-ve0-f178.google.com with SMTP id pb11so6592529veb.23 for ; Fri, 21 Jun 2013 09:58:37 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=rahBC+jsgm68AAfFrga0iIli4qDnwCyorx2nFY/5P58=; b=hGHRPMqx4RjxAi3iUl2MuEWCcliG2v/VjPkdH/pazMINFBf9QichJzlLvWBFooNzzl 11tEDnj/bk3PRGDphF1zQxyOEDNW6MF45bdwi49cvbaHnjJgfjNbJIx82vh7tBe1XzlL wHVqjaqSfqt4LjOTlsW8j+ktTazEBTN111Pv0g5LL+7DlyfTZXtz5THRZ4fQ5QXQSyb3 G9hseHR9gVdqhFooNDo09+kOzNGkXIOCK5+4NlwBPfVdIYupmtJomeV4L4maMVXom/6Z 4Atgl3AQqmNOoZ2QTF9CXO4cwDMK7Kl6NsX9Sp1fuUaOdoud/MnsnV0BIuANF8W+WcuS ZV/w== MIME-Version: 1.0 X-Received: by 10.220.162.70 with SMTP id u6mr5984039vcx.11.1371833916841; Fri, 21 Jun 2013 09:58:36 -0700 (PDT) Received: by 10.220.219.200 with HTTP; Fri, 21 Jun 2013 09:58:36 -0700 (PDT) X-Originating-IP: [24.84.235.32] In-Reply-To: <9E497099-2B5B-4256-B066-C2E77B558267@vpnc.org> References: <9E497099-2B5B-4256-B066-C2E77B558267@vpnc.org> Date: Fri, 21 Jun 2013 09:58:36 -0700 Message-ID: From: Tim Bray To: Paul Hoffman Content-Type: multipart/alternative; boundary=001a11c21b384df17704dfacf965 X-Gm-Message-State: ALoCoQmau5/zDvnhUJ2T3xPi9rO7Fe1UBIOPGVtU13OTxO9dnVAFv1OJ/E5lcES3OH0KL0hmtzyV Cc: JSON WG Subject: Re: [Json] Consensus call: ABNF nits X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 21 Jun 2013 16:58:42 -0000 --001a11c21b384df17704dfacf965 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I=E2=80=99m OK with #1, the revision. It=E2=80=99s a considerable improveme= nt, and thanks to the people who did the unglamorous revision work. -T On Fri, Jun 21, 2013 at 9:40 AM, Paul Hoffman wrote= : > There are two proposals for dealing with nits in the ABNF: > 0) Leave the ABNF in the current draft as-is > 1) Change the ABNF in the draft to use the values in "Proposal 1" below > Note that later proposals might make technical changes to the ABNF itself= ; > those proposals are not what we are discussing in this consensus call. > > Please respond to this message with a list of proposals you could accept, > ordered from highest to lowest. Do not list proposals you cannot live wit= h. > If you cannot accept any of the proposals, please respond and say why. > > Based on the responses we receive, we will try to judge the consensus of > the WG. > > -- The JSON WG co-chairs > > Proposal #1 > Note that this ABNF is sprinkled throughout Section 2 of > draft-ietf-json-rfc4627bis-02. Each > section below replaces the similar section in the draft. > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > JSON-text =3D object / array > > begin-array =3D ws %x5B ws ; [ left square bracket > begin-object =3D ws %x7B ws ; { left curly bracket > end-array =3D ws %x5D ws ; ] right square bracket > end-object =3D ws %x7D ws ; } right curly bracket > name-separator =3D ws %x3A ws ; : colon > value-separator =3D ws %x2C ws ; , comma > > ws =3D *( > %x20 / ; Space > %x09 / ; Horizontal tab > %x0A / ; Line feed or New line > %x0D ; Carriage return > ) > > value =3D false / null / true / object / array / number / string > false =3D %x66.61.6c.73.65 ; false > null =3D %x6e.75.6c.6c ; null > true =3D %x74.72.75.65 ; true > > object =3D begin-object [ member *( value-separator member ) ] > end-object > member =3D string name-separator value > > array =3D begin-array [ value *( value-separator value ) ] end-array > > number =3D [ minus ] int [ frac ] [ exp ] > decimal-point =3D %x2E ; . > digit1-9 =3D %x31-39 ; 1-9 > e =3D %x65 / %x45 ; e E > exp =3D e [ minus / plus ] 1*DIGIT > frac =3D decimal-point 1*DIGIT > int =3D zero / ( digit1-9 *DIGIT ) > minus =3D %x2D ; - > plus =3D %x2B ; + > zero =3D %x30 ; 0 > DIGIT =3D %x30-39 ; 0-9 > ; DIGIT equivalent to DIGIT rule in [RFC5234] > > string =3D quotation-mark *char quotation-mark > char =3D unescaped / ( > escape ( > %x22 / ; " quotation mark U+0022 > %x5C / ; \ reverse solidus U+005C > %x2F / ; / solidus U+002F > %x62 / ; b backspace U+0008 > %x66 / ; f form feed U+000C > %x6E / ; n line feed U+000A > %x72 / ; r carriage return U+000D > %x74 / ; t tab U+0009 > %x75 4HEXDIG ) ) ; uXXXX U+XXXX > escape =3D %x5C ; \ U+005C > quotation-mark =3D %x22 ; " U+0022 > unescaped =3D %x20-21 / %x23-5B / %x5D-10FFFF ; any Unicode scalar > ; value, except those that must be escaped (C0 control > ; characters, "QUOTATION MARK" [U+0022], and "REVERSE SOLIDUS" > ; [U+005C]) > HEXDIG =3D DIGIT / %x41-46 / %x61-66 ; 0-9, A-F, or a-f > ; HEXDIG equivalent to HEXDIG rule in [RFC5234] > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > --001a11c21b384df17704dfacf965 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I=E2=80=99m OK with #1, the revision. It=E2=80=99s a consi= derable improvement, and thanks to the people who did the unglamorous revis= ion work.=C2=A0 -T


On Fri, Jun 21, 2013 at 9:40 AM, Paul Hoffman <paul.h= offman@vpnc.org> wrote:
There are two proposals for dealing with nit= s in the ABNF:
=C2=A0 0) Leave the ABNF in the current draft as-is
=C2=A0 1) Change the ABNF in the draft to use the values in "Proposal = 1" below
Note that later proposals might make technical changes to the ABNF itself; = those proposals are not what we are discussing in this consensus call.

Please respond to this message with a list of proposals you could accept, o= rdered from highest to lowest. Do not list proposals you cannot live with. = If you cannot accept any of the proposals, please respond and say why.

Based on the responses we receive, we will try to judge the consensus of th= e WG.

-- The JSON WG co-chairs

Proposal #1
Note that this ABNF is sprinkled throughout Section 2 of draft-ietf-json-rf= c4627bis-02. Each
section below replaces the similar section in the draft.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

JSON-text =3D object / array

begin-array =C2=A0 =C2=A0 =3D ws %x5B ws =C2=A0; [ left square bracket
begin-object =C2=A0 =C2=A0=3D ws %x7B ws =C2=A0; { left curly bracket
end-array =C2=A0 =C2=A0 =C2=A0 =3D ws %x5D ws =C2=A0; ] right square bracke= t
end-object =C2=A0 =C2=A0 =C2=A0=3D ws %x7D ws =C2=A0; } right curly bracket=
name-separator =C2=A0=3D ws %x3A ws =C2=A0; : colon
value-separator =3D ws %x2C ws =C2=A0; , comma

ws =3D *(
=C2=A0 =C2=A0 =C2=A0%x20 / =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= ; Space
=C2=A0 =C2=A0 =C2=A0%x09 / =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= ; Horizontal tab
=C2=A0 =C2=A0 =C2=A0%x0A / =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= ; Line feed or New line
=C2=A0 =C2=A0 =C2=A0%x0D =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0; Carriage return
=C2=A0 =C2=A0 =C2=A0)

value =3D false / null / true / object / array / number / string
false =3D %x66.61.6c.73.65 =C2=A0 ; false
null =C2=A0=3D %x6e.75.6c.6c =C2=A0 =C2=A0 =C2=A0; null
true =C2=A0=3D %x74.72.75.65 =C2=A0 =C2=A0 =C2=A0; true

object =3D begin-object [ member *( value-separator member ) ]
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0end-object
member =3D string name-separator value

array =3D begin-array [ value *( value-separator value ) ] end-array

number =3D [ minus ] int [ frac ] [ exp ]
decimal-point =3D %x2E =C2=A0 =C2=A0 =C2=A0 ; .
digit1-9 =3D %x31-39 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ; 1-9
e =3D %x65 / %x45 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0; e E
exp =3D e [ minus / plus ] 1*DIGIT
frac =3D decimal-point 1*DIGIT
int =3D zero / ( digit1-9 *DIGIT )
minus =3D %x2D =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ; -
plus =3D %x2B =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0; + zero =3D %x30 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0; 0 DIGIT =3D %x30-39 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0; 0-9
=C2=A0 =C2=A0 =C2=A0 ; DIGIT equivalent to DIGIT rule in [RFC5234]

string =3D quotation-mark *char quotation-mark
char =3D unescaped / (
=C2=A0 =C2=A0 escape (
=C2=A0 =C2=A0 =C2=A0 =C2=A0 %x22 / =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ; &qu= ot; =C2=A0 =C2=A0quotation mark =C2=A0U+0022
=C2=A0 =C2=A0 =C2=A0 =C2=A0 %x5C / =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ; \ = =C2=A0 =C2=A0reverse solidus U+005C
=C2=A0 =C2=A0 =C2=A0 =C2=A0 %x2F / =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ; / = =C2=A0 =C2=A0solidus =C2=A0 =C2=A0 =C2=A0 =C2=A0 U+002F
=C2=A0 =C2=A0 =C2=A0 =C2=A0 %x62 / =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ; b = =C2=A0 =C2=A0backspace =C2=A0 =C2=A0 =C2=A0 U+0008
=C2=A0 =C2=A0 =C2=A0 =C2=A0 %x66 / =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ; f = =C2=A0 =C2=A0form feed =C2=A0 =C2=A0 =C2=A0 U+000C
=C2=A0 =C2=A0 =C2=A0 =C2=A0 %x6E / =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ; n = =C2=A0 =C2=A0line feed =C2=A0 =C2=A0 =C2=A0 U+000A
=C2=A0 =C2=A0 =C2=A0 =C2=A0 %x72 / =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ; r = =C2=A0 =C2=A0carriage return U+000D
=C2=A0 =C2=A0 =C2=A0 =C2=A0 %x74 / =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ; t = =C2=A0 =C2=A0tab =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 U+0009
=C2=A0 =C2=A0 =C2=A0 =C2=A0 %x75 4HEXDIG ) ) ; uXXXX =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0U+XXXX
escape =3D %x5C =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0; \ =C2=A0U= +005C
quotation-mark =3D %x22 =C2=A0 =C2=A0 =C2=A0; " =C2=A0U+0022
unescaped =3D %x20-21 / %x23-5B / %x5D-10FFFF =C2=A0; any Unicode scalar =C2=A0 =C2=A0; value, except those that must be escaped (C0 control
=C2=A0 =C2=A0; characters, "QUOTATION MARK" [U+0022], and "R= EVERSE SOLIDUS"
=C2=A0 =C2=A0; [U+005C])
HEXDIG =3D DIGIT / %x41-46 / %x61-66 =C2=A0 ; 0-9, A-F, or a-f
=C2=A0 =C2=A0 =C2=A0 =C2=A0; HEXDIG equivalent to HEXDIG rule in [RFC5234]<= br> _______________________________________________
json mailing list
json@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/json

--001a11c21b384df17704dfacf965-- From tbray@textuality.com Fri Jun 21 10:02:09 2013 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 6694521F9E21 for ; Fri, 21 Jun 2013 10:02:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.493 X-Spam-Level: X-Spam-Status: No, score=0.493 tagged_above=-999 required=5 tests=[AWL=-0.864, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NfIZJbJigwal for ; Fri, 21 Jun 2013 10:02:05 -0700 (PDT) Received: from mail-vc0-x229.google.com (mail-vc0-x229.google.com [IPv6:2607:f8b0:400c:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id 4765121F9DBA for ; Fri, 21 Jun 2013 10:02:02 -0700 (PDT) Received: by mail-vc0-f169.google.com with SMTP id ia10so42094vcb.0 for ; Fri, 21 Jun 2013 10:02:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=q+xg/NmkHnGk+28KHZsCOXisJYORnNV3UkAhaueTciM=; b=YloZuUzpE0FbuzXdXfYUBaF+zkGv2pC6KAp8et/2G2RG2hqOQ5hj/LBmzAV8OR03t2 ohDQ2Z8Yl5SUmxU8IWEllsGqMdDHQT6TC9vtYjqNVAZm8AIDyyORT0zWtBQD2kDdQTcJ 38jKnFtEAMth7UZ22dgx2c25J4pgCcOjrkqkbPVE3bu/Eumv0BBZi+hjKxIpZB2z69nv iLN4xuK49GvbfBBp6Yz4AY1PqDb8c/pmRbNYvjpqlOj8j9FxJ+ZoLYkHNUIN9wt2D/PW RpvlDGRt+aRpi6kIEICWmfDrQ4+mLTkrH5XEiFHHP/RSlsSTyBUVxDiDkTLwhT0Q4RSF YWWA== MIME-Version: 1.0 X-Received: by 10.58.180.102 with SMTP id dn6mr6309430vec.79.1371834121650; Fri, 21 Jun 2013 10:02:01 -0700 (PDT) Received: by 10.220.219.200 with HTTP; Fri, 21 Jun 2013 10:02:01 -0700 (PDT) X-Originating-IP: [24.84.235.32] In-Reply-To: References: Date: Fri, 21 Jun 2013 10:02:01 -0700 Message-ID: From: Tim Bray To: Paul Hoffman Content-Type: multipart/alternative; boundary=047d7b5d853183129104dfad05ca X-Gm-Message-State: ALoCoQmAgCvbCyWnfPFdQheLF25uJXiTvlrWv2j8tWYwIlBlopSeTqYfHZYY3uxIoSTxCsGHF8Ws Cc: JSON WG Subject: Re: [Json] Consensus call: establishing name equality X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 21 Jun 2013 17:02:09 -0000 --047d7b5d853183129104dfad05ca Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable #1 and #3 only differ at the editorial-nit level; I=E2=80=99m equally fine = with either. -T On Fri, Jun 21, 2013 at 9:42 AM, Paul Hoffman wrote= : > There are four proposals for establishing name equality: > > 0) Leave the current draft as-is, not discussing name equality > > 1) In Section 2.5 ("Strings"), immediately before the ABNF add: > For purpose of establishing name equality, comparisons MUST be > conducted, after all unescaping > is done, by comparing numeric character code points. There is to be no > modification of any > kind to the characters in names, including case-changing or > combining-form normalization. > For example, the following four names MUST be considered equivalent: > * "\u002F" > * "\u002f" > * "\/" > * "/" > > 2) In Section 2.5 ("Strings"), immediately before the ABNF add: > For purpose of establishing name equality, comparisons MUST be > conducted, after all unescaping > is done, by comparing numeric character code points. There MUST NOT be > any modification of any > kind to the characters in names, including change of case or change > between precomposed and > decomposed forms. > For example, the following four names MUST be considered equivalent: > * "\u002F" > * "\u002f" > * "\/" > * "/" > > 3) In Section 2.5 ("Strings"), immediately before the ABNF add: > For purpose of establishing name equality, implementations MUST first > do all unescaping and > then MUST compare numeric character code points. There is to be no > modification of any kind to > the characters in names, including case-changing or combining-form > normalization. > For example, the following four names MUST be considered equivalent: > * "\u002F" > * "\u002f" > * "\/" > * "/" > > Please respond to this message with a list of proposals you could accept, > ordered from highest to lowest. Do not list proposals you cannot live wit= h. > If you cannot accept any of the proposals, please respond and say why. > > Based on the responses we receive, we will try to judge the consensus of > the WG. > > -- The JSON WG co-chairs > > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > --047d7b5d853183129104dfad05ca Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
#1 and #3 only differ at the editorial-nit level; I=E2=80= =99m equally fine with either.=C2=A0 -T


On Fri, Jun 21, 2013 at 9:42 AM, Paul H= offman <paul.hoffman@vpnc.org> wrote:
There are four proposals for establishing na= me equality:

0) Leave the current draft as-is, not discussing name equality

1) In Section 2.5 ("Strings"), immediately before the ABNF add: =C2=A0 =C2=A0For purpose of establishing name equality, comparisons MUST be= conducted, after all unescaping
=C2=A0 =C2=A0is done, by comparing numeric character code points. There is = to be no modification of any
=C2=A0 =C2=A0kind to the characters in names, including case-changing or co= mbining-form normalization.
=C2=A0 =C2=A0For example, the following four names MUST be considered equiv= alent:
=C2=A0 =C2=A0 * "\u002F"
=C2=A0 =C2=A0 * "\u002f"
=C2=A0 =C2=A0 * "\/"
=C2=A0 =C2=A0 * "/"

2) In Section 2.5 ("Strings"), immediately before the ABNF add: =C2=A0 =C2=A0For purpose of establishing name equality, comparisons MUST be= conducted, after all unescaping
=C2=A0 =C2=A0is done, by comparing numeric character code points. There MUS= T NOT be any modification of any
=C2=A0 =C2=A0kind to the characters in names, including change of case or c= hange between precomposed and
=C2=A0 =C2=A0decomposed forms.
=C2=A0 =C2=A0For example, the following four names MUST be considered equiv= alent:
=C2=A0 =C2=A0 * "\u002F"
=C2=A0 =C2=A0 * "\u002f"
=C2=A0 =C2=A0 * "\/"
=C2=A0 =C2=A0 * "/"

3) In Section 2.5 ("Strings"), immediately before the ABNF add: =C2=A0 =C2=A0For purpose of establishing name equality, implementations MUS= T first do all unescaping and
=C2=A0 =C2=A0then MUST compare numeric character code points. There is to b= e no modification of any kind to
=C2=A0 =C2=A0the characters in names, including case-changing or combining-= form normalization.
=C2=A0 =C2=A0For example, the following four names MUST be considered equiv= alent:
=C2=A0 =C2=A0 * "\u002F"
=C2=A0 =C2=A0 * "\u002f"
=C2=A0 =C2=A0 * "\/"
=C2=A0 =C2=A0 * "/"

Please respond to this message with a list of proposals you could accept, o= rdered from highest to lowest. Do not list proposals you cannot live with. = If you cannot accept any of the proposals, please respond and say why.

Based on the responses we receive, we will try to judge the consensus of th= e WG.

-- The JSON WG co-chairs


_______________________________________________
json mailing list
json@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/json

--047d7b5d853183129104dfad05ca-- From tbray@textuality.com Fri Jun 21 10:02:41 2013 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 5EB4C21F9EAA for ; Fri, 21 Jun 2013 10:02:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.547 X-Spam-Level: X-Spam-Status: No, score=0.547 tagged_above=-999 required=5 tests=[AWL=-0.810, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vx5-giNqGxq4 for ; Fri, 21 Jun 2013 10:02:37 -0700 (PDT) Received: from mail-vb0-x232.google.com (mail-vb0-x232.google.com [IPv6:2607:f8b0:400c:c02::232]) by ietfa.amsl.com (Postfix) with ESMTP id C625521F9E5B for ; Fri, 21 Jun 2013 10:02:36 -0700 (PDT) Received: by mail-vb0-f50.google.com with SMTP id w16so6107505vbb.37 for ; Fri, 21 Jun 2013 10:02:36 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=T5DVQvQ1Rfho4SsJcrospyCswrx5izX/5MJiv1K6yjM=; b=dXbYzLR5N0o1fez9TUia8hrcUVZQbGbte1XKm2HqJ/8uYH6BCsx83bWoZPmNuL7UMV QMOQRDTvF+t37BVG4VvFTbOL2EwTpN+iIT4IPV7LJEOs8ZcE3vgvQg45hbJ/mB06cNIH nhrHyWldNxn/nXEctuhE6idM8ZshtyzTe2x3VXNXdcaeHSlXyDQ+fxjGiJQDHaupKIF+ hrE4l2jHf5GwFaL0D5HbubtjjYSJRDxWlKdi91JCS1/wau6d5lTITAxG2Q8zLh1mx0tc 4JePnnJMA2G4b/mbJrzbWYsOsPciExcIt6jtNl2Hj9MyTt5G9mK3PjHcrRSrnNQyVOvJ zgSA== MIME-Version: 1.0 X-Received: by 10.58.187.232 with SMTP id fv8mr6331444vec.50.1371834156165; Fri, 21 Jun 2013 10:02:36 -0700 (PDT) Received: by 10.220.219.200 with HTTP; Fri, 21 Jun 2013 10:02:35 -0700 (PDT) X-Originating-IP: [24.84.235.32] In-Reply-To: <90B659B8-D4AC-41AF-8C06-67FC65C8BD74@vpnc.org> References: <90B659B8-D4AC-41AF-8C06-67FC65C8BD74@vpnc.org> Date: Fri, 21 Jun 2013 10:02:35 -0700 Message-ID: From: Tim Bray To: Paul Hoffman Content-Type: multipart/alternative; boundary=047d7b6dc4a091bee104dfad0744 X-Gm-Message-State: ALoCoQmGMXAY+0VraJvL/qg61YbOmNQH76ATojsKWFEDDEG2xxNlLKwDm2yVdLx6MY1oJLrZ/lRT Cc: JSON WG Subject: Re: [Json] Consensus call: document title X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 21 Jun 2013 17:02:41 -0000 --047d7b6dc4a091bee104dfad0744 Content-Type: text/plain; charset=UTF-8 #1 -T On Fri, Jun 21, 2013 at 9:38 AM, Paul Hoffman wrote: > There are three proposals for dealing with the document title: > 0) Leave the title in the current draft as-is: > The application/json Media Type for JavaScript Object Notation > (JSON) > 1) Change the title to > The JSON Data Interchange Format > 2) Change the title to > The JSON Format for Encoding Data > > Please respond to this message with a list of proposals you could accept, > ordered from highest to lowest. Do not list proposals you cannot live with. > If you cannot accept any of the proposals, please respond and say why. > > Based on the responses we receive, we will try to judge the consensus of > the WG. > > -- The JSON WG co-chairs > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > --047d7b6dc4a091bee104dfad0744 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
#1=C2=A0 -T


On Fri, Jun 21, 2013 at 9:38 AM, Paul Hoffman <paul.hoffman@vpnc.org> wrote:
There are three proposals for dealing with t= he document title:
=C2=A0 0) Leave the title in the current draft as-is:
=C2=A0 =C2=A0 =C2=A0 =C2=A0The application/json Media Type for JavaScript O= bject Notation (JSON)
=C2=A0 1) Change the title to
=C2=A0 =C2=A0 =C2=A0 =C2=A0The JSON Data Interchange Format
=C2=A0 2) Change the title to
=C2=A0 =C2=A0 =C2=A0 =C2=A0The JSON Format for Encoding Data

Please respond to this message with a list of proposals you could accept, o= rdered from highest to lowest. Do not list proposals you cannot live with. = If you cannot accept any of the proposals, please respond and say why.

Based on the responses we receive, we will try to judge the consensus of th= e WG.

-- The JSON WG co-chairs
_______________________________________________
json mailing list
json@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/json

--047d7b6dc4a091bee104dfad0744-- From sgbeal@googlemail.com Fri Jun 21 10:21:16 2013 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 CF7C421F946C for ; Fri, 21 Jun 2013 10:21:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.654 X-Spam-Level: X-Spam-Status: No, score=-1.654 tagged_above=-999 required=5 tests=[AWL=0.323, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 363cFRJKcINL for ; Fri, 21 Jun 2013 10:21:15 -0700 (PDT) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 1BB9821F9FD7 for ; Fri, 21 Jun 2013 10:21:08 -0700 (PDT) Received: by mail-wi0-f172.google.com with SMTP id c10so858270wiw.11 for ; Fri, 21 Jun 2013 10:21:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=mA7/pvVHZzdMOxjcYXcy2g7Yj95ZFV+7X19Hj91+Ha4=; b=hzY+U0VLiMvurp5IMg3SIKTbYjLfk/Sok8DrKQXMmZSkx07VS/fkZVYeVK20ouVExh +qwpBHGsNLnxXXOgWyhmsxoRbNqhWa/HHSE8BUMnMneGuoNKiIvdIkGYQkjfM9l8smDJ zSkoEamPP9e2WtGAroiXs9eGY/am6px8+9PJL3dvPGKnzSrooDLm5jCxW8Zl3yKANiFk egD+85H8OxLZL2MYwuw1yqCtzVY+4PLi2CMvDSakTq+3BkNoT6cPSmwsM2Y4lp5wJ2/X peSMFXJ8ycD/h9/z4VuHxEtzPvuebsfNjR8ls3drG3VNVCslC4BoW0kQ2uEYSNC7cLNT cwtA== MIME-Version: 1.0 X-Received: by 10.194.75.201 with SMTP id e9mr9698441wjw.20.1371835268241; Fri, 21 Jun 2013 10:21:08 -0700 (PDT) Received: by 10.194.42.230 with HTTP; Fri, 21 Jun 2013 10:21:08 -0700 (PDT) In-Reply-To: References: Date: Fri, 21 Jun 2013 19:21:08 +0200 Message-ID: From: Stephan Beal To: "json@ietf.org" Content-Type: multipart/alternative; boundary=047d7bb04efcdadb3004dfad498d Subject: Re: [Json] Consensus call: establishing name equality X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 21 Jun 2013 17:21:17 -0000 --047d7bb04efcdadb3004dfad498d Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Fri, Jun 21, 2013 at 7:02 PM, Tim Bray wrote: > #1 and #3 only differ at the editorial-nit level; I=92m equally fine with > either. -T > +1 --=20 ----- stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal --047d7bb04efcdadb3004dfad498d Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
On Fri, Jun 21, 2013 at 7:02 PM, Tim Bray <tbray@textu= ality.com> wrote:
#1 and #3 only differ at th= e editorial-nit level; I=92m equally fine with either.=A0 -T

+1
=A0
--
----- stephan bealhtt= p://wanderinghorse.net/home/stephan/
--047d7bb04efcdadb3004dfad498d-- From sgbeal@googlemail.com Fri Jun 21 10:23:36 2013 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 098C221E8127 for ; Fri, 21 Jun 2013 10:23:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.679 X-Spam-Level: X-Spam-Status: No, score=-1.679 tagged_above=-999 required=5 tests=[AWL=0.298, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 89F8pZMLQkIr for ; Fri, 21 Jun 2013 10:23:34 -0700 (PDT) Received: from mail-wg0-x234.google.com (mail-wg0-x234.google.com [IPv6:2a00:1450:400c:c00::234]) by ietfa.amsl.com (Postfix) with ESMTP id 3EE1F21E811B for ; Fri, 21 Jun 2013 10:23:31 -0700 (PDT) Received: by mail-wg0-f52.google.com with SMTP id b12so6690980wgh.31 for ; Fri, 21 Jun 2013 10:23:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=NzAaM+VX5H+yg+8BP1kMPlg5W+hhSjFWrVyQUz06rdo=; b=I7+x9o5xBWNNhCjZAh+cXgecbgLvIL8bY02whgWLqxCZSjapp0BrP7PiE/tD9bsAOK TtLWNRVjTDnhavapNxmHGjFBvJMsLkJ2YhCECZ3kxgi7kqP7Y3WVu0Ov1JtFTHU2cspo /wPJV2/tTxrma7kkeh/9bL9a6OUPlrru/PgBygX/RwhJr9Z+jAlx0ZKe5/buN0Tv051m PY7SgS8uP+syCiLMIQLydhzk2kdHGmmTOKGGUC9MV/lMzeswCI7J8ENCdx4+zhfI9LbU UlAWG7I3yD5I5K5XUA6+wszodkij+MYNaeoJMKe5II+xfZj25wOFZrVmv2pnl3pN/PjJ dczw== MIME-Version: 1.0 X-Received: by 10.194.75.201 with SMTP id e9mr9704042wjw.20.1371835411143; Fri, 21 Jun 2013 10:23:31 -0700 (PDT) Received: by 10.194.42.230 with HTTP; Fri, 21 Jun 2013 10:23:31 -0700 (PDT) In-Reply-To: <90B659B8-D4AC-41AF-8C06-67FC65C8BD74@vpnc.org> References: <90B659B8-D4AC-41AF-8C06-67FC65C8BD74@vpnc.org> Date: Fri, 21 Jun 2013 19:23:31 +0200 Message-ID: From: Stephan Beal To: "json@ietf.org" Content-Type: multipart/alternative; boundary=047d7bb04efc5f224104dfad5299 Subject: Re: [Json] Consensus call: document title X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 21 Jun 2013 17:23:36 -0000 --047d7bb04efc5f224104dfad5299 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Jun 21, 2013 at 6:38 PM, Paul Hoffman wrote: > There are three proposals for dealing with the document title: > 1, 2 0 is a real mouthful, and i thought the consensus was to distance JSON from JS. (i'm ambivalent on that point, though.) -- ----- stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal --047d7bb04efc5f224104dfad5299 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, Jun 21, 2013 at 6:38 PM, Paul Hoffman <paul.h= offman@vpnc.org> wrote:
There are three proposals for dealing with the document ti= tle:

1, 2

0 is a real = mouthful, and i thought the consensus was to distance JSON from JS. (i'= m ambivalent on that point, though.)=A0

--
----- stephan beal
http://wanderinghorse.net/home/stephan/
--047d7bb04efc5f224104dfad5299-- From cabo@tzi.org Fri Jun 21 11:06:25 2013 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 E720721F9BC1 for ; Fri, 21 Jun 2013 11:06:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.209 X-Spam-Level: X-Spam-Status: No, score=-106.209 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YgCZCyPuREp3 for ; Fri, 21 Jun 2013 11:06:13 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 7FDC821F99BE for ; Fri, 21 Jun 2013 11:06:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r5LI6Ae5006106 for ; Fri, 21 Jun 2013 20:06:10 +0200 (CEST) Received: from [192.168.217.135] (p5489351C.dip0.t-ipconnect.de [84.137.53.28]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 712DE76C3; Fri, 21 Jun 2013 20:06:10 +0200 (CEST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Carsten Bormann In-Reply-To: <90B659B8-D4AC-41AF-8C06-67FC65C8BD74@vpnc.org> Date: Fri, 21 Jun 2013 20:06:09 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <90B659B8-D4AC-41AF-8C06-67FC65C8BD74@vpnc.org> To: JSON WG X-Mailer: Apple Mail (2.1508) Subject: Re: [Json] Consensus call: document title X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 21 Jun 2013 18:06:25 -0000 1 is preferable; 2 is OK in a pinch. (0 is wrong and thus I'm not listing it :-) Gr=FC=DFe, Carsten From cabo@tzi.org Fri Jun 21 11:18:36 2013 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 D119921F9BE5 for ; Fri, 21 Jun 2013 11:18:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.209 X-Spam-Level: X-Spam-Status: No, score=-106.209 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xt8a0w+s8CV1 for ; Fri, 21 Jun 2013 11:18:32 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 6302411E80AD for ; Fri, 21 Jun 2013 11:18:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r5LIIHQn026409; Fri, 21 Jun 2013 20:18:17 +0200 (CEST) Received: from [192.168.217.135] (p5489351C.dip0.t-ipconnect.de [84.137.53.28]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 75A4876CA; Fri, 21 Jun 2013 20:18:17 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: Date: Fri, 21 Jun 2013 20:18:16 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <6BCAAC4F-2B45-43BA-A40B-96F3369A5851@tzi.org> References: To: Paul Hoffman X-Mailer: Apple Mail (2.1508) Cc: JSON WG Subject: Re: [Json] Consensus call: establishing name equality X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 21 Jun 2013 18:18:37 -0000 Hmm, a bit too much MUSTard for my taste. Only the first MUST in 1 is = really needed. So 1 > 3 > 2, but I don't like any of them: a) The example does not illustrate the sentence preceding it (although = it sounds as if it were intended to do so): Swap the example and the = "no mods" sentence. (Again, b) we are comparing sequences of code points and not single code = points, and c) the "there is to be no mod" sentence is not properly = bound to the comparing, so there is infinite potential for = misinterpretation of these sentences unless you already know what they = are saying.) Do we have consensus what we'll use the name equality for that we just = defined? Gr=FC=DFe, Carsten On Jun 21, 2013, at 18:42, Paul Hoffman wrote: > There are four proposals for establishing name equality: >=20 > 0) Leave the current draft as-is, not discussing name equality >=20 > 1) In Section 2.5 ("Strings"), immediately before the ABNF add: > For purpose of establishing name equality, comparisons MUST be = conducted, after all unescaping > is done, by comparing numeric character code points. There is to be = no modification of any > kind to the characters in names, including case-changing or = combining-form normalization. > For example, the following four names MUST be considered equivalent: > * "\u002F" > * "\u002f" > * "\/" > * "/" >=20 > 2) In Section 2.5 ("Strings"), immediately before the ABNF add: > For purpose of establishing name equality, comparisons MUST be = conducted, after all unescaping > is done, by comparing numeric character code points. There MUST NOT = be any modification of any > kind to the characters in names, including change of case or change = between precomposed and > decomposed forms. > For example, the following four names MUST be considered equivalent: > * "\u002F" > * "\u002f" > * "\/" > * "/" >=20 > 3) In Section 2.5 ("Strings"), immediately before the ABNF add: > For purpose of establishing name equality, implementations MUST = first do all unescaping and > then MUST compare numeric character code points. There is to be no = modification of any kind to > the characters in names, including case-changing or combining-form = normalization. > For example, the following four names MUST be considered equivalent: > * "\u002F" > * "\u002f" > * "\/" > * "/" >=20 > Please respond to this message with a list of proposals you could = accept, ordered from highest to lowest. Do not list proposals you cannot = live with. If you cannot accept any of the proposals, please respond and = say why. >=20 > Based on the responses we receive, we will try to judge the consensus = of the WG. >=20 > -- The JSON WG co-chairs >=20 >=20 > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json >=20 From cabo@tzi.org Fri Jun 21 11:27:28 2013 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 3619A21FA000 for ; Fri, 21 Jun 2013 11:27:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.21 X-Spam-Level: X-Spam-Status: No, score=-106.21 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jDmrv15XL09U for ; Fri, 21 Jun 2013 11:27:22 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 0D1C421F9F32 for ; Fri, 21 Jun 2013 11:27:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r5LIRINd011506; Fri, 21 Jun 2013 20:27:18 +0200 (CEST) Received: from [192.168.217.135] (p5489351C.dip0.t-ipconnect.de [84.137.53.28]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3E21676D3; Fri, 21 Jun 2013 20:27:18 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <9E497099-2B5B-4256-B066-C2E77B558267@vpnc.org> Date: Fri, 21 Jun 2013 20:27:17 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <8E2702C8-CB58-49C0-BB8C-3C4DC2BD8AEA@tzi.org> References: <9E497099-2B5B-4256-B066-C2E77B558267@vpnc.org> To: Paul Hoffman X-Mailer: Apple Mail (2.1508) Cc: JSON WG Subject: Re: [Json] Consensus call: ABNF nits X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 21 Jun 2013 18:27:28 -0000 1 is better. (and the tools confirm that 0 and 1 are semantically exactly equivalent, = ignoring comments.) Gr=FC=DFe, Carsten From douglas@crockford.com Fri Jun 21 11:31:57 2013 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 25FB921F9FA5 for ; Fri, 21 Jun 2013 11:31:57 -0700 (PDT) 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=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1a0M3ZguLKu8 for ; Fri, 21 Jun 2013 11:31:52 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id 859CE21F9F10 for ; Fri, 21 Jun 2013 11:31:46 -0700 (PDT) Received: from oxuslxltgw03.lxa.perfora.net (oxuslxltgw03.lxa.perfora.net [172.19.206.5]) by mrelay.perfora.net (node=mrus0) with ESMTP (Nemesis) id 0LevkF-1UVtXD447T-00ql7k; Fri, 21 Jun 2013 14:31:45 -0400 Date: Fri, 21 Jun 2013 11:31:44 -0700 (PDT) From: "douglas@crockford.com" To: json@ietf.org Message-ID: <833372357.126503.1371839504953.open-xchange@email.1and1.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Priority: 3 Importance: Medium X-Mailer: Open-Xchange Mailer v7.2.1-Rev4 X-Provags-ID: V02:K0:M8WBZ0k7U9Jut33eMM0F+4WMhqWj1jngfXuq8vfwc6R RSRVGYOR3yR729x298cgjbpXAkDGRtoT90y6/j8/ml8tU5wJ3U 1/NJFITUC8qxUNOuZF8Bs9MoU7EuUdjQGYLIMG/++V2t92AfM1 yABoWDiz26/CFXRzOIea1h+eHDet0ToAmXqFCipTa68DUVdwtH jbOt6myFzUzgJ58A0ljcGKI1v/imopl6aZh4D0/uJd43AsXJ8h fD0CTO/aF4FES6WC7LWfBZ2aGJ6UM7F8VdeZEVdTcYrbzQ7ZVF oHxfgS1La74hjA55o52hkf9otsTO/3u1XHHxaIWXJJz36/uHkp Agj2wdYr0UZ0YU0Nd2yx+lMb30smdON7U/oXAs/BXdVdPvmYNe 8PoU1BTNHleoFi5OB6dWOcAFmaY7kJQpbQ= Subject: Re: [Json] Consensus call: document title X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "douglas@crockford.com" List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jun 2013 18:31:57 -0000 I think this call is premature. We first need to determine which document we are producing. That will determine the title. If we are making The JSON Data Interchange Format document, then it should obviously have that title. But if we are changing the status of the RFC, then it should retain its current title. From ietf@lindenbergsoftware.com Fri Jun 21 11:57:02 2013 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 0AB0221F9E5A for ; Fri, 21 Jun 2013 11:57:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.003 X-Spam-Level: X-Spam-Status: No, score=-3.003 tagged_above=-999 required=5 tests=[AWL=-1.204, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_16=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4PGf4AxyTV2e for ; Fri, 21 Jun 2013 11:56:57 -0700 (PDT) Received: from mirach.lunarpages.com (mirach.lunarpages.com [216.97.235.70]) by ietfa.amsl.com (Postfix) with ESMTP id 6D6D221F9CF2 for ; Fri, 21 Jun 2013 11:56:57 -0700 (PDT) Received: from 50-0-136-241.dsl.dynamic.sonic.net ([50.0.136.241]:57524 helo=[192.168.0.5]) by mirach.lunarpages.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1Uq6Vx-000xLn-GE; Fri, 21 Jun 2013 11:56:53 -0700 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=utf-8 From: Norbert Lindenberg In-Reply-To: <9E497099-2B5B-4256-B066-C2E77B558267@vpnc.org> Date: Fri, 21 Jun 2013 11:56:50 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <339F1E4A-5D5F-481E-AF4D-42477A07F50F@lindenbergsoftware.com> References: <9E497099-2B5B-4256-B066-C2E77B558267@vpnc.org> To: Paul Hoffman X-Mailer: Apple Mail (2.1283) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - mirach.lunarpages.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - lindenbergsoftware.com X-Get-Message-Sender-Via: mirach.lunarpages.com: authenticated_id: ietf@lindenbergsoftware.com Cc: Norbert Lindenberg , JSON WG Subject: Re: [Json] Consensus call: ABNF nits X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 21 Jun 2013 18:57:02 -0000 On Jun 21, 2013, at 9:40 , Paul Hoffman wrote: > There are two proposals for dealing with nits in the ABNF: > 0) Leave the ABNF in the current draft as-is > 1) Change the ABNF in the draft to use the values in "Proposal 1" = below > Note that later proposals might make technical changes to the ABNF = itself; those proposals are not what we are discussing in this consensus = call. >=20 > Please respond to this message with a list of proposals you could = accept, ordered from highest to lowest. Do not list proposals you cannot = live with. If you cannot accept any of the proposals, please respond and = say why. Below are comments on three issues with proposal 1. The second issue, if = not addressed, would make proposal 1 unacceptable to me. Otherwise I = prefer proposal 1 over the old version. > char =3D unescaped / ( > escape ( > %x22 / ; " quotation mark U+0022 > %x5C / ; \ reverse solidus U+005C > %x2F / ; / solidus U+002F > %x62 / ; b backspace U+0008 > %x66 / ; f form feed U+000C > %x6E / ; n line feed U+000A > %x72 / ; r carriage return U+000D > %x74 / ; t tab U+0009 > %x75 4HEXDIG ) ) ; uXXXX U+XXXX As noted earlier, the last line isn't quite correct - \uXXXX can not = only represent U+XXXX, but also be part of U+YYYYYY, where YYYYYY = depends on a preceding or following \uXXXX sequence. Proposal: Replace "U+XXXX" with "U+XXXX or part of U+YYYYYY". > escape =3D %x5C ; \ U+005C > quotation-mark =3D %x22 ; " U+0022 > unescaped =3D %x20-21 / %x23-5B / %x5D-10FFFF ; any Unicode scalar > ; value, except those that must be escaped (C0 control > ; characters, "QUOTATION MARK" [U+0022], and "REVERSE SOLIDUS" > ; [U+005C]) Describing "unescaped" as "any Unicode scalar value, except..." is = wrong. The correct term is "Unicode code point". Unicode scalar values = do not include the range U+D800 through U+DFFFF. http://www.unicode.org/glossary/#unicode_scalar_value > HEXDIG =3D DIGIT / %x41-46 / %x61-66 ; 0-9, A-F, or a-f > ; HEXDIG equivalent to HEXDIG rule in [RFC5234] To complete the effort of disambiguating Unicode characters in the = grammar, the comment should include "U+0030 through U+0039, U+0041 = through U+0046, U+0061 through U+0066". We don't want them to be = confused with =EF=BC=90-=EF=BC=99, =EF=BC=A1-=EF=BC=A6, or =EF=BD=81-=EF=BD= =86. Norbert= From barryleiba.mailing.lists@gmail.com Fri Jun 21 12:19:46 2013 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 BF7AC21F9FDA for ; Fri, 21 Jun 2013 12:19:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.02 X-Spam-Level: X-Spam-Status: No, score=-102.02 tagged_above=-999 required=5 tests=[AWL=-0.042, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2TcPDpCYibn8 for ; Fri, 21 Jun 2013 12:19:46 -0700 (PDT) Received: from mail-vb0-x229.google.com (mail-vb0-x229.google.com [IPv6:2607:f8b0:400c:c02::229]) by ietfa.amsl.com (Postfix) with ESMTP id 41E7221F9FA4 for ; Fri, 21 Jun 2013 12:19:46 -0700 (PDT) Received: by mail-vb0-f41.google.com with SMTP id p13so6234607vbe.14 for ; Fri, 21 Jun 2013 12:19:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=Hl9adQ5218wUNya/jIN5zohc9GuWFlQC+eYEheOQ3pA=; b=fJmxTNy493EXuXoJ/naITSyyhM60xHimXFMCrwmvodjktmgho5mlvnOUsPXix13acl P8RTFIiG+6raHi9kTaUlpnMOAP/rr0DyEBeOa1NeJ5i1HlCl6yGpcPaF4D9J/SZ+kBUT NPEMRB2c3O9ojNy3m5/ZDQSanBlyNzSXRHRchA3sMl4AyNAm36653pUWQnCXeTC1wQRX AR2ddgPUZODuH8nPWWj9XjoZNkJ4AuU9klNqsK3vBkbX5rUrxRR40DsLMfgV3E1QAWS6 U2daXn9ecD34UpoJ4o2yKMW2HVdBgYPBn2wEaY/2QzgnXKBM2uQccAnyjCsi/r5l1p9y P5MQ== MIME-Version: 1.0 X-Received: by 10.58.34.69 with SMTP id x5mr6559328vei.11.1371842385490; Fri, 21 Jun 2013 12:19:45 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.58.234.105 with HTTP; Fri, 21 Jun 2013 12:19:45 -0700 (PDT) In-Reply-To: <833372357.126503.1371839504953.open-xchange@email.1and1.com> References: <833372357.126503.1371839504953.open-xchange@email.1and1.com> Date: Fri, 21 Jun 2013 15:19:45 -0400 X-Google-Sender-Auth: Vt0PU-67BzouH_YQ9BbK5QmNRcc Message-ID: From: Barry Leiba To: "douglas@crockford.com" Content-Type: text/plain; charset=ISO-8859-1 Cc: json@ietf.org Subject: Re: [Json] Consensus call: document title X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 21 Jun 2013 19:19:46 -0000 > I think this call is premature. We first need to determine which document we are > producing. That will determine the title. If we are making The JSON Data > Interchange Format document, then it should obviously have that title. But if we > are changing the status of the RFC, then it should retain its current title. Procedural point: This is certainly a valid opinion (that we shouldn't change the title as we replace the document), but there's no *procedural* reason that the title can't or shouldn't be changed in the process of changing the status, as long as we're making changes and issuing a new RFC. The only time the title *couldn't* be changed would be if we were actually changing *only* the status metadata, and not publishing a new RFC. Barry From ietf@augustcellars.com Fri Jun 21 14:04:26 2013 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 42FB321F9DD4 for ; Fri, 21 Jun 2013 14:04:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.289 X-Spam-Level: X-Spam-Status: No, score=-3.289 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7zYY5f5MeuJr for ; Fri, 21 Jun 2013 14:04:21 -0700 (PDT) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9CB0421F9E1C for ; Fri, 21 Jun 2013 14:04:21 -0700 (PDT) Received: from Philemon (173-160-230-154-Washington.hfc.comcastbusiness.net [173.160.230.154]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id 7374F2C9F5; Fri, 21 Jun 2013 14:04:21 -0700 (PDT) From: "Jim Schaad" To: "'Paul Hoffman'" , "'JSON WG'" References: <90B659B8-D4AC-41AF-8C06-67FC65C8BD74@vpnc.org> In-Reply-To: <90B659B8-D4AC-41AF-8C06-67FC65C8BD74@vpnc.org> Date: Fri, 21 Jun 2013 14:03:26 -0700 Message-ID: <06a901ce6ec2$c6ac6260$54052720$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us Thread-Index: AQIYRwD11oUXLPzWYMeQJGNAY8iWoJis930Q Subject: Re: [Json] Consensus call: document title X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 21 Jun 2013 21:04:26 -0000 1 2 Jim > -----Original Message----- > From: json-bounces@ietf.org [mailto:json-bounces@ietf.org] On Behalf Of > Paul Hoffman > Sent: Friday, June 21, 2013 9:39 AM > To: JSON WG > Subject: [Json] Consensus call: document title > > There are three proposals for dealing with the document title: > 0) Leave the title in the current draft as-is: > The application/json Media Type for JavaScript Object Notation (JSON) > 1) Change the title to > The JSON Data Interchange Format > 2) Change the title to > The JSON Format for Encoding Data > > Please respond to this message with a list of proposals you could accept, > ordered from highest to lowest. Do not list proposals you cannot live with. If > you cannot accept any of the proposals, please respond and say why. > > Based on the responses we receive, we will try to judge the consensus of the > WG. > > -- The JSON WG co-chairs > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json From ietf@augustcellars.com Fri Jun 21 14:05:57 2013 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 7D56121F9E2A for ; Fri, 21 Jun 2013 14:05:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.367 X-Spam-Level: X-Spam-Status: No, score=-3.367 tagged_above=-999 required=5 tests=[AWL=0.233, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0IdZRj5EBjsx for ; Fri, 21 Jun 2013 14:05:52 -0700 (PDT) Received: from smtp4.pacifier.net (smtp4.pacifier.net [64.255.237.176]) by ietfa.amsl.com (Postfix) with ESMTP id D433721F9E3F for ; Fri, 21 Jun 2013 14:05:52 -0700 (PDT) Received: from Philemon (173-160-230-154-Washington.hfc.comcastbusiness.net [173.160.230.154]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp4.pacifier.net (Postfix) with ESMTPSA id 850F138F00; Fri, 21 Jun 2013 14:05:52 -0700 (PDT) From: "Jim Schaad" To: "'Paul Hoffman'" , "'JSON WG'" References: In-Reply-To: Date: Fri, 21 Jun 2013 14:04:58 -0700 Message-ID: <06aa01ce6ec2$fd0de4a0$f729ade0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us Thread-Index: AQFcrSXQKVqoOiIoZ9W4zZulto3hJZokK6Zg Subject: Re: [Json] Consensus call: establishing name equality X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 21 Jun 2013 21:05:57 -0000 3 1 2 Jim > -----Original Message----- > From: json-bounces@ietf.org [mailto:json-bounces@ietf.org] On Behalf Of > Paul Hoffman > Sent: Friday, June 21, 2013 9:42 AM > To: JSON WG > Subject: [Json] Consensus call: establishing name equality > > There are four proposals for establishing name equality: > > 0) Leave the current draft as-is, not discussing name equality > > 1) In Section 2.5 ("Strings"), immediately before the ABNF add: > For purpose of establishing name equality, comparisons MUST be > conducted, after all unescaping > is done, by comparing numeric character code points. There is to be no > modification of any > kind to the characters in names, including case-changing or combining-form > normalization. > For example, the following four names MUST be considered equivalent: > * "\u002F" > * "\u002f" > * "\/" > * "/" > > 2) In Section 2.5 ("Strings"), immediately before the ABNF add: > For purpose of establishing name equality, comparisons MUST be > conducted, after all unescaping > is done, by comparing numeric character code points. There MUST NOT be > any modification of any > kind to the characters in names, including change of case or change > between precomposed and > decomposed forms. > For example, the following four names MUST be considered equivalent: > * "\u002F" > * "\u002f" > * "\/" > * "/" > > 3) In Section 2.5 ("Strings"), immediately before the ABNF add: > For purpose of establishing name equality, implementations MUST first do > all unescaping and > then MUST compare numeric character code points. There is to be no > modification of any kind to > the characters in names, including case-changing or combining-form > normalization. > For example, the following four names MUST be considered equivalent: > * "\u002F" > * "\u002f" > * "\/" > * "/" > > Please respond to this message with a list of proposals you could accept, > ordered from highest to lowest. Do not list proposals you cannot live with. If > you cannot accept any of the proposals, please respond and say why. > > Based on the responses we receive, we will try to judge the consensus of the > WG. > > -- The JSON WG co-chairs > > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json From ietf@lindenbergsoftware.com Fri Jun 21 15:19:20 2013 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 334A721F9DE5 for ; Fri, 21 Jun 2013 15:19:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.811 X-Spam-Level: X-Spam-Status: No, score=-3.811 tagged_above=-999 required=5 tests=[AWL=-0.212, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j3nRpmsWs1ag for ; Fri, 21 Jun 2013 15:19:14 -0700 (PDT) Received: from mirach.lunarpages.com (mirach.lunarpages.com [216.97.235.70]) by ietfa.amsl.com (Postfix) with ESMTP id 6968121F9D85 for ; Fri, 21 Jun 2013 15:19:14 -0700 (PDT) Received: from 50-0-136-241.dsl.dynamic.sonic.net ([50.0.136.241]:57700 helo=[192.168.0.5]) by mirach.lunarpages.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1Uq9fh-001fzL-SZ; Fri, 21 Jun 2013 15:19:09 -0700 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Norbert Lindenberg In-Reply-To: <90B659B8-D4AC-41AF-8C06-67FC65C8BD74@vpnc.org> Date: Fri, 21 Jun 2013 15:19:05 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <90B659B8-D4AC-41AF-8C06-67FC65C8BD74@vpnc.org> To: Paul Hoffman X-Mailer: Apple Mail (2.1283) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - mirach.lunarpages.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - lindenbergsoftware.com X-Get-Message-Sender-Via: mirach.lunarpages.com: authenticated_id: ietf@lindenbergsoftware.com Cc: Norbert Lindenberg , JSON WG Subject: Re: [Json] Consensus call: document title X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 21 Jun 2013 22:19:20 -0000 On Jun 21, 2013, at 9:38 , Paul Hoffman wrote: > There are three proposals for dealing with the document title: > 0) Leave the title in the current draft as-is: > The application/json Media Type for JavaScript Object Notation = (JSON) > 1) Change the title to > The JSON Data Interchange Format > 2) Change the title to > The JSON Format for Encoding Data >=20 > Please respond to this message with a list of proposals you could = accept, ordered from highest to lowest. Do not list proposals you cannot = live with. If you cannot accept any of the proposals, please respond and = say why. 1, 2. Norbert From cromis@gmail.com Fri Jun 21 15:23:41 2013 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 F292721F9E11 for ; Fri, 21 Jun 2013 15:23:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.858 X-Spam-Level: X-Spam-Status: No, score=-1.858 tagged_above=-999 required=5 tests=[AWL=0.119, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zar95SyeGt84 for ; Fri, 21 Jun 2013 15:23:36 -0700 (PDT) Received: from mail-qa0-x235.google.com (mail-qa0-x235.google.com [IPv6:2607:f8b0:400d:c00::235]) by ietfa.amsl.com (Postfix) with ESMTP id 7488721F9DEC for ; Fri, 21 Jun 2013 15:23:36 -0700 (PDT) Received: by mail-qa0-f53.google.com with SMTP id g10so981643qah.12 for ; Fri, 21 Jun 2013 15:23:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=wo9YmwTjbwDBBTkeO5v6ofyBTOXzkyaWf/TgV18vf5s=; b=rOKFQMaSh5XXX8rS+N+ZjDgSWSdnaPz1BUkS4etu0K4SFYo58AjjFjU4i1XyKXUmjc bh56/HHjj/JE1CbOshKVJLDdKvZAPr1IoIpM1VV82dFGzs4GRwRAs1w5e5saby8PDHPP r7Jm0JyBOOObjFG4QLq8iRb00EXXsTNdj/OyTdzwg/MozUeIDN73jaiSVdnvDTNe4VFr vOtLxY5Z1Jo04wCqk8fyQ2Q6Ar/jsiQcM3AFWWZWVz+hSfkpWAzUvkdCeTdLqZmFqqmE zRAVFCtAMArcZ0OJQUiZiXGn0k7bckkkEvWfpT/Mi/ZHD0B/t7oJfg29OnxnnwUAXYjY +Gww== X-Received: by 10.49.127.196 with SMTP id ni4mr8884010qeb.5.1371853415876; Fri, 21 Jun 2013 15:23:35 -0700 (PDT) MIME-Version: 1.0 Sender: cromis@gmail.com Received: by 10.49.76.42 with HTTP; Fri, 21 Jun 2013 15:23:15 -0700 (PDT) In-Reply-To: <6BCAAC4F-2B45-43BA-A40B-96F3369A5851@tzi.org> References: <6BCAAC4F-2B45-43BA-A40B-96F3369A5851@tzi.org> From: Jacob Davies Date: Fri, 21 Jun 2013 15:23:15 -0700 X-Google-Sender-Auth: Ovk_1ytyEIP1x_D7JYy1uSx1vCQ Message-ID: To: Carsten Bormann Content-Type: multipart/alternative; boundary=047d7b5dae98898d1204dfb183fb Cc: Paul Hoffman , JSON WG Subject: Re: [Json] Consensus call: establishing name equality X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 21 Jun 2013 22:23:41 -0000 --047d7b5dae98898d1204dfb183fb Content-Type: text/plain; charset=ISO-8859-1 On Fri, Jun 21, 2013 at 11:18 AM, Carsten Bormann wrote: > Do we have consensus what we'll use the name equality for that we just > defined? > That's my question. What is the problem this is seeking to solve again? Because I'm inclined to say 0, especially since keys cannot be guaranteed to be unique (and so no definition of uniqueness needs to be defined for that). It seems like this is dictating the interpretation of data, rather than its format. --047d7b5dae98898d1204dfb183fb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, Jun 21, 2013 at 11:18 AM, Carsten Bormann <cabo@tzi.or= g> wrote:
Do we have consensus what we'll use the name equality for that we just = defined?

That's my question. = What is the problem this is seeking to solve again? Because I'm incline= d to say 0, especially since keys cannot be guaranteed to be unique (and so= no definition of uniqueness needs to be defined for that). It seems like t= his is dictating the interpretation of data, rather than its format.
--047d7b5dae98898d1204dfb183fb-- From tbray@textuality.com Fri Jun 21 15:29:42 2013 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 5160121F9E76 for ; Fri, 21 Jun 2013 15:29:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.3 X-Spam-Level: X-Spam-Status: No, score=-0.3 tagged_above=-999 required=5 tests=[AWL=-0.752, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_SORBS_DUL=0.877, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id auGenyPJy2oq for ; Fri, 21 Jun 2013 15:29:38 -0700 (PDT) Received: from mail-vc0-x22a.google.com (mail-vc0-x22a.google.com [IPv6:2607:f8b0:400c:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 2296B21F9E75 for ; Fri, 21 Jun 2013 15:29:38 -0700 (PDT) Received: by mail-vc0-f170.google.com with SMTP id hf12so62529vcb.1 for ; Fri, 21 Jun 2013 15:29:37 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=UvEHhrxG4rF1/0+unNsXQq+3ifi9+j0GdgkIYBScA4k=; b=UbIrAUsPuDHYgcbbC3zA/37nJLmMjZikfvey4SUUEDGVNb8+XefnLQCWwijCYFNs4b BZmEUKkeu1dL1JD0GWWF1DUKWlX9g3OWUJYI2MKZh4ib/ySrjU8ZyltIY6jXXWwZYjgJ ULWnFM81F7oSgphsCSh/0YYSyCmUBQZeO0gXDQQnAYZ/Y8yeNjAK5W5lzsirT/sz447W pUDdSOThvrhRFLxeBfSsoWXVcgtA7GHnrgTIVQx2beTiSUBe5s7GzLRqPzgzOU5k/Ity iuSKckATXaKj007Qsi5wbHoFeGdDW23tBVtxScVTXkOUyzsGcDn19QeibS0X2/0fuRQT igjA== MIME-Version: 1.0 X-Received: by 10.52.119.233 with SMTP id kx9mr5608483vdb.50.1371853777482; Fri, 21 Jun 2013 15:29:37 -0700 (PDT) Received: by 10.220.219.200 with HTTP; Fri, 21 Jun 2013 15:29:37 -0700 (PDT) X-Originating-IP: [96.49.81.176] In-Reply-To: References: <6BCAAC4F-2B45-43BA-A40B-96F3369A5851@tzi.org> Date: Fri, 21 Jun 2013 15:29:37 -0700 Message-ID: From: Tim Bray To: Jacob Davies Content-Type: multipart/alternative; boundary=047d7bdc8be4174b1d04dfb199f5 X-Gm-Message-State: ALoCoQkq8gGSGC4uwPXNWFXVklQnzoeFhV8TteyzewJbrCl1IYLolM3A8c2vNqWF3d0F3WYgn7YP Cc: Carsten Bormann , Paul Hoffman , JSON WG Subject: Re: [Json] Consensus call: establishing name equality X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 21 Jun 2013 22:29:42 -0000 --047d7bdc8be4174b1d04dfb199f5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hm, I think this is useful. I=E2=80=99ve seen people go off the rails tryi= ng to be overly clever comparing strings, so this in effect is just telling them not to overthink. -T On Fri, Jun 21, 2013 at 3:23 PM, Jacob Davies wrote: > On Fri, Jun 21, 2013 at 11:18 AM, Carsten Bormann wrote: > >> Do we have consensus what we'll use the name equality for that we just >> defined? >> > > That's my question. What is the problem this is seeking to solve again? > Because I'm inclined to say 0, especially since keys cannot be guaranteed > to be unique (and so no definition of uniqueness needs to be defined for > that). It seems like this is dictating the interpretation of data, rather > than its format. > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > > --047d7bdc8be4174b1d04dfb199f5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hm, I think this is useful.=C2=A0 I=E2=80=99ve seen people= go off the rails trying to be overly clever comparing strings, so this in = effect is just telling them not to overthink. -T


On Fri, Jun 21, 2013 at 3:23 PM, Jacob Davie= s <jacob@well.com> wrote:
On Fri, Jun 21, 2013 at 11:18 AM, Carste= n Bormann <cabo@tzi.org> wrote:
Do we have consensus what we'll use the name equality for that we just = defined?

That's my question. = What is the problem this is seeking to solve again? Because I'm incline= d to say 0, especially since keys cannot be guaranteed to be unique (and so= no definition of uniqueness needs to be defined for that). It seems like t= his is dictating the interpretation of data, rather than its format.

_______________________________________________
json mailing list
json@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/json


--047d7bdc8be4174b1d04dfb199f5-- From nico@cryptonector.com Fri Jun 21 15:31:38 2013 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 56F6921F9976 for ; Fri, 21 Jun 2013 15:31:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.959 X-Spam-Level: X-Spam-Status: No, score=-1.959 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZmMDTje7Zf7H for ; Fri, 21 Jun 2013 15:31:25 -0700 (PDT) Received: from homiemail-a63.g.dreamhost.com (caiajhbdcbef.dreamhost.com [208.97.132.145]) by ietfa.amsl.com (Postfix) with ESMTP id A71B121F992A for ; Fri, 21 Jun 2013 15:31:24 -0700 (PDT) Received: from homiemail-a63.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a63.g.dreamhost.com (Postfix) with ESMTP id 579B02F4075 for ; Fri, 21 Jun 2013 15:31:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=8pC3RcQDSXUe0MuA9DXP2NhWbEk=; b=hsv5amrdOy8 dUi8FSSXI5GTyPOmOG8t9vXdPdxlqpBusoc+0KnbPI6eccNm6KB5CjguZXN9XEXf GneGNRGeBEUE1VzCuydZT7zvfeS0hzdFb0QpPYVVVTzd0I7iP98MhaxhkCMIs+Wa B7/ahJOvyrWP8je12InkZ3ejG13gZK2Q= Received: from mail-wg0-f43.google.com (mail-wg0-f43.google.com [74.125.82.43]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a63.g.dreamhost.com (Postfix) with ESMTPSA id 0069A2F406D for ; Fri, 21 Jun 2013 15:31:23 -0700 (PDT) Received: by mail-wg0-f43.google.com with SMTP id z11so6988747wgg.22 for ; Fri, 21 Jun 2013 15:31:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=rW3gas9HQfyy8xMva97nxCv21TN1q584iN1Pkpy+i8I=; b=fbbpADXTO93X7zLfKQnMp1+7DzbTfonOxyaWXBMt2jrFU6SQqbGF72XvBCh/GNTPsr SRwFCRAENq47nwQCBh3kqjX+DH+q9zF07RkcmbzENnsmkiYLsW54ZBtm+ikYx0LbiYH1 /fruWWEnYeVAOkO6esJBWQjvYopEZj+ZavqMt0YTYWFgUmiVQt4Je+HQg5Ltk/q2NdqE oG/VRkAtheya1mkqSCoN+tuHurfxEn2WDjHqB5S33OsbwzFmVUXpStVB9AgB+Exj+6PD FgczxZBEWAYPKUR+hi9uD2E+UAAnpXtpADaQUaKXdcy0K5HnnGmi8/lR0dbpqRlYRzZQ lQ+A== MIME-Version: 1.0 X-Received: by 10.194.78.110 with SMTP id a14mr10537291wjx.84.1371853882573; Fri, 21 Jun 2013 15:31:22 -0700 (PDT) Received: by 10.216.29.5 with HTTP; Fri, 21 Jun 2013 15:31:22 -0700 (PDT) In-Reply-To: References: <6BCAAC4F-2B45-43BA-A40B-96F3369A5851@tzi.org> Date: Fri, 21 Jun 2013 17:31:22 -0500 Message-ID: From: Nico Williams To: Tim Bray Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Carsten Bormann , Jacob Davies , Paul Hoffman , JSON WG Subject: Re: [Json] Consensus call: establishing name equality X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 21 Jun 2013 22:31:38 -0000 On Fri, Jun 21, 2013 at 5:29 PM, Tim Bray wrote: > Hm, I think this is useful. I=E2=80=99ve seen people go off the rails tr= ying to be > overly clever comparing strings, so this in effect is just telling them n= ot > to overthink. -T Is that yet another instance of breakage we're not allowed to cause? From cromis@gmail.com Fri Jun 21 16:15:41 2013 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 8358E21F9EBA for ; Fri, 21 Jun 2013 16:15:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.873 X-Spam-Level: X-Spam-Status: No, score=-1.873 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qCfcBeN6azhq for ; Fri, 21 Jun 2013 16:15:41 -0700 (PDT) Received: from mail-qa0-x22b.google.com (mail-qa0-x22b.google.com [IPv6:2607:f8b0:400d:c00::22b]) by ietfa.amsl.com (Postfix) with ESMTP id DC63421F9EB8 for ; Fri, 21 Jun 2013 16:15:40 -0700 (PDT) Received: by mail-qa0-f43.google.com with SMTP id d13so1018255qak.2 for ; Fri, 21 Jun 2013 16:15:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=POvGz2GV0vJf2Lnu8chDEUw6GDZEQg0rk09wWe8fvak=; b=BqV4FL/fkeawuknqWeVzabw3ySpa/Jvy6v512k5dofmE2xxztvvhyxwFZbuWi94Df5 5P057Z2ca3q7FrLtJAq9m1txA81F27A7bf5pJyAVw/uad8hlx/FWWR6Z0WKGOnyCzuuR Ixn9kY8nC7Mp4HUiq2Y90ReuhuGaWYkKAuM1dBKn7XgssQZ1g6bwYZsXqWziDIviS1vI rbV7/A31IwYaDzta6sIKwap6x7etU+B/MWAselw5xnyYtA4lwzJQqfXSrQhIBeZIRkNn hPNISUNzBfFOAtCOPOofjPt/AbobsFaEQbWWLVPosZnrSirqVyCkyoH/DWHdaVvPzymc 5kww== X-Received: by 10.224.123.68 with SMTP id o4mr7696437qar.106.1371856540348; Fri, 21 Jun 2013 16:15:40 -0700 (PDT) MIME-Version: 1.0 Sender: cromis@gmail.com Received: by 10.49.76.42 with HTTP; Fri, 21 Jun 2013 16:15:20 -0700 (PDT) In-Reply-To: References: <6BCAAC4F-2B45-43BA-A40B-96F3369A5851@tzi.org> From: Jacob Davies Date: Fri, 21 Jun 2013 16:15:20 -0700 X-Google-Sender-Auth: lcxe4y2k6NyqTfsH1ErO4da2Ka0 Message-ID: To: Tim Bray Content-Type: multipart/alternative; boundary=047d7bd6bc92c5522104dfb23dbc Cc: Carsten Bormann , Paul Hoffman , JSON WG Subject: Re: [Json] Consensus call: establishing name equality X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 21 Jun 2013 23:15:41 -0000 --047d7bd6bc92c5522104dfb23dbc Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Fri, Jun 21, 2013 at 3:29 PM, Tim Bray wrote: > Hm, I think this is useful. I=92ve seen people go off the rails trying t= o > be overly clever comparing strings, so this in effect is just telling the= m > not to overthink. -T > Is this definition of equality needed elsewhere in the document though? Standing alone it seems a little odd - there's no discussion how to compare two numbers, two objects, or two lists for equality, so why are strings-used-for-names special? --047d7bd6bc92c5522104dfb23dbc Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
On Fri, Jun 21, 2013 at 3:29 PM, Tim Bray <tbray@textu= ality.com> wrote:
Hm, I think this is useful.= =A0 I=92ve seen people go off the rails trying to be overly clever comparin= g strings, so this in effect is just telling them not to overthink. -T

Is this definition of equality neede= d elsewhere in the document though? Standing alone it seems a little odd - = there's no discussion how to compare two numbers, two objects, or two l= ists for equality, so why are strings-used-for-names special?
--047d7bd6bc92c5522104dfb23dbc-- From tbray@textuality.com Fri Jun 21 16:22:00 2013 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 2571D21F9E99 for ; Fri, 21 Jun 2013 16:22:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.25 X-Spam-Level: X-Spam-Status: No, score=-0.25 tagged_above=-999 required=5 tests=[AWL=-0.702, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_SORBS_DUL=0.877, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P0BXFm98V2+y for ; Fri, 21 Jun 2013 16:21:55 -0700 (PDT) Received: from mail-ve0-x22c.google.com (mail-ve0-x22c.google.com [IPv6:2607:f8b0:400c:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id C59DE21F9ABC for ; Fri, 21 Jun 2013 16:21:54 -0700 (PDT) Received: by mail-ve0-f172.google.com with SMTP id jz10so7031780veb.17 for ; Fri, 21 Jun 2013 16:21:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=uUj2s3pGYsIeKzQllYN+sSHIOhIkMa8Vo+4oROhswBk=; b=Ihdbx39kbULjc9k8SguZ8+6aGJMKkYHdWXQf8h2iKCBHTBcTPSu9Z5kD1metbiy7Op EXEJgJkFcynA2sFCzA4h51onTv059M55iYSmJVVY7bTs8vXnM6w76w9k/LbK3JJr66Li Kwzcx4SV9atAC+qQ1txH8qbTQb6NMznlKIUXUWyBJFKIL66Ah6GZMsWUuwsJxF5GZB/f pzVR/DL11XFcxHykpduOLr+zeUu251vkLeO0wqK1CMtfU4Hijqa9cSLfzsAflmpUl6Vx y4PsumiJtF3gXiiMbFHxkwhwcUt8as0qDYNSkKSKpiGh/PdqmUk+7HcIHDHcZuER2JdZ ClXA== MIME-Version: 1.0 X-Received: by 10.58.180.102 with SMTP id dn6mr6989473vec.79.1371856913737; Fri, 21 Jun 2013 16:21:53 -0700 (PDT) Received: by 10.220.219.200 with HTTP; Fri, 21 Jun 2013 16:21:53 -0700 (PDT) X-Originating-IP: [96.49.81.176] In-Reply-To: References: <6BCAAC4F-2B45-43BA-A40B-96F3369A5851@tzi.org> Date: Fri, 21 Jun 2013 16:21:53 -0700 Message-ID: From: Tim Bray To: Jacob Davies Content-Type: multipart/alternative; boundary=047d7b5d853106e3e804dfb254ff X-Gm-Message-State: ALoCoQkX3JmGI8ZASHwhgPORVtygpInNYX1gK0U2AU0b/L/g3qKL2kMnSZ9WSI+NG9hcyPazqKY2 Cc: Carsten Bormann , Paul Hoffman , JSON WG Subject: Re: [Json] Consensus call: establishing name equality X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 21 Jun 2013 23:22:00 -0000 --047d7b5d853106e3e804dfb254ff Content-Type: text/plain; charset=UTF-8 On Fri, Jun 21, 2013 at 4:15 PM, Jacob Davies wrote: > > Is this definition of equality needed elsewhere in the document though? > Standing alone it seems a little odd - there's no discussion how to compare > two numbers, two objects, or two lists for equality, so why are > strings-used-for-names special? > Because - We talk about duplicates so it's important to define what duplicate means - they are, in effect, hash-table keys, so comparison really matters --047d7b5d853106e3e804dfb254ff Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Jun 21, 2013 at 4:15 PM, Jacob Davies <jacob@well.com> wrot= e:

=
Is this definition of equality needed elsewhere in the document though= ? Standing alone it seems a little odd - there's no discussion how to c= ompare two numbers, two objects, or two lists for equality, so why are stri= ngs-used-for-names special?

Because
- We talk ab= out duplicates so it's important to define what duplicate means
- th= ey are, in effect, hash-table keys, so comparison really matters

--047d7b5d853106e3e804dfb254ff-- From jsontest@yahoo.com Fri Jun 21 16:43:29 2013 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 4AA7621F9ED4 for ; Fri, 21 Jun 2013 16:43:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.526 X-Spam-Level: X-Spam-Status: No, score=0.526 tagged_above=-999 required=5 tests=[AWL=-0.131, BAYES_20=-0.74, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JP1DGg0TmYab for ; Fri, 21 Jun 2013 16:43:23 -0700 (PDT) Received: from nm6.bullet.mail.bf1.yahoo.com (nm6.bullet.mail.bf1.yahoo.com [98.139.212.165]) by ietfa.amsl.com (Postfix) with ESMTP id 0D7AA21F9ED8 for ; Fri, 21 Jun 2013 16:43:20 -0700 (PDT) Received: from [98.139.212.151] by nm6.bullet.mail.bf1.yahoo.com with NNFMP; 21 Jun 2013 23:43:20 -0000 Received: from [98.139.211.160] by tm8.bullet.mail.bf1.yahoo.com with NNFMP; 21 Jun 2013 23:43:20 -0000 Received: from [127.0.0.1] by smtp217.mail.bf1.yahoo.com with NNFMP; 21 Jun 2013 23:43:20 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1371858200; bh=BvRajVL3QPRlHVgLtq/HUUBhaQUTZkPqvvnPCRGarMo=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:References:In-Reply-To:Mime-Version:Content-Type:Content-Transfer-Encoding:Message-Id:Cc:X-Mailer:From:Subject:Date:To; b=t9kJSlow9/8dgZUIwGtj+ia27BBWpxbWrpFX9M3dBNG87WgnlAfDd84ORnuzewPJluv3JlhMSNQSi5pbaJUKW7I1nDNF/ZfUxmpuoHB7md96S15DcCK06fusF5ev+QX4x76zJpBlCU0aCvjqlswDfQLyz+vDjsQO/9MYrXIAU2g= X-Yahoo-Newman-Id: 420313.97558.bm@smtp217.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: 1kd3OMwVM1lz1zoGjErKINdB4qxnimRGFfyFRY8harqlkb4 2VbdmIuM8moQA6h1SPNHdvQ6Z6FjjAjHS702fyXva039CCDXtobT0SLRh8ol CucdeUAaZkLIfyDRTf2upTCeKucaqhsPw71zsCT0vtTRGldo6rObveVjfolX aj0JW61p1cJYKlrXSVm4H_T8rKLCeoH5A0tKAdZf4Mj4tX6s8jRICgcd0n0Y aVXyttoPhaZ1g.t2z0LddrdxEwMJvAqcl9qldPHmvo4lIfNVk_7Z2Z5_x2oC ncLeIfGWslEBMCEtpsSZACFRZpx_.twiTImt5yRZRys9xuG7P8zWbZWl17Mg zKB3PcawaCK4ocDqIedCGeuxxDm6imoFIxW2EtVwM_vy.NRmjCF6g_zBWaLR cJqB2xXyxpzz6GHc5z79O3QT_c9PwcHzb1Ui6SHUdIPBhARprIT2SV.iPB7W ZglsyQKGW4egkY0Ma9DJlzujcuaWryZvI_gaZpQGco58bWhwf6jgGemjiizJ RMIcUtdTPul1uI7QFmkJzIrwf X-Yahoo-SMTP: indQcmSswBC8IKsm6t4aCAPskK3T X-Rocket-Received: from [192.168.0.102] (jsontest@76.29.100.42 with ) by smtp217.mail.bf1.yahoo.com with SMTP; 21 Jun 2013 16:43:20 -0700 PDT References: <6BCAAC4F-2B45-43BA-A40B-96F3369A5851@tzi.org> In-Reply-To: Mime-Version: 1.0 (1.0) Content-Type: multipart/alternative; boundary=Apple-Mail-B8C93012-B4E5-44B2-AAAA-FEA614A0964D Content-Transfer-Encoding: 7bit Message-Id: <5105FF78-F926-4ED4-A923-026DCAFD6674@yahoo.com> X-Mailer: iPod Mail (9B206) From: Vinny A Date: Fri, 21 Jun 2013 18:43:17 -0500 To: Jacob Davies Cc: Carsten Bormann , Tim Bray , Paul Hoffman , JSON WG Subject: Re: [Json] Consensus call: establishing name equality X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 21 Jun 2013 23:43:29 -0000 --Apple-Mail-B8C93012-B4E5-44B2-AAAA-FEA614A0964D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Jun 21, 2013, at 6:15 PM, Jacob Davies wrote: > On Fri, Jun 21, 2013 at 3:29 PM, Tim Bray wrote: > Hm, I think this is useful. I=E2=80=99ve seen people go off the rails try= ing to be overly clever comparing strings, so this in effect is just telling= them not to overthink. -T >=20 > Is this definition of equality needed elsewhere in the document though? St= anding alone it seems a little odd - there's no discussion how to compare tw= o numbers, two objects, or two lists for equality, so why are strings-used-f= or-names special? View this as more of a constraint on names, not on strings in general. It's i= mportant to set expectations here, as implementations have to convert JSON i= nto maps. On Jun 21, 2013, at 11:42 AM, Paul Hoffman wrote: > =20 > Please respond to this message with a list of proposals you could accept, o= rdered from highest to lowest. Do not list proposals you cannot live with. I= f you cannot accept any of the proposals, please respond and say why. 3 =3D 1 > 2 I can't live with option 0, as I think there needs to be more clarification i= n regards to names, name comparison, and conversion to language-specific map= s. ----------------- Vinny www.jsontest.com --Apple-Mail-B8C93012-B4E5-44B2-AAAA-FEA614A0964D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Jun= 21, 2013, at 6:15 PM, Jacob Davies <ja= cob@well.com> wrote:
On Fri, Jun 21, 2013 at 3:29 PM, Tim Bray <tbray@text= uality.com> wrote:
Hm, I think this is useful.&n= bsp; I=E2=80=99ve seen people go off the rails trying to be overly clever co= mparing strings, so this in effect is just telling them not to overthink. -T=

Is this definition of equality n= eeded elsewhere in the document though? Standing alone it seems a little odd= - there's no discussion how to compare two numbers, two objects, or two lis= ts for equality, so why are strings-used-for-names special?

View this as more of a constraint on name= s, not on strings in general. It's important to set expectations here, as im= plementations have to convert JSON into maps.


On J= un 21, 2013, at 11:42 AM, Paul Hoffman <paul.hoffman@vpnc.org> wrote:
 
Please respond to this mess= age with a list of proposals you could accept, ordered from highest to lowes= t. Do not list proposals you cannot live with. If you cannot accept any of t= he proposals, please respond and say why.

3 =3D 1 > 2

= I can't live with option 0, as I think there needs to be more clarification i= n regards to names, name comparison, and conversion to language-specific map= s.


-----------------
Vinny
<= span>
= --Apple-Mail-B8C93012-B4E5-44B2-AAAA-FEA614A0964D-- From ietf@lindenbergsoftware.com Fri Jun 21 16:45:32 2013 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 2813421F9EDF for ; Fri, 21 Jun 2013 16:45:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.795 X-Spam-Level: X-Spam-Status: No, score=-3.795 tagged_above=-999 required=5 tests=[AWL=-0.196, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O3fDCM+uY5e9 for ; Fri, 21 Jun 2013 16:45:27 -0700 (PDT) Received: from mirach.lunarpages.com (mirach.lunarpages.com [216.97.235.70]) by ietfa.amsl.com (Postfix) with ESMTP id 762C221F9EE0 for ; Fri, 21 Jun 2013 16:45:27 -0700 (PDT) Received: from 50-0-136-241.dsl.dynamic.sonic.net ([50.0.136.241]:58273 helo=[192.168.0.5]) by mirach.lunarpages.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1UqB1A-002776-Au; Fri, 21 Jun 2013 16:45:24 -0700 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Norbert Lindenberg In-Reply-To: Date: Fri, 21 Jun 2013 16:45:20 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <6BCAAC4F-2B45-43BA-A40B-96F3369A5851@tzi.org> To: Tim Bray X-Mailer: Apple Mail (2.1283) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - mirach.lunarpages.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - lindenbergsoftware.com X-Get-Message-Sender-Via: mirach.lunarpages.com: authenticated_id: ietf@lindenbergsoftware.com Cc: Norbert Lindenberg , Carsten Bormann , Jacob Davies , Paul Hoffman , JSON WG Subject: Re: [Json] Consensus call: establishing name equality X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 21 Jun 2013 23:45:32 -0000 On Jun 21, 2013, at 16:21 , Tim Bray wrote: > On Fri, Jun 21, 2013 at 4:15 PM, Jacob Davies wrote: >=20 > Is this definition of equality needed elsewhere in the document = though? Standing alone it seems a little odd - there's no discussion how = to compare two numbers, two objects, or two lists for equality, so why = are strings-used-for-names special? >=20 > Because=20 > - We talk about duplicates so it's important to define what duplicate = means Correct - section 2.2, "The names within an object SHOULD be unique." > - they are, in effect, hash-table keys, so comparison really matters That seems out of scope for the spec - the spec may cover the output of = the parser, but not what clients do with the output. We can't stop = clients from treating names as case insensitive, for example. However, the comment that eventually led to this proposal was actually = about a somewhat different problem [1]: > It should say explicitly that these three all produce exactly the same = result: > "\u002F" > "\/" > "/" >=20 > I have seen confusion about this. This comment is about how the parser interprets JSON text and what its = output is. The three input strings shown, as well as "\u002f", should = all result in an output string containing the single code point U+002F. This important information seems to have gotten lost in the subsequent = discussion. To say that the four input strings must be considered equivalent then = becomes unnecessary because they result in the same name. [1] http://www.ietf.org/mail-archive/web/json/current/msg00372.html Norbert From cromis@gmail.com Fri Jun 21 16:55:09 2013 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 3AE0321F9EF3 for ; Fri, 21 Jun 2013 16:55:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.885 X-Spam-Level: X-Spam-Status: No, score=-1.885 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CXgnH8MXve9G for ; Fri, 21 Jun 2013 16:55:08 -0700 (PDT) Received: from mail-qc0-x229.google.com (mail-qc0-x229.google.com [IPv6:2607:f8b0:400d:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id 7CCB921F9EE0 for ; Fri, 21 Jun 2013 16:55:08 -0700 (PDT) Received: by mail-qc0-f169.google.com with SMTP id c10so5171679qcz.28 for ; Fri, 21 Jun 2013 16:55:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=b6iD5yCRbK4KxEeUWsPzfdvhcdN8P4yayknsUyjpK0g=; b=ZZrw3Z6YOSfrSFElEklwMLQvrg7J+DDiXo76jI8+MbGA6M4fUDtP63EwncSfghcnSQ rUXrkS/vTgsqWf29eeaz/rlSqnlcAcz8dcAE6pgoLK7l8yQkooAXSNKRWlaguVpPqYBb m3lI0XCi1PhRBUTIBw6yyZuc32ZHdQUYRJBJxTGdU74sEJKvcBKP+DZp5LgxI7UJS836 eRbIyzUP3NQwuXovCBpqptrG9fG03CR/X9fmJWHhSCGVjwC0MWR1UA3+2yaBbY7AVbw1 kBYTu7wAyK/EPlRIMFvHuhnU7Yw6tOBuUEILWfNEY2Jy7heqTg8x0RJM8wPEYmciQPpx KpfQ== X-Received: by 10.49.116.79 with SMTP id ju15mr17231747qeb.2.1371858907879; Fri, 21 Jun 2013 16:55:07 -0700 (PDT) MIME-Version: 1.0 Sender: cromis@gmail.com Received: by 10.49.76.42 with HTTP; Fri, 21 Jun 2013 16:54:47 -0700 (PDT) In-Reply-To: References: <6BCAAC4F-2B45-43BA-A40B-96F3369A5851@tzi.org> From: Jacob Davies Date: Fri, 21 Jun 2013 16:54:47 -0700 X-Google-Sender-Auth: _LTzDGEpOW9mYtYTJa_iPrWncDM Message-ID: To: Tim Bray Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: Carsten Bormann , Paul Hoffman , JSON WG Subject: Re: [Json] Consensus call: establishing name equality X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 21 Jun 2013 23:55:09 -0000 Well, even given those givens, what about this: http://www.unicode.org/versions/Unicode6.2.0/ch03.pdf >From Section 3.2: C6 A process shall not assume that the interpretations of two canonical-equivalent character sequences are distinct. =95 The implications of this conformance clause are twofold. First, a process is never required to give different interpretations to two different, but canonical-equivalent character sequences. Second, no process can assume that another process will make a distinction between two different, but canonical-equivalent character sequences. =95 Ideally, an implementation would always interpret two canonical-equivalent character sequences identically. There are practical circumstances under which implementations may reasonably distinguish them. --- That argues pretty strongly against specifying name normalization behavior for implementations, I would think. Back on the point of what this is for: yes, JSON names in objects are likely used as hash keys. But the specification itself does not *require* that they be unique (it advises, yes) and therefore no absolutely unambiguous definition of what "unique" means is necessary within the specification. The specification is already clear that a name is a string, and that backslashed characters in JSON-encoded strings are to be interpreted in certain ways to produce a native string; how to hash and compare strings is really a platform function, not a decoding function. It seems unnecessary to say that the four given strings for the slash character are equivalent: if you have followed the instructions on interpreting strings, they already will be by the time you get around to comparing them. On Fri, Jun 21, 2013 at 4:21 PM, Tim Bray wrote: > > On Fri, Jun 21, 2013 at 4:15 PM, Jacob Davies wrote: >> >> >> Is this definition of equality needed elsewhere in the document though? = Standing alone it seems a little odd - there's no discussion how to compare= two numbers, two objects, or two lists for equality, so why are strings-us= ed-for-names special? > > > Because > - We talk about duplicates so it's important to define what duplicate mea= ns > - they are, in effect, hash-table keys, so comparison really matters > From paul.hoffman@vpnc.org Fri Jun 21 17:15:03 2013 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 EB2E621E805E for ; Fri, 21 Jun 2013 17:15:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.517 X-Spam-Level: X-Spam-Status: No, score=-102.517 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EmDDgF5sKkbw for ; Fri, 21 Jun 2013 17:15:03 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 20C7711E80C5 for ; Fri, 21 Jun 2013 17:15:03 -0700 (PDT) Received: from [10.20.30.90] (50-0-66-165.dsl.dynamic.sonic.net [50.0.66.165]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r5M0F077054619 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 21 Jun 2013 17:15:01 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Paul Hoffman In-Reply-To: Date: Fri, 21 Jun 2013 17:14:59 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <6BCAAC4F-2B45-43BA-A40B-96F3369A5851@tzi.org> To: JSON WG X-Mailer: Apple Mail (2.1508) Subject: Re: [Json] Consensus call: establishing name equality X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 22 Jun 2013 00:15:04 -0000 On Jun 21, 2013, at 3:23 PM, Jacob Davies wrote: > What is the problem this is seeking to solve again? Some people want to compare names for objects. The current draft says: The names within an object SHOULD be unique. If either a generator or parsers wants to follow that rule (as some do), = some people in the WG feel that there needs to be a standard way to do = so. This call is to determine how to do that, or whether to try. --Paul Hoffman= From cromis@gmail.com Fri Jun 21 17:58:46 2013 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 4BBA721E804B for ; Fri, 21 Jun 2013 17:58:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id woTnkxkoWJDS for ; Fri, 21 Jun 2013 17:58:46 -0700 (PDT) Received: from mail-qc0-x230.google.com (mail-qc0-x230.google.com [IPv6:2607:f8b0:400d:c01::230]) by ietfa.amsl.com (Postfix) with ESMTP id CB89811E80E3 for ; Fri, 21 Jun 2013 17:58:45 -0700 (PDT) Received: by mail-qc0-f176.google.com with SMTP id z10so5059743qcx.7 for ; Fri, 21 Jun 2013 17:58:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=uSI/sWZO1MgTqU2NlptFFZw1Ab15+jExLOEWAYPND18=; b=jkpJlLs0WvaVvqxBoSjl5SjbwWeXKyQWr6IBp7eBPS6Kk+ozFLCp3lxXxc5z/SeB12 RkpvWJmabxGDEvHsTUfaETDA6XXMypyLWOzg879u2VvOF5LUEuy5A+yWGZsJeZJNYZG9 xPdKI21plJCuerIS8HvaUXferBSVg/jC7Onm8GfKlHLghGdexFhrjbrhgLCs5kmFBUIm 2mOWel5ZpzHxw4ruSEx80C8hWOLdi9y9WJ8og5ZbjkPgTG+6L3qh84vvFMpSJczIopj6 2Q7BSO0woR12QE6hfVMt6thIaoMROWCiu712PPVJmDUnTUXGP5NSofuS9UUIKm43GuY1 9o3w== X-Received: by 10.49.127.196 with SMTP id ni4mr9302628qeb.5.1371862725269; Fri, 21 Jun 2013 17:58:45 -0700 (PDT) MIME-Version: 1.0 Sender: cromis@gmail.com Received: by 10.49.76.42 with HTTP; Fri, 21 Jun 2013 17:58:25 -0700 (PDT) In-Reply-To: <20130622005014.GA31186@mercury.ccil.org> References: <6BCAAC4F-2B45-43BA-A40B-96F3369A5851@tzi.org> <20130622005014.GA31186@mercury.ccil.org> From: Jacob Davies Date: Fri, 21 Jun 2013 17:58:25 -0700 X-Google-Sender-Auth: N9cdh3d8I4FNNw-9oj4_zdP7vKE Message-ID: To: John Cowan Content-Type: text/plain; charset=ISO-8859-1 Cc: Carsten Bormann , Tim Bray , Paul Hoffman , JSON WG Subject: Re: [Json] Consensus call: establishing name equality X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 22 Jun 2013 00:58:46 -0000 On Fri, Jun 21, 2013 at 5:50 PM, John Cowan wrote: > JSON, like XML, does not assume they are distinct: it decides that they > are distinct. This is what in Unicode is called a higher-order protocol. Hm, OK. > SHOULD is rather more than advice. Quoth RFC 2119: "This word, or > the adjective "RECOMMENDED", mean that there may exist valid reasons > in particular circumstances to ignore a particular item, but the full > implications must be understood and carefully weighed before choosing > a different course." > > If JSON document, generator, or parser authors choose to ignore this > stipulation, they need to know what it is they are choosing not to do. Okey dokes. Then: 2, 3, 1, 0 From ietf@lindenbergsoftware.com Fri Jun 21 18:09:46 2013 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 BAAF721E8097 for ; Fri, 21 Jun 2013 18:09:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.782 X-Spam-Level: X-Spam-Status: No, score=-3.782 tagged_above=-999 required=5 tests=[AWL=-0.183, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LPYRkj6Ov11Z for ; Fri, 21 Jun 2013 18:09:40 -0700 (PDT) Received: from mirach.lunarpages.com (mirach.lunarpages.com [216.97.235.70]) by ietfa.amsl.com (Postfix) with ESMTP id D018E11E80A2 for ; Fri, 21 Jun 2013 18:09:40 -0700 (PDT) Received: from 50-0-136-241.dsl.dynamic.sonic.net ([50.0.136.241]:50052 helo=[192.168.0.5]) by mirach.lunarpages.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1UqCKf-002Osq-5g; Fri, 21 Jun 2013 18:09:37 -0700 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=utf-8 From: Norbert Lindenberg In-Reply-To: <20130622005330.GD31186@mercury.ccil.org> Date: Fri, 21 Jun 2013 18:09:32 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <0E535EF2-E08E-4974-A01E-5E4BBB7A077E@lindenbergsoftware.com> References: <9E497099-2B5B-4256-B066-C2E77B558267@vpnc.org> <339F1E4A-5D5F-481E-AF4D-42477A07F50F@lindenbergsoftware.com> <20130622005330.GD31186@mercury.ccil.org> To: John Cowan X-Mailer: Apple Mail (2.1283) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - mirach.lunarpages.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - lindenbergsoftware.com X-Get-Message-Sender-Via: mirach.lunarpages.com: authenticated_id: ietf@lindenbergsoftware.com Cc: Norbert Lindenberg , Paul Hoffman , JSON WG Subject: Re: [Json] Consensus call: ABNF nits X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 22 Jun 2013 01:09:46 -0000 On Jun 21, 2013, at 17:53 , John Cowan wrote: > Norbert Lindenberg scripsit: >=20 >>> HEXDIG =3D DIGIT / %x41-46 / %x61-66 ; 0-9, A-F, or a-f >>> ; HEXDIG equivalent to HEXDIG rule in [RFC5234] >>=20 >> To complete the effort of disambiguating Unicode characters in the >> grammar, the comment should include "U+0030 through U+0039, U+0041 >> through U+0046, U+0061 through U+0066". We don't want them to be >> confused with =EF=BC=90-=EF=BC=99, =EF=BC=A1-=EF=BC=A6, or =EF=BD=81-=EF= =BD=86. >=20 > I fail to see what U+0041 says that %x41 does not already say. By that logic many of the ABNF comments are unnecessary. Norbert= From cowan@ccil.org Fri Jun 21 18:12:31 2013 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 3995121F9982 for ; Fri, 21 Jun 2013 18:12:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.468 X-Spam-Level: X-Spam-Status: No, score=-3.468 tagged_above=-999 required=5 tests=[AWL=0.131, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FPBiO5H7-k9h for ; Fri, 21 Jun 2013 18:12:22 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id 8E49E11E80A2 for ; Fri, 21 Jun 2013 18:12:22 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1UqC1u-0002bB-S7; Fri, 21 Jun 2013 20:50:14 -0400 Date: Fri, 21 Jun 2013 20:50:14 -0400 From: John Cowan To: Jacob Davies Message-ID: <20130622005014.GA31186@mercury.ccil.org> References: <6BCAAC4F-2B45-43BA-A40B-96F3369A5851@tzi.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Cc: Carsten Bormann , Tim Bray , Paul Hoffman , JSON WG Subject: Re: [Json] Consensus call: establishing name equality X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 22 Jun 2013 01:12:31 -0000 Jacob Davies scripsit: > C6 A process shall not assume that the interpretations of two > canonical-equivalent character sequences are distinct. JSON, like XML, does not assume they are distinct: it decides that they are distinct. This is what in Unicode is called a higher-order protocol. > Back on the point of what this is for: yes, JSON names in objects are > likely used as hash keys. But the specification itself does not > *require* that they be unique (it advises, yes) and therefore no > absolutely unambiguous definition of what "unique" means is necessary > within the specification. SHOULD is rather more than advice. Quoth RFC 2119: "This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course." If JSON document, generator, or parser authors choose to ignore this stipulation, they need to know what it is they are choosing not to do. -- Is not a patron, my Lord [Chesterfield], John Cowan one who looks with unconcern on a man http://www.ccil.org/~cowan struggling for life in the water, and when cowan@ccil.org he has reached ground encumbers him with help? --Samuel Johnson From cowan@ccil.org Fri Jun 21 18:12:31 2013 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 7D70A11E80D3 for ; Fri, 21 Jun 2013 18:12:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.471 X-Spam-Level: X-Spam-Status: No, score=-3.471 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iMwNjghL9ZC0 for ; Fri, 21 Jun 2013 18:12:23 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id 6FC9521F969F for ; Fri, 21 Jun 2013 18:12:23 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1UqC54-0002oI-CN; Fri, 21 Jun 2013 20:53:30 -0400 Date: Fri, 21 Jun 2013 20:53:30 -0400 From: John Cowan To: Norbert Lindenberg Message-ID: <20130622005330.GD31186@mercury.ccil.org> References: <9E497099-2B5B-4256-B066-C2E77B558267@vpnc.org> <339F1E4A-5D5F-481E-AF4D-42477A07F50F@lindenbergsoftware.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <339F1E4A-5D5F-481E-AF4D-42477A07F50F@lindenbergsoftware.com> User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Cc: Paul Hoffman , JSON WG Subject: Re: [Json] Consensus call: ABNF nits X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 22 Jun 2013 01:12:31 -0000 Norbert Lindenberg scripsit: > > HEXDIG = DIGIT / %x41-46 / %x61-66 ; 0-9, A-F, or a-f > > ; HEXDIG equivalent to HEXDIG rule in [RFC5234] > > To complete the effort of disambiguating Unicode characters in the > grammar, the comment should include "U+0030 through U+0039, U+0041 > through U+0046, U+0061 through U+0066". We don't want them to be > confused with ï¼-ï¼™, Ａ-Ｆ, or ï½-ｆ. I fail to see what U+0041 says that %x41 does not already say. -- With techies, I've generally found John Cowan If your arguments lose the first round http://www.ccil.org/~cowan Make it rhyme, make it scan cowan@ccil.org Then you generally can Make the same stupid point seem profound! --Jonathan Robie From cowan@ccil.org Fri Jun 21 18:22:53 2013 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 EEC251F0D3E for ; Fri, 21 Jun 2013 18:22:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.467 X-Spam-Level: X-Spam-Status: No, score=-2.467 tagged_above=-999 required=5 tests=[AWL=-0.880, BAYES_00=-2.599, FAKE_REPLY_C=2.012, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o1E4gjhfaPas for ; Fri, 21 Jun 2013 18:22:48 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id 9431A1F0D35 for ; Fri, 21 Jun 2013 18:22:48 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1UqCXP-0005tF-Aa for json@ietf.org; Fri, 21 Jun 2013 21:22:47 -0400 Date: Fri, 21 Jun 2013 21:22:47 -0400 From: John Cowan To: json@ietf.org Message-ID: <20130622012247.GF31186@mercury.ccil.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Subject: Re: [Json] Consensus call: establishing name equality X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 22 Jun 2013 01:22:53 -0000 Paul Hoffman scripsit: > There are four proposals for establishing name equality: All four are unacceptable to me, by reason of the phrase "numeric character code points", which can be read as "code points for numeric characters", in 1-3. If that is corrected, then 3 > 2 > 1. -- Andrew Watt on Microsoft: John Cowan Never in the field of human computing cowan@ccil.org has so much been paid by so many http://www.ccil.org/~cowan to so few! (pace Winston Churchill) From jsontest@yahoo.com Fri Jun 21 18:23:46 2013 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 676491F0D3D for ; Fri, 21 Jun 2013 18:23:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.382 X-Spam-Level: X-Spam-Status: No, score=-0.382 tagged_above=-999 required=5 tests=[AWL=0.821, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pfsp9eTUYPiv for ; Fri, 21 Jun 2013 18:23:34 -0700 (PDT) Received: from nm16.bullet.mail.bf1.yahoo.com (nm16.bullet.mail.bf1.yahoo.com [98.139.212.175]) by ietfa.amsl.com (Postfix) with ESMTP id C6E481F0D3B for ; Fri, 21 Jun 2013 18:23:31 -0700 (PDT) Received: from [66.196.81.172] by nm16.bullet.mail.bf1.yahoo.com with NNFMP; 22 Jun 2013 01:23:30 -0000 Received: from [98.139.211.160] by tm18.bullet.mail.bf1.yahoo.com with NNFMP; 22 Jun 2013 01:23:30 -0000 Received: from [127.0.0.1] by smtp217.mail.bf1.yahoo.com with NNFMP; 22 Jun 2013 01:23:30 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1371864210; bh=wLwh1AMXQjD9z+gH9C3rho33rqfwkQUwPUBhWxhJTpE=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:Subject:References:From:Content-Type:X-Mailer:In-Reply-To:Message-Id:Date:To:Content-Transfer-Encoding:Mime-Version; b=TG7lrMgVMTPcTonfTL8tf5Td23YV6HFuOg0FRaHs+rY2aX4LrbZA3LL8xUuRPFvYpM24LYZHEH7dV8maLc06r1Qa0JfQ3wtcMWyqaSrr6LqL4p6kAIoECJAi14QNbZ3rsTNNu/uhZnKSXt6EFn1Mm4mn5GPtgAl1IMmh+OuvUoQ= X-Yahoo-Newman-Id: 397778.11751.bm@smtp217.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: yQT856MVM1ka_VrndG7P0wAbpzJpm6j_8FUEgqQ0A7PLcMN 0ZEKohsgzpOO0EiQ6mVOqYGvEDrpB3iX.Dn5q0sPxnsSTe.bjNtM.WtvR.zX kNSEG2UUzCkQsZbFVBRGFfl4UKj06V8x57DKnVLrYBdMjFkNf4Mj3BcS6Rz0 RfXWzy812qnss9KY4N8qiRpWfkO2XoR8LMWcJDBPNrZMV4VH3VyzUqGXXoW1 dj7phoys1HNFyU1rPvX3pdb3tLx81S8m.JvBNYPwAd7tmQx6nG6jO.tE_LIZ 5h1te.e9HzbVo9eskURC4vGcerfiDoQIo4fZh5EiS1IMODkSXXl59Swm3thp ClS59hlOWuGWgwrF1WSu95EE02ASdCd.horW.WCnFJ9fH1zFa_Py05xOCvW4 _JyrphgSLDUQ19y8dcPhDoDEYJ2ZALg_bnT2tCZi7zY3cUKR7CZv67kI.yO2 Fff.B_PwfhDud.sJanJdwz_X8W.XwBuhaLy6L81cDN2vdGmfE3cKMlLVc8aE Q5hMNV8goUBZezH3B0RWvJwMC X-Yahoo-SMTP: indQcmSswBC8IKsm6t4aCAPskK3T X-Rocket-Received: from [192.168.0.102] (jsontest@76.29.100.42 with ) by smtp217.mail.bf1.yahoo.com with SMTP; 21 Jun 2013 18:23:30 -0700 PDT References: <90B659B8-D4AC-41AF-8C06-67FC65C8BD74@vpnc.org> From: Vinny A Content-Type: text/plain; charset=us-ascii X-Mailer: iPod Mail (9B206) In-Reply-To: <90B659B8-D4AC-41AF-8C06-67FC65C8BD74@vpnc.org> Message-Id: Date: Fri, 21 Jun 2013 20:23:29 -0500 To: JSON WG Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) Subject: Re: [Json] Consensus call: document title X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 22 Jun 2013 01:23:46 -0000 On Jun 21, 2013, at 11:38 AM, Paul Hoffman wrote: > There are three proposals for dealing with the document title: > 0) Leave the title in the current draft as-is: > The application/json Media Type for JavaScript Object Notation (JSON) > 1) Change the title to > The JSON Data Interchange Format > 2) Change the title to > The JSON Format for Encoding Data >=20 > Please respond to this message with a list of proposals you could accept, o= rdered from highest to lowest. Do not list proposals you cannot live with. I= f you cannot accept any of the proposals, please respond and say why. 1 >>> 2 > 0 1 is by far the best. 2 is still acceptable, while 0 is completely unaccepta= ble ( we're trying to move away from JSON's JS origins, aren't we?) ----------------- Vinny www.jsontest.com From cowan@ccil.org Fri Jun 21 18:27:23 2013 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 5415A21F9B17 for ; Fri, 21 Jun 2013 18:27:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.457 X-Spam-Level: X-Spam-Status: No, score=-3.457 tagged_above=-999 required=5 tests=[AWL=0.142, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W7DRku59KhOM for ; Fri, 21 Jun 2013 18:27:16 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id D50DB21F9AFE for ; Fri, 21 Jun 2013 18:27:14 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1UqCbh-0006IE-FV; Fri, 21 Jun 2013 21:27:13 -0400 Date: Fri, 21 Jun 2013 21:27:13 -0400 From: John Cowan To: Norbert Lindenberg Message-ID: <20130622012713.GH31186@mercury.ccil.org> References: <9E497099-2B5B-4256-B066-C2E77B558267@vpnc.org> <339F1E4A-5D5F-481E-AF4D-42477A07F50F@lindenbergsoftware.com> <20130622005330.GD31186@mercury.ccil.org> <0E535EF2-E08E-4974-A01E-5E4BBB7A077E@lindenbergsoftware.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0E535EF2-E08E-4974-A01E-5E4BBB7A077E@lindenbergsoftware.com> User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Cc: Paul Hoffman , JSON WG Subject: Re: [Json] Consensus call: ABNF nits X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 22 Jun 2013 01:27:23 -0000 Norbert Lindenberg scripsit: > > I fail to see what U+0041 says that %x41 does not already say. > > By that logic many of the ABNF comments are unnecessary. Quite so. But the fact that we have some commentary that violates the DRY rule is not an argument for adding yet more commentary that violates it. -- Cash registers don't really add and subtract; John Cowan they only grind their gears. cowan@ccil.org But then they don't really grind their gears, either; they only obey the laws of physics. --Unknown From jhildebr@cisco.com Fri Jun 21 18:32:45 2013 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 EDDC61F0D40 for ; Fri, 21 Jun 2013 18:32:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BVMM547tZWEC for ; Fri, 21 Jun 2013 18:32:41 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 171451F0D3B for ; Fri, 21 Jun 2013 18:32:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=883; q=dns/txt; s=iport; t=1371864757; x=1373074357; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=5IvLh4CJjoSERgVxLawSLyfd63EAm4H3UulO8cg4ypI=; b=N2Z2qsQu+BEVaHKFkcMA2QJN8ZDkVCoIsDZCy7P9AG9NlDY/5wR6PXka Jbxv2UK/tgdI779HjSTr7i6SPqTOLyZRYvkiZVCtrg2/VrkI1o46hGoEb Ucju6bL6ODygsUYSk7lu49iYunKJF8xdVIxmLxUKHqZHC6ciegK4IomZh w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmAFAK/9xFGtJV2c/2dsb2JhbABbgwkxSYI8vH2BAhZ0giUBBDo/EgEIDhQUQiUCBAENBQgBiAUMvAaPGDEHgwBhA6kHgw+CKA X-IronPort-AV: E=Sophos;i="4.87,916,1363132800"; d="scan'208";a="226015720" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-8.cisco.com with ESMTP; 22 Jun 2013 01:32:36 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r5M1WW20021761 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 22 Jun 2013 01:32:32 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.56]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.02.0318.004; Fri, 21 Jun 2013 20:32:32 -0500 From: "Joe Hildebrand (jhildebr)" To: Norbert Lindenberg , Paul Hoffman Thread-Topic: [Json] Consensus call: ABNF nits Thread-Index: AQHObp4GCg0C1hAwXU6c6yl/pmiq4plA2MEAgAAJ9wA= Date: Sat, 22 Jun 2013 01:32:31 +0000 Message-ID: In-Reply-To: <339F1E4A-5D5F-481E-AF4D-42477A07F50F@lindenbergsoftware.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.5.130515 x-originating-ip: [10.21.93.139] Content-Type: text/plain; charset="us-ascii" Content-ID: <640F92DCA207FA4C977D60779422F82F@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: JSON WG Subject: Re: [Json] Consensus call: ABNF nits X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 22 Jun 2013 01:32:46 -0000 On 6/21/13 12:56 PM, "Norbert Lindenberg" wrote: >>escape =3D %x5C ; \ U+005C >> quotation-mark =3D %x22 ; " U+0022 >> unescaped =3D %x20-21 / %x23-5B / %x5D-10FFFF ; any Unicode scalar >> ; value, except those that must be escaped (C0 control >> ; characters, "QUOTATION MARK" [U+0022], and "REVERSE SOLIDUS" >> ; [U+005C]) > >Describing "unescaped" as "any Unicode scalar value, except..." is wrong. >The correct term is "Unicode code point". Unicode scalar values do not >include the range U+D800 through U+DFFFF. >http://www.unicode.org/glossary/#unicode_scalar_value The posted ABNF for option 1 didn't get the last change that I proposed: unescaped =3D %x20-21 / %x23-5B / %x5D-D7FF / %xE000-10FFFF which would make the comment correct. I like option 1 with that fix. --=20 Joe Hildebrand From cowan@ccil.org Fri Jun 21 18:37:56 2013 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 B8E6C1F0D3B for ; Fri, 21 Jun 2013 18:37:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.453 X-Spam-Level: X-Spam-Status: No, score=-2.453 tagged_above=-999 required=5 tests=[AWL=-0.866, BAYES_00=-2.599, FAKE_REPLY_C=2.012, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sEj2XwJ68aAM for ; Fri, 21 Jun 2013 18:37:52 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id 6CF391F0D38 for ; Fri, 21 Jun 2013 18:37:52 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1UqClz-0007HF-Rr for json@ietf.org; Fri, 21 Jun 2013 21:37:51 -0400 Date: Fri, 21 Jun 2013 21:37:51 -0400 From: John Cowan To: json@ietf.org Message-ID: <20130622013751.GJ31186@mercury.ccil.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Subject: Re: [Json] Consensus call: establishing name equality X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 22 Jun 2013 01:37:56 -0000 Carsten Bormann scripsit: > Hmm, a bit too much MUSTard for my taste. Only the first MUST in 1 > is really needed. Not so, and for this reason: in 1 and 2 it says "comparisons MUST be conducted, after all unescaping is done, by comparing" etc. That does not positively require that unescaping be done. It can be read as "comparisons MUST be conducted, after all unescaping is done (if it is done at all)". Only 3 positively requires unescaping to be done before comparing. It has been said that a standard (and this is a Standards Track RFC) is a contract between the implementer and the user. We ought not to disregard the possibility that some implementers will be acting in bad faith, trying to find whatever loopholes they can, and that some users will be suing them for non-compliance. Insofar as any form of words can capture it, we should make sure that implementers MUST do what users can properly expect them to do. So why didn't I say that I couldn't live with 1 or 2, you may wonder? Because I'm willing to swallow a certain amount of lack of precision in the search for consensus. -- You are a child of the universe no less John Cowan than the trees and all other acyclic http://www.ccil.org/~cowan graphs; you have a right to be here. cowan@ccil.org --DeXiderata by Sean McGrath From cowan@ccil.org Fri Jun 21 18:39:25 2013 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 0ABE921E80AF for ; Fri, 21 Jun 2013 18:39:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.444 X-Spam-Level: X-Spam-Status: No, score=-3.444 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M0IztlND4Y1Q for ; Fri, 21 Jun 2013 18:39:20 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id D8A2121E80AE for ; Fri, 21 Jun 2013 18:39:17 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1UqCnF-0007P4-P1; Fri, 21 Jun 2013 21:39:09 -0400 Date: Fri, 21 Jun 2013 21:39:09 -0400 From: John Cowan To: "Joe Hildebrand (jhildebr)" Message-ID: <20130622013909.GK31186@mercury.ccil.org> References: <339F1E4A-5D5F-481E-AF4D-42477A07F50F@lindenbergsoftware.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Cc: Norbert Lindenberg , Paul Hoffman , JSON WG Subject: Re: [Json] Consensus call: ABNF nits X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 22 Jun 2013 01:39:25 -0000 Joe Hildebrand (jhildebr) scripsit: > The posted ABNF for option 1 didn't get the last change that I proposed: > > unescaped = %x20-21 / %x23-5B / %x5D-D7FF / %xE000-10FFFF > > > which would make the comment correct. I like option 1 with that fix. If I understand the consensus call correctly, we are not attempting to change the ABNF itself at this stage. But I agree with you. -- John Cowan cowan@ccil.org http://www.ccil.org/~cowan Most languages are dramatically underdescribed, and at least one is dramatically overdescribed. Still other languages are simultaneously overdescribed and underdescribed. Welsh pertains to the third category. --Alan King From ietf@lindenbergsoftware.com Fri Jun 21 18:48:11 2013 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 9BF9F11E80A2 for ; Fri, 21 Jun 2013 18:48:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.471 X-Spam-Level: X-Spam-Status: No, score=-3.471 tagged_above=-999 required=5 tests=[AWL=-0.472, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wCp1rLlj+X+L for ; Fri, 21 Jun 2013 18:48:07 -0700 (PDT) Received: from mirach.lunarpages.com (mirach.lunarpages.com [216.97.235.70]) by ietfa.amsl.com (Postfix) with ESMTP id EEE9A21E804B for ; Fri, 21 Jun 2013 18:48:06 -0700 (PDT) Received: from 50-0-136-241.dsl.dynamic.sonic.net ([50.0.136.241]:50212 helo=[192.168.0.5]) by mirach.lunarpages.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1UqCvt-002UYY-G8; Fri, 21 Jun 2013 18:48:05 -0700 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Norbert Lindenberg In-Reply-To: Date: Fri, 21 Jun 2013 18:48:00 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "Joe Hildebrand (jhildebr)" X-Mailer: Apple Mail (2.1283) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - mirach.lunarpages.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - lindenbergsoftware.com X-Get-Message-Sender-Via: mirach.lunarpages.com: authenticated_id: ietf@lindenbergsoftware.com Cc: Norbert Lindenberg , Paul Hoffman , JSON WG Subject: Re: [Json] Consensus call: ABNF nits X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 22 Jun 2013 01:48:11 -0000 On Jun 21, 2013, at 18:32 , Joe Hildebrand (jhildebr) wrote: > On 6/21/13 12:56 PM, "Norbert Lindenberg" = > wrote: >=20 >>> escape =3D %x5C ; \ U+005C >>> quotation-mark =3D %x22 ; " U+0022 >>> unescaped =3D %x20-21 / %x23-5B / %x5D-10FFFF ; any Unicode scalar >>> ; value, except those that must be escaped (C0 control >>> ; characters, "QUOTATION MARK" [U+0022], and "REVERSE SOLIDUS" >>> ; [U+005C]) >>=20 >> Describing "unescaped" as "any Unicode scalar value, except..." is = wrong. >> The correct term is "Unicode code point". Unicode scalar values do = not >> include the range U+D800 through U+DFFFF. >> http://www.unicode.org/glossary/#unicode_scalar_value >=20 > The posted ABNF for option 1 didn't get the last change that I = proposed: >=20 > unescaped =3D %x20-21 / %x23-5B / %x5D-D7FF / %xE000-10FFFF That would be a significant normative change, which has been discussed = before and will surely come up in other consensus calls. It doesn't fit = under "nits". Norbert= From paul.hoffman@vpnc.org Fri Jun 21 19:26:48 2013 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 1611C21F9974 for ; Fri, 21 Jun 2013 19:26:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.518 X-Spam-Level: X-Spam-Status: No, score=-102.518 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YyIBM-FROZF3 for ; Fri, 21 Jun 2013 19:26:47 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 9B66821F9968 for ; Fri, 21 Jun 2013 19:26:47 -0700 (PDT) Received: from [10.20.30.90] (50-0-66-165.dsl.dynamic.sonic.net [50.0.66.165]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r5M2QgSZ057478 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 21 Jun 2013 19:26:43 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Paul Hoffman In-Reply-To: Date: Fri, 21 Jun 2013 19:26:41 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <44C998F8-D6D0-4E6E-BFCF-BA7E36A36892@vpnc.org> References: To: Joe Hildebrand (jhildebr) X-Mailer: Apple Mail (2.1508) Cc: JSON WG Subject: Re: [Json] Consensus call: ABNF nits X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 22 Jun 2013 02:26:48 -0000 On Jun 21, 2013, at 6:32 PM, Joe Hildebrand (jhildebr) = wrote: > The posted ABNF for option 1 didn't get the last change that I = proposed: >=20 > unescaped =3D %x20-21 / %x23-5B / %x5D-D7FF / %xE000-10FFFF The purpose of *this* consensus call is a clarification of the ABNF that = would technically match the ABNF in the current draft. The change you = propose will be in a different consensus call that is dealing with the = subject of code points. --Paul Hoffman= From sayrer@gmail.com Fri Jun 21 19:33:08 2013 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 DA6CD21E809E for ; Fri, 21 Jun 2013 19:33:08 -0700 (PDT) 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=[AWL=0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KVD5lShfcluY for ; Fri, 21 Jun 2013 19:33:08 -0700 (PDT) Received: from mail-wg0-x233.google.com (mail-wg0-x233.google.com [IPv6:2a00:1450:400c:c00::233]) by ietfa.amsl.com (Postfix) with ESMTP id 2299C21E804D for ; Fri, 21 Jun 2013 19:33:07 -0700 (PDT) Received: by mail-wg0-f51.google.com with SMTP id e11so7060325wgh.30 for ; Fri, 21 Jun 2013 19:33:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=rsr+PB4HX7OCjhQFXGcobev6kPh+PyBQ1DpA3dyDPjg=; b=T64FlsdMVkez+Jy1eeWZTuieeNwO2PhrYIHUKxmfE5ketOOggeXFMsJ/1Q8Y1MAeZs 3cFPLQoyFtNdzFJFjD1dNqZwBo9+sihp4gk5icFaa4RUMMj6cQeJ8c9ACobxGOZ01Edk 7y1vkC3jhwBLaCnx046BluRACM6dz8B56AseIuabn+QyH6a10gYc340eJuDB+5m4Q0Jb Q1dPVH17rKoSK1k4CZ93zhYENtyoz3lqJ6XwpzRyVi20CPiK8/ZbPVs9epsswlmGHcBO 7iq9PiS4pInJM92oBqBQfPtlW9bAUk5tysxs/nx8GrtKy00NwkR3tv/OS7qMZLk2hx7g bPrA== MIME-Version: 1.0 X-Received: by 10.180.76.103 with SMTP id j7mr585123wiw.21.1371868386096; Fri, 21 Jun 2013 19:33:06 -0700 (PDT) Received: by 10.194.44.138 with HTTP; Fri, 21 Jun 2013 19:33:06 -0700 (PDT) In-Reply-To: <90B659B8-D4AC-41AF-8C06-67FC65C8BD74@vpnc.org> References: <90B659B8-D4AC-41AF-8C06-67FC65C8BD74@vpnc.org> Date: Fri, 21 Jun 2013 19:33:06 -0700 Message-ID: From: R S To: Paul Hoffman Content-Type: multipart/alternative; boundary=f46d043c7cc6d4fe6404dfb4ff66 Cc: JSON WG Subject: Re: [Json] Consensus call: document title X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 22 Jun 2013 02:33:09 -0000 --f46d043c7cc6d4fe6404dfb4ff66 Content-Type: text/plain; charset=ISO-8859-1 1, 0 (a refreshing change from "+1" emails...) - Rob On Fri, Jun 21, 2013 at 9:38 AM, Paul Hoffman wrote: > There are three proposals for dealing with the document title: > 0) Leave the title in the current draft as-is: > The application/json Media Type for JavaScript Object Notation > (JSON) > 1) Change the title to > The JSON Data Interchange Format > 2) Change the title to > The JSON Format for Encoding Data > > Please respond to this message with a list of proposals you could accept, > ordered from highest to lowest. Do not list proposals you cannot live with. > If you cannot accept any of the proposals, please respond and say why. > > Based on the responses we receive, we will try to judge the consensus of > the WG. > > -- The JSON WG co-chairs > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > --f46d043c7cc6d4fe6404dfb4ff66 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
1, 0

(a refreshing change from &q= uot;+1" emails...)

- Rob


On Fri, Ju= n 21, 2013 at 9:38 AM, Paul Hoffman <paul.hoffman@vpnc.org> wrote:
There are three proposals for dealing with t= he document title:
=A0 0) Leave the title in the current draft as-is:
=A0 =A0 =A0 =A0The application/json Media Type for JavaScript Object Notati= on (JSON)
=A0 1) Change the title to
=A0 =A0 =A0 =A0The JSON Data Interchange Format
=A0 2) Change the title to
=A0 =A0 =A0 =A0The JSON Format for Encoding Data

Please respond to this message with a list of proposals you could accept, o= rdered from highest to lowest. Do not list proposals you cannot live with. = If you cannot accept any of the proposals, please respond and say why.

Based on the responses we receive, we will try to judge the consensus of th= e WG.

-- The JSON WG co-chairs
_______________________________________________
json mailing list
json@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/json

--f46d043c7cc6d4fe6404dfb4ff66-- From cabo@tzi.org Fri Jun 21 20:25:24 2013 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 EB0CD21F9B0F for ; Fri, 21 Jun 2013 20:25:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.211 X-Spam-Level: X-Spam-Status: No, score=-106.211 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DytXzhvCRo6Z for ; Fri, 21 Jun 2013 20:25:19 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id D43E521F9B03 for ; Fri, 21 Jun 2013 20:25:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r5M3PCjg006320; Sat, 22 Jun 2013 05:25:12 +0200 (CEST) Received: from [192.168.217.105] (p54891B2F.dip0.t-ipconnect.de [84.137.27.47]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 992BF7725; Sat, 22 Jun 2013 05:25:11 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <44C998F8-D6D0-4E6E-BFCF-BA7E36A36892@vpnc.org> Date: Sat, 22 Jun 2013 05:25:10 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <44C998F8-D6D0-4E6E-BFCF-BA7E36A36892@vpnc.org> To: Paul Hoffman X-Mailer: Apple Mail (2.1508) Cc: "Joe Hildebrand \(jhildebr\)" , JSON WG Subject: Re: [Json] Consensus call: ABNF nits X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 22 Jun 2013 03:25:25 -0000 On Jun 22, 2013, at 04:26, Paul Hoffman wrote: > clarification of the ABNF Yes. But Norbert and Joe are right that the change to the comment in = that clarification already anticipates the change to the ABNF itself in = that separate consensus call. So at this stage, it needs to say "Unicode code point", until we change = both the production and the comment to "Unicode scalar value". This is less a matter of consensus, than of correctness. Gr=FC=DFe, Carsten From sayrer@gmail.com Fri Jun 21 20:31:48 2013 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 CDE3221F9605 for ; Fri, 21 Jun 2013 20:31:48 -0700 (PDT) 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=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oKyjd4yz2KOH for ; Fri, 21 Jun 2013 20:31:48 -0700 (PDT) Received: from mail-we0-x22d.google.com (mail-we0-x22d.google.com [IPv6:2a00:1450:400c:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 2C7ED21F95D7 for ; Fri, 21 Jun 2013 20:31:48 -0700 (PDT) Received: by mail-we0-f173.google.com with SMTP id x54so6905675wes.4 for ; Fri, 21 Jun 2013 20:31:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=2qyN7ATYgl4vfGXXaYn1VjjWfUKONasX1vUiMUJ4qKA=; b=hHli0RVjMnUAKxP1G4Tkg8b/2HTMnx8OsXH13JZXluu2LylABMgqkCVVSJABuS6DVG CikfTJmgA86JqQGFphLh0Ihzvby3J85mixezNeaD3+mAmiA1gxV30mlnx2/sZDVj5pjn LCAzU0+PfNKOFn0prlu7mdzuhkdc4SpBLoiP1kPkuARH4ikUoZGzFGEOT7AGhXPE68SD E1xNTAEu3hqOCs3q7Ln7iZuD01MfiOy1+ckZA114lgnqCXXRSdYcXErCRKMB2FEO+ipa 5sFeAR5woSSdR8c3hIV+n5GUVYhzuR7gsgWGzifqcr9CqQgjZnOflhgfJqSbZhciYotZ qPqw== MIME-Version: 1.0 X-Received: by 10.180.185.84 with SMTP id fa20mr621676wic.49.1371871904806; Fri, 21 Jun 2013 20:31:44 -0700 (PDT) Received: by 10.194.44.138 with HTTP; Fri, 21 Jun 2013 20:31:44 -0700 (PDT) In-Reply-To: References: <44C998F8-D6D0-4E6E-BFCF-BA7E36A36892@vpnc.org> Date: Fri, 21 Jun 2013 20:31:44 -0700 Message-ID: From: R S To: Carsten Bormann Content-Type: multipart/alternative; boundary=001a11c2404c903c8804dfb5d186 Cc: Paul Hoffman , "Joe Hildebrand \(jhildebr\)" , JSON WG Subject: Re: [Json] Consensus call: ABNF nits X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 22 Jun 2013 03:31:48 -0000 --001a11c2404c903c8804dfb5d186 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Jun 21, 2013 at 8:25 PM, Carsten Bormann wrote: > > This is less a matter of consensus, than of correctness. Fully disagree. The existing specification is imperfect, but running code seems to exist. - Rob --001a11c2404c903c8804dfb5d186 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, Jun 21, 2013 at 8:25 PM, Carsten Bormann <cabo@tzi.org= > wrote:

This is less a matter of consensus, than of correctness.
<= br>

Fully disagree. The existing specificati= on is imperfect, but running code seems to exist.

- Rob

--001a11c2404c903c8804dfb5d186-- From cabo@tzi.org Fri Jun 21 21:07:16 2013 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 40A4111E80CC for ; Fri, 21 Jun 2013 21:07:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.212 X-Spam-Level: X-Spam-Status: No, score=-106.212 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sdn8JLIgl9M4 for ; Fri, 21 Jun 2013 21:07:10 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 287C411E80AE for ; Fri, 21 Jun 2013 21:07:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r5M473rr017322; Sat, 22 Jun 2013 06:07:03 +0200 (CEST) Received: from [192.168.217.105] (p54891B2F.dip0.t-ipconnect.de [84.137.27.47]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id E37877727; Sat, 22 Jun 2013 06:07:02 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: Date: Sat, 22 Jun 2013 06:07:02 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <40953F6C-E904-4C7D-9DF3-9711D48D14FF@tzi.org> References: <44C998F8-D6D0-4E6E-BFCF-BA7E36A36892@vpnc.org> To: R S X-Mailer: Apple Mail (2.1508) Cc: Paul Hoffman , "Joe Hildebrand \(jhildebr\)" , JSON WG Subject: Re: [Json] Consensus call: ABNF nits X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 22 Jun 2013 04:07:16 -0000 On Jun 22, 2013, at 05:31, R S wrote: >> This is less a matter of consensus, than of correctness. >=20 >=20 > Fully disagree. The existing specification is imperfect, but running = code seems to exist. You didn't understand. The current text says 2 + 2 ; this is 5 You need to either=20 1) change the 2 + 2 (which is the substantive change you seem to be = opposed of; you are wrong here, but not incorrect). 2) or change the 5 to 4. (which would be wrong, but correct for now). Since this consensus call is about non-substantive changes, the answer = must be 2, and there is no sensible way to disagree with that. Gr=FC=DFe, Carsten From sayrer@gmail.com Fri Jun 21 22:22:12 2013 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 4AF3021F99E2 for ; Fri, 21 Jun 2013 22:22:12 -0700 (PDT) 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=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dnkgj6hdFVMR for ; Fri, 21 Jun 2013 22:22:11 -0700 (PDT) Received: from mail-wg0-x233.google.com (mail-wg0-x233.google.com [IPv6:2a00:1450:400c:c00::233]) by ietfa.amsl.com (Postfix) with ESMTP id 7FCCC21F99C5 for ; Fri, 21 Jun 2013 22:22:11 -0700 (PDT) Received: by mail-wg0-f51.google.com with SMTP id e11so6915458wgh.18 for ; Fri, 21 Jun 2013 22:22:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=zPzREKW8Q1Qe0JE/85C2WeLmWNggqHkopX90xkzWCiI=; b=ya3eYS7dc6Xm3rNyBGPZbZSDcXH+W8hYIPFIggWq7xj1Q4kiA3hAYkxRGmoUZ7nDc9 WpFu7LtaRPS+bMM+i8eT4CxtTJR/Scqd3hYLISg6t/tM+YI+E1YaQE7szfvh4l3VKp0e OOmce+jE1nS4whU1hnt9czzoVFWJ2t6ta+IjUe9xWopRFetc94RV6hYar5ZHbrY1pA5j LvN2hI6Ga+3Tdd9+S/nc/MqhfpwFGRD+JhpjBdaa3UWx/ROzBkKDoNg8lvbzxqMlxpPP 3QKbuwAn5aRTyDJLFC3Lj48C226r7vhS7nvsGQbki5FtS9XM7HJZlCSAlZAwfUSqlbob n1Ag== MIME-Version: 1.0 X-Received: by 10.194.63.229 with SMTP id j5mr11127023wjs.79.1371878529346; Fri, 21 Jun 2013 22:22:09 -0700 (PDT) Received: by 10.194.44.138 with HTTP; Fri, 21 Jun 2013 22:22:09 -0700 (PDT) In-Reply-To: <40953F6C-E904-4C7D-9DF3-9711D48D14FF@tzi.org> References: <44C998F8-D6D0-4E6E-BFCF-BA7E36A36892@vpnc.org> <40953F6C-E904-4C7D-9DF3-9711D48D14FF@tzi.org> Date: Fri, 21 Jun 2013 22:22:09 -0700 Message-ID: From: R S To: Carsten Bormann Content-Type: multipart/alternative; boundary=047d7ba975186adf2104dfb75cb8 Cc: Paul Hoffman , "Joe Hildebrand \(jhildebr\)" , JSON WG Subject: Re: [Json] Consensus call: ABNF nits X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 22 Jun 2013 05:22:12 -0000 --047d7ba975186adf2104dfb75cb8 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Jun 21, 2013 at 9:07 PM, Carsten Bormann wrote: > On Jun 22, 2013, at 05:31, R S wrote: > > >> This is less a matter of consensus, than of correctness. > > > > > > Fully disagree. The existing specification is imperfect, but running > code seems to exist. > > You didn't understand. Frankly, I think you don't understand. The issue does not matter. Leave the current text. It's fine. - Rob --047d7ba975186adf2104dfb75cb8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, Jun 21, 2013 at 9:07 PM, Carsten Bormann <cabo@tzi.org= > wrote:
On Jun 22, 2013, at 05:31, R S <sayrer@gmail.com> wrote:

>> This is less a matter of consensus, than of correctness.
>
>
> Fully disagree. The existing specification is imperfect, but running c= ode seems to exist.

You didn't understand. =A0

= Frankly, I think you don't understand.

The issue does not matter. Leave the current text. It's fine.

- Rob=A0
--047d7ba975186adf2104dfb75cb8-- From jhildebr@cisco.com Fri Jun 21 22:49:56 2013 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 0E04C21F9DCE for ; Fri, 21 Jun 2013 22:49:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.581 X-Spam-Level: X-Spam-Status: No, score=-10.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DMC2UaeiqUbg for ; Fri, 21 Jun 2013 22:49:50 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 5FD1A21F9DDA for ; Fri, 21 Jun 2013 22:49:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=689; q=dns/txt; s=iport; t=1371880190; x=1373089790; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=Tar+KYcNEZZ/FlRXSod9ccs2MbD64/akyn9ltiOqnck=; b=GNh6SiK81dx4rIb8o4WU1zaNfFnmmgyx/6vpandhB3IN513YSkaRwjBy pucUgZP1gyDGrLStVoy+1z1Tt9cZ0H/zNBpSvtfUpcrw91sXeJMkxccb6 jA38ra0NoE2kQeon+22FBhiumWM+zfJwAFTfJv8wLrXfljFtZ1vebMig+ U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Al8FALA5xVGtJV2c/2dsb2JhbABbgwl6gjy8f4EEFnSCIwEBAQQ6PxIBCBgKFEIlAgQOBQiIBrwjjxgxB4MAYQOpB4MPgig X-IronPort-AV: E=Sophos;i="4.87,917,1363132800"; d="scan'208";a="226157386" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-4.cisco.com with ESMTP; 22 Jun 2013 05:49:46 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r5M5ndoc028975 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 22 Jun 2013 05:49:39 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.56]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.02.0318.004; Sat, 22 Jun 2013 00:49:39 -0500 From: "Joe Hildebrand (jhildebr)" To: Paul Hoffman Thread-Topic: [Json] Consensus call: ABNF nits Thread-Index: AQHObp4GCg0C1hAwXU6c6yl/pmiq4plA2MEAgAAJ9wCAAHO5gP//1BoA Date: Sat, 22 Jun 2013 05:49:38 +0000 Message-ID: In-Reply-To: <44C998F8-D6D0-4E6E-BFCF-BA7E36A36892@vpnc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.5.130515 x-originating-ip: [10.21.115.32] Content-Type: text/plain; charset="us-ascii" Content-ID: <04BF71A590E3404091B0DAD32C2BDD24@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: JSON WG Subject: Re: [Json] Consensus call: ABNF nits X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 22 Jun 2013 05:49:56 -0000 On 6/21/13 8:26 PM, "Paul Hoffman" wrote: > > >On Jun 21, 2013, at 6:32 PM, Joe Hildebrand (jhildebr) > wrote: > >> The posted ABNF for option 1 didn't get the last change that I proposed: >>=20 >> unescaped =3D %x20-21 / %x23-5B / %x5D-D7FF / %xE000-10FFFF > >The purpose of *this* consensus call is a clarification of the ABNF that >would technically match the ABNF in the current draft. The change you >propose will be in a different consensus call that is dealing with the >subject of code points. Then I suggest you remove the (new) comment from that line for this consensus call. --=20 Joe Hildebrand From duerst@it.aoyama.ac.jp Sat Jun 22 03:38:02 2013 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 0E32021F9D1B for ; Sat, 22 Jun 2013 03:38:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.152 X-Spam-Level: X-Spam-Status: No, score=-103.152 tagged_above=-999 required=5 tests=[AWL=0.638, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NX28SFOVynXL for ; Sat, 22 Jun 2013 03:37:56 -0700 (PDT) Received: from scintmta02.scbb.aoyama.ac.jp (scintmta02.scbb.aoyama.ac.jp [133.2.253.34]) by ietfa.amsl.com (Postfix) with ESMTP id 6002721F9F41 for ; Sat, 22 Jun 2013 03:37:55 -0700 (PDT) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id r5MAbrZo023182; Sat, 22 Jun 2013 19:37:53 +0900 Received: from (unknown [133.2.206.134]) by scmse02.scbb.aoyama.ac.jp with smtp id 6989_d6be_cb5abd12_db27_11e2_914f_001e6722eec2; Sat, 22 Jun 2013 19:37:53 +0900 Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id 87C11BF4CD; Sat, 22 Jun 2013 19:36:29 +0900 (JST) Message-ID: <51C57E6D.8000005@it.aoyama.ac.jp> Date: Sat, 22 Jun 2013 19:37:33 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: Paul Hoffman References: <90B659B8-D4AC-41AF-8C06-67FC65C8BD74@vpnc.org> In-Reply-To: <90B659B8-D4AC-41AF-8C06-67FC65C8BD74@vpnc.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: JSON WG Subject: Re: [Json] Consensus call: document title X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 22 Jun 2013 10:38:02 -0000 1 (2) Regards, Martin. On 2013/06/22 1:38, Paul Hoffman wrote: > There are three proposals for dealing with the document title: > 0) Leave the title in the current draft as-is: > The application/json Media Type for JavaScript Object Notation (JSON) > 1) Change the title to > The JSON Data Interchange Format > 2) Change the title to > The JSON Format for Encoding Data > > Please respond to this message with a list of proposals you could accept, ordered from highest to lowest. Do not list proposals you cannot live with. If you cannot accept any of the proposals, please respond and say why. > > Based on the responses we receive, we will try to judge the consensus of the WG. > > -- The JSON WG co-chairs > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > From stefan@drees.name Sat Jun 22 06:09:41 2013 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 E053F11E80F8 for ; Sat, 22 Jun 2013 06:09:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.111 X-Spam-Level: X-Spam-Status: No, score=-2.111 tagged_above=-999 required=5 tests=[AWL=0.138, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rITle0nYCbhN for ; Sat, 22 Jun 2013 06:09:36 -0700 (PDT) Received: from mout.web.de (mout.web.de [212.227.15.14]) by ietfa.amsl.com (Postfix) with ESMTP id CEF7011E80F7 for ; Sat, 22 Jun 2013 06:09:35 -0700 (PDT) Received: from newyork.local.box ([93.129.186.29]) by smtp.web.de (mrweb101) with ESMTPSA (Nemesis) id 0MVLj0-1UngyD1Mbu-00Ykwp; Sat, 22 Jun 2013 15:09:31 +0200 Message-ID: <51C5A20A.1060300@drees.name> Date: Sat, 22 Jun 2013 15:09:30 +0200 From: Stefan Drees User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Paul Hoffman References: <90B659B8-D4AC-41AF-8C06-67FC65C8BD74@vpnc.org> In-Reply-To: <90B659B8-D4AC-41AF-8C06-67FC65C8BD74@vpnc.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:raf/5pbCJ9bD6R4paea717YgkrsAD1ugp8oOdEvqCylu4UvyxI1 EQsIMfbHMXZmCiburOOLjf0x4zdixwZNYoSHyAihIJMccN4WkRomNsHkcLbAzRnfIqlkT/z CQ12g9mDelLDToybENj9v6pLdJFH3a13WS3NsOKzhq9cXHN0pw82VFmEuNkWK99HMUwoUMm qlqpnax4hlmvT6bBlRqIA== Cc: JSON WG Subject: Re: [Json] Consensus call: document title X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stefan@drees.name List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Jun 2013 13:09:42 -0000 On 2013-06-21 18:38 +02:00, Paul Hoffman wrote: > There are three proposals for dealing with the document title: > 0) Leave the title in the current draft as-is: > The application/json Media Type for JavaScript Object Notation (JSON) > 1) Change the title to > The JSON Data Interchange Format > 2) Change the title to > The JSON Format for Encoding Data > > Please respond to this message with a list of proposals you could > accept, ordered from highest to lowest. Do not list proposals you cannot > live with. If you cannot accept any of the proposals, please respond and > say why. ... 2, 1 {"Stefan":true} From stefan@drees.name Sat Jun 22 06:19:58 2013 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 3D41A11E80F7 for ; Sat, 22 Jun 2013 06:19:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.815 X-Spam-Level: X-Spam-Status: No, score=-1.815 tagged_above=-999 required=5 tests=[AWL=-0.166, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_14=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cFX4IItFvhKX for ; Sat, 22 Jun 2013 06:19:52 -0700 (PDT) Received: from mout.web.de (mout.web.de [212.227.15.3]) by ietfa.amsl.com (Postfix) with ESMTP id 35D8C21F9D55 for ; Sat, 22 Jun 2013 06:19:51 -0700 (PDT) Received: from newyork.local.box ([93.129.186.29]) by smtp.web.de (mrweb102) with ESMTPSA (Nemesis) id 0LxwiW-1UBatx2m5E-015Mhz; Sat, 22 Jun 2013 15:19:47 +0200 Message-ID: <51C5A470.4010101@drees.name> Date: Sat, 22 Jun 2013 15:19:44 +0200 From: Stefan Drees User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Paul Hoffman References: <9E497099-2B5B-4256-B066-C2E77B558267@vpnc.org> In-Reply-To: <9E497099-2B5B-4256-B066-C2E77B558267@vpnc.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:3LNkbBP0W1klyCTLRKF2YdUDzzapp+WqW8Ryslww5EtW2T4HAHe K+D+I9i3lrbViJUc82rZOPgBlftAw/Z+U3VVhnpQaeai2cpCtUkfQqeILN0HiHrl5FE5Gpn SHC30LfrBxaeT0szNgdVHRk+m0DbTnFZu/oUek4yuxoc1MvZiMoaMs947H7rvBIYAAwq07o 2kW65rDhrPv5oqh8MXocA== Cc: JSON WG Subject: Re: [Json] Consensus call: ABNF nits X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stefan@drees.name List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Jun 2013 13:19:58 -0000 On 2013-06-21 18:40 +02:00, Paul Hoffman wrote: > There are two proposals for dealing with nits in the ABNF: > 0) Leave the ABNF in the current draft as-is > 1) Change the ABNF in the draft to use the values in "Proposal 1" below > Note that later proposals might make technical changes to the ABNF > itself; those proposals are not what we are discussing in this consensus > call. > > Please respond to this message with a list of proposals you could > accept, ordered from highest to lowest. Do not list proposals you cannot > live with. If you cannot accept any of the proposals, please respond and > say why. ... [1] But: Please do not forget to at least consider replacing ws by ows to somehow indicate the "nothing"ness it might represent and as already discussed on this list inside the ABNF nits thread(s). My motviation in this regard has already been explicated, so I do not have to repeat it here ;-) Thanks. {"Stefan":true} > -- The JSON WG co-chairs > > Proposal #1 > Note that this ABNF is sprinkled throughout Section 2 of draft-ietf-json-rfc4627bis-02. Each > section below replaces the similar section in the draft. > ============================================================== > > JSON-text = object / array > > begin-array = ws %x5B ws ; [ left square bracket > begin-object = ws %x7B ws ; { left curly bracket > end-array = ws %x5D ws ; ] right square bracket > end-object = ws %x7D ws ; } right curly bracket > name-separator = ws %x3A ws ; : colon > value-separator = ws %x2C ws ; , comma > > ws = *( > %x20 / ; Space > %x09 / ; Horizontal tab > %x0A / ; Line feed or New line > %x0D ; Carriage return > ) > > value = false / null / true / object / array / number / string > false = %x66.61.6c.73.65 ; false > null = %x6e.75.6c.6c ; null > true = %x74.72.75.65 ; true > > object = begin-object [ member *( value-separator member ) ] > end-object > member = string name-separator value > > array = begin-array [ value *( value-separator value ) ] end-array > > number = [ minus ] int [ frac ] [ exp ] > decimal-point = %x2E ; . > digit1-9 = %x31-39 ; 1-9 > e = %x65 / %x45 ; e E > exp = e [ minus / plus ] 1*DIGIT > frac = decimal-point 1*DIGIT > int = zero / ( digit1-9 *DIGIT ) > minus = %x2D ; - > plus = %x2B ; + > zero = %x30 ; 0 > DIGIT = %x30-39 ; 0-9 > ; DIGIT equivalent to DIGIT rule in [RFC5234] > > string = quotation-mark *char quotation-mark > char = unescaped / ( > escape ( > %x22 / ; " quotation mark U+0022 > %x5C / ; \ reverse solidus U+005C > %x2F / ; / solidus U+002F > %x62 / ; b backspace U+0008 > %x66 / ; f form feed U+000C > %x6E / ; n line feed U+000A > %x72 / ; r carriage return U+000D > %x74 / ; t tab U+0009 > %x75 4HEXDIG ) ) ; uXXXX U+XXXX > escape = %x5C ; \ U+005C > quotation-mark = %x22 ; " U+0022 > unescaped = %x20-21 / %x23-5B / %x5D-10FFFF ; any Unicode scalar > ; value, except those that must be escaped (C0 control > ; characters, "QUOTATION MARK" [U+0022], and "REVERSE SOLIDUS" > ; [U+005C]) > HEXDIG = DIGIT / %x41-46 / %x61-66 ; 0-9, A-F, or a-f > ; HEXDIG equivalent to HEXDIG rule in [RFC5234] From stefan@drees.name Sat Jun 22 06:30:18 2013 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 1E70621E809A for ; Sat, 22 Jun 2013 06:30:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.111 X-Spam-Level: X-Spam-Status: No, score=-2.111 tagged_above=-999 required=5 tests=[AWL=0.138, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1PCO5Rlj7L69 for ; Sat, 22 Jun 2013 06:30:11 -0700 (PDT) Received: from mout.web.de (mout.web.de [212.227.15.3]) by ietfa.amsl.com (Postfix) with ESMTP id 47D6911E80F7 for ; Sat, 22 Jun 2013 06:30:10 -0700 (PDT) Received: from newyork.local.box ([93.129.186.29]) by smtp.web.de (mrweb102) with ESMTPSA (Nemesis) id 0Lhev7-1UTxNP2hbV-00msKY; Sat, 22 Jun 2013 15:30:06 +0200 Message-ID: <51C5A6DD.7060902@drees.name> Date: Sat, 22 Jun 2013 15:30:05 +0200 From: Stefan Drees User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Paul Hoffman References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:izQHu868WDn0p1QEdQ16f9hmdAO8+he3SUs2Hg4Rb58BEUi3Al1 6faYtGgjZlljDFEJimYnj+qbW0HZB9xxvXq4zPe5HSvOoTFEkjaGHQSiFFHHyzVRyR/9PvT 0X2LH2NJp8VZ/OaoZgTZnPXti2+1/c1SCaaOCufVmmeHKuxrfBxx0XMLNT+Thaca3AgY3tW 2XntPmoyeRbR7hTbFkJNg== Cc: JSON WG Subject: Re: [Json] Consensus call: establishing name equality X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stefan@drees.name List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Jun 2013 13:30:18 -0000 On 2013-06-21 18:42 +02:00, Paul Hoffman wrote: > There are four proposals for establishing name equality: > > 0) Leave the current draft as-is, not discussing name equality > > 1) In Section 2.5 ("Strings"), immediately before the ABNF add: > For purpose of establishing name equality, comparisons MUST be conducted, after all unescaping > is done, by comparing numeric character code points. There is to be no modification of any > kind to the characters in names, including case-changing or combining-form normalization. > For example, the following four names MUST be considered equivalent: > * "\u002F" > * "\u002f" > * "\/" > * "/" > > 2) In Section 2.5 ("Strings"), immediately before the ABNF add: > For purpose of establishing name equality, comparisons MUST be conducted, after all unescaping > is done, by comparing numeric character code points. There MUST NOT be any modification of any > kind to the characters in names, including change of case or change between precomposed and > decomposed forms. > For example, the following four names MUST be considered equivalent: > * "\u002F" > * "\u002f" > * "\/" > * "/" > > 3) In Section 2.5 ("Strings"), immediately before the ABNF add: > For purpose of establishing name equality, implementations MUST first do all unescaping and > then MUST compare numeric character code points. There is to be no modification of any kind to > the characters in names, including case-changing or combining-form normalization. > For example, the following four names MUST be considered equivalent: > * "\u002F" > * "\u002f" > * "\/" > * "/" > > Please respond to this message with a list of proposals you could > accept, ordered from highest to lowest. Do not list proposals you cannot > live with. If you cannot accept any of the proposals, please respond and > say why. ... [3,2,1] plus: I am happily hopping on John's train, trying to leave "numeric character code points" town for some better place ... {"Stefan":true} From stedolan@stedolan.net Sat Jun 22 07:58:24 2013 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 C5B8121F9D1F for ; Sat, 22 Jun 2013 07:58:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.956 X-Spam-Level: * X-Spam-Status: No, score=1.956 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_14=0.6, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dsJJKyL-TJUQ for ; Sat, 22 Jun 2013 07:58:15 -0700 (PDT) Received: from mail-la0-x236.google.com (mail-la0-x236.google.com [IPv6:2a00:1450:4010:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id E34FD21F9FA5 for ; Sat, 22 Jun 2013 07:58:10 -0700 (PDT) Received: by mail-la0-f54.google.com with SMTP id ec20so8431865lab.41 for ; Sat, 22 Jun 2013 07:58:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:x-originating-ip:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :x-gm-message-state; bh=LYFHOIvHddb32wNROI2v9WltfWNd1MQqsUtkFrUICuw=; b=Rgvdcn7cUIboOlioODfecGOvJG5f6SK7M4QKLZBVaPQCmakJv/KXmZvbwmi8pMboPL UFKY3te72w9ToQLTgJgs/L2M8L7nAR9NG/k6nh04LomMh8rvC3LLSp8Dv/MwCaNQ/DVC FcTGOgnp64xyLeQ8oDdaYkXdCycK6aTvcX7nbRIUDNIEd7ZOp0vyO4xvkwJeGNsNpVjy iM4L2E3+Nn7F4zR/FQOKSjynJb+1mKx+YQvnoKc2B0EO+Xlx6cVhrahDCUsC1uGzROX+ oY8y8UIOeveEpweoY8AJ0s70Hj9iTHfa2BGyJm+JUKANhQwflQh8f46nESmhakuey5Jv x2Fw== MIME-Version: 1.0 X-Received: by 10.112.50.77 with SMTP id a13mr1418078lbo.46.1371913089451; Sat, 22 Jun 2013 07:58:09 -0700 (PDT) Sender: stedolan@stedolan.net Received: by 10.114.176.231 with HTTP; Sat, 22 Jun 2013 07:58:09 -0700 (PDT) X-Originating-IP: [80.111.235.9] In-Reply-To: <05A7D2E5-C119-4900-B52B-54B0F1206300@lindenbergsoftware.com> References: <05A7D2E5-C119-4900-B52B-54B0F1206300@lindenbergsoftware.com> Date: Sat, 22 Jun 2013 15:58:09 +0100 X-Google-Sender-Auth: Pee1cscWhvWHkskaomLzTSfccZU Message-ID: From: Stephen Dolan To: Norbert Lindenberg Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQlfuiVeNaRsHaTXy405SW4O9h83gjCJONZv3MjO3L/u89tyYGUdkHZd6jGm/Vj24VBmTQf5 Cc: "json@ietf.org" Subject: Re: [Json] Proposal: Code points and surrogates X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 22 Jun 2013 14:58:24 -0000 On Tue, Jun 18, 2013 at 8:43 AM, Norbert Lindenberg wrote: > Before: > A string is a sequence of zero or more Unicode characters [UNICODE]. > > After: > A string is a sequence of zero or more Unicode code points [UNICODE]. Unicode's three character encoding forms (UTF-8, UTF-16, and UTF-32) define means of encoding sequences of unicode scalar values. A unicode scalar value is a code point which is not a surrogate. Noncharacter codepoints like U+FFFF are unicode scalar values. Since JSON is invariably represented in some unicode encoding, it seems odd that JSON would include things which are not representable in any standard unicode encoding. Should we instead say "a string is a sequence of zero or more Unicode scalar values"? Even if we use "code point", it still seems odd to claim "this specification allows the inclusion of surrogate code points (U+D800 through U+DFFF) in JSON text, both directly and through escape sequences" - it's not clear that the inclusion of surrogate code points directly is actually possible. Stephen From sayrer@gmail.com Sat Jun 22 09:18:53 2013 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 4E6EE11E80FF for ; Sat, 22 Jun 2013 09:18:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.766 X-Spam-Level: X-Spam-Status: No, score=-1.766 tagged_above=-999 required=5 tests=[AWL=-0.833, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gybAUiz01Eyq for ; Sat, 22 Jun 2013 09:18:52 -0700 (PDT) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 4BC5821F9BFC for ; Sat, 22 Jun 2013 09:18:52 -0700 (PDT) Received: by mail-wi0-f170.google.com with SMTP id ey16so1541525wid.5 for ; Sat, 22 Jun 2013 09:18:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Mc8rsFiWvGM/Xo38Z4qaV4604NQC2SlsakiAS1nCcJo=; b=m7Ax5l3JyaIRQZCmx0Je6fJiiK0tpE1LioWuKKdGHUp35sBGt88gpT+PuhJ5CPW3kV AhhlHeDdTELDQSsWTVjUUxjh9A1QI+4frWH955ZPx2Y4vSJSQmRce7VkMA7kQVwYTF/9 EnocxNQKutqR/I2mQzaMQ2X3KOJo+cX46mO2sYoqcgTYxFj/U9vU6Ggzk9VjEVZ8D0Hp G6EQSvGKT763PvA3rhYcqUdCLrFQz/Y+soPCzUCeDHh29sQ5NzqmdFxi1L3mAqTkKg8R GKwxIqh7YqSPwaNVj9Oqq55e4ncJiC6QRr7E2d2Xmag2FTUhfTdPCTkNyI+Yf3tgNLYM wkCg== MIME-Version: 1.0 X-Received: by 10.180.93.136 with SMTP id cu8mr1861804wib.49.1371917930319; Sat, 22 Jun 2013 09:18:50 -0700 (PDT) Received: by 10.194.44.138 with HTTP; Sat, 22 Jun 2013 09:18:50 -0700 (PDT) In-Reply-To: <51C5A6DD.7060902@drees.name> References: <51C5A6DD.7060902@drees.name> Date: Sat, 22 Jun 2013 09:18:50 -0700 Message-ID: From: R S To: stefan@drees.name Content-Type: multipart/alternative; boundary=f46d0438931de5d6e204dfc08803 Cc: Paul Hoffman , JSON WG Subject: Re: [Json] Consensus call: establishing name equality X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 22 Jun 2013 16:18:53 -0000 --f46d0438931de5d6e204dfc08803 Content-Type: text/plain; charset=ISO-8859-1 [0] On Sat, Jun 22, 2013 at 6:30 AM, Stefan Drees wrote: > On 2013-06-21 18:42 +02:00, Paul Hoffman wrote: > >> There are four proposals for establishing name equality: >> >> 0) Leave the current draft as-is, not discussing name equality >> >> 1) In Section 2.5 ("Strings"), immediately before the ABNF add: >> For purpose of establishing name equality, comparisons MUST be >> conducted, after all unescaping >> is done, by comparing numeric character code points. There is to be >> no modification of any >> kind to the characters in names, including case-changing or >> combining-form normalization. >> For example, the following four names MUST be considered equivalent: >> * "\u002F" >> * "\u002f" >> * "\/" >> * "/" >> >> 2) In Section 2.5 ("Strings"), immediately before the ABNF add: >> For purpose of establishing name equality, comparisons MUST be >> conducted, after all unescaping >> is done, by comparing numeric character code points. There MUST NOT >> be any modification of any >> kind to the characters in names, including change of case or change >> between precomposed and >> decomposed forms. >> For example, the following four names MUST be considered equivalent: >> * "\u002F" >> * "\u002f" >> * "\/" >> * "/" >> >> 3) In Section 2.5 ("Strings"), immediately before the ABNF add: >> For purpose of establishing name equality, implementations MUST first >> do all unescaping and >> then MUST compare numeric character code points. There is to be no >> modification of any kind to >> the characters in names, including case-changing or combining-form >> normalization. >> For example, the following four names MUST be considered equivalent: >> * "\u002F" >> * "\u002f" >> * "\/" >> * "/" >> >> Please respond to this message with a list of proposals you could >> accept, ordered from highest to lowest. Do not list proposals you cannot >> live with. If you cannot accept any of the proposals, please respond and >> say why. ... >> > > [3,2,1] > > plus: I am happily hopping on John's train, trying to leave "numeric > character code points" town for some better place ... > > {"Stefan":true} > > > ______________________________**_________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/**listinfo/json > --f46d0438931de5d6e204dfc08803 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
[0]


On Sat, Jun 22, 2013 at 6:30 AM, Stefan Drees <stefan@drees.n= ame> wrote:
On 2= 013-06-21 18:42 +02:00, Paul Hoffman wrote:
There are four proposals for establishing name equality:

0) Leave the current draft as-is, not discussing name equality

1) In Section 2.5 ("Strings"), immediately before the ABNF add: =A0 =A0 For purpose of establishing name equality, comparisons MUST be cond= ucted, after all unescaping
=A0 =A0 is done, by comparing numeric character code points. There is to be= no modification of any
=A0 =A0 kind to the characters in names, including case-changing or combini= ng-form normalization.
=A0 =A0 For example, the following four names MUST be considered equivalent= :
=A0 =A0 =A0* "\u002F"
=A0 =A0 =A0* "\u002f"
=A0 =A0 =A0* "\/"
=A0 =A0 =A0* "/"

2) In Section 2.5 ("Strings"), immediately before the ABNF add: =A0 =A0 For purpose of establishing name equality, comparisons MUST be cond= ucted, after all unescaping
=A0 =A0 is done, by comparing numeric character code points. There MUST NOT= be any modification of any
=A0 =A0 kind to the characters in names, including change of case or change= between precomposed and
=A0 =A0 decomposed forms.
=A0 =A0 For example, the following four names MUST be considered equivalent= :
=A0 =A0 =A0* "\u002F"
=A0 =A0 =A0* "\u002f"
=A0 =A0 =A0* "\/"
=A0 =A0 =A0* "/"

3) In Section 2.5 ("Strings"), immediately before the ABNF add: =A0 =A0 For purpose of establishing name equality, implementations MUST fir= st do all unescaping and
=A0 =A0 then MUST compare numeric character code points. There is to be no = modification of any kind to
=A0 =A0 the characters in names, including case-changing or combining-form = normalization.
=A0 =A0 For example, the following four names MUST be considered equivalent= :
=A0 =A0 =A0* "\u002F"
=A0 =A0 =A0* "\u002f"
=A0 =A0 =A0* "\/"
=A0 =A0 =A0* "/"

Please respond to this message with a list of proposals you could
accept, ordered from highest to lowest. Do not list proposals you cannot live with. If you cannot accept any of the proposals, please respond and
say why. ...

[3,2,1]

plus: I am happily hopping on John's train, trying to leave "numer= ic character code points" town for some better place ...

{"Stefan":true}


_______________________________________________
json mailing list
json@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/json

--f46d0438931de5d6e204dfc08803-- From ietf@lindenbergsoftware.com Sat Jun 22 09:29:39 2013 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 598B121F9FB6 for ; Sat, 22 Jun 2013 09:29:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.443 X-Spam-Level: X-Spam-Status: No, score=-3.443 tagged_above=-999 required=5 tests=[AWL=-0.444, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IZ8u7JOcLgHr for ; Sat, 22 Jun 2013 09:29:27 -0700 (PDT) Received: from mirach.lunarpages.com (mirach.lunarpages.com [216.97.235.70]) by ietfa.amsl.com (Postfix) with ESMTP id C998021F9F9D for ; Sat, 22 Jun 2013 09:29:27 -0700 (PDT) Received: from 50-0-136-241.dsl.dynamic.sonic.net ([50.0.136.241]:52269 helo=[192.168.0.5]) by mirach.lunarpages.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1UqQgo-00455M-5Z; Sat, 22 Jun 2013 09:29:26 -0700 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Norbert Lindenberg In-Reply-To: Date: Sat, 22 Jun 2013 09:29:21 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <05A7D2E5-C119-4900-B52B-54B0F1206300@lindenbergsoftware.com> To: Stephen Dolan X-Mailer: Apple Mail (2.1283) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - mirach.lunarpages.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - lindenbergsoftware.com X-Get-Message-Sender-Via: mirach.lunarpages.com: authenticated_id: ietf@lindenbergsoftware.com Cc: Norbert Lindenberg , "json@ietf.org" Subject: Re: [Json] Proposal: Code points and surrogates X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 22 Jun 2013 16:29:39 -0000 On Jun 22, 2013, at 7:58 , Stephen Dolan wrote: > On Tue, Jun 18, 2013 at 8:43 AM, Norbert Lindenberg > wrote: >> Before: >> A string is a sequence of zero or more Unicode characters = [UNICODE]. >>=20 >> After: >> A string is a sequence of zero or more Unicode code points = [UNICODE]. >=20 > Unicode's three character encoding forms (UTF-8, UTF-16, and UTF-32) > define means of encoding sequences of unicode scalar values. A unicode > scalar value is a code point which is not a surrogate. Noncharacter > codepoints like U+FFFF are unicode scalar values. >=20 > Since JSON is invariably represented in some unicode encoding, it > seems odd that JSON would include things which are not representable > in any standard unicode encoding. >=20 > Should we instead say "a string is a sequence of zero or more Unicode > scalar values"? Even if we use "code point", it still seems odd to > claim "this specification allows the inclusion of surrogate code > points (U+D800 through U+DFFF) in JSON text, both directly and through > escape sequences" - it's not clear that the inclusion of surrogate > code points directly is actually possible. They can be included in Unicode strings, as defined in the Unicode = Standard, section 2.7 [1]. The strings used in JavaScript, Java, and = some other languages are Unicode strings, with no requirement of = well-formedness. The specification of the JSON object in the ECMAScript Language = Specification [2] requires that unpaired surrogates in strings are = passed through by both parse() and stringify(), and that parse() = unescapes escape sequences for all surrogate values, paired or not. = Testing I've done indicates that the implementations in the major = browsers and in Node.js conform to this requirement. [1] http://www.unicode.org/versions/Unicode6.2.0/ch02.pdf [2] http://ecma-international.org/ecma-262/5.1/#sec-15.12 Norbert From sayrer@gmail.com Sat Jun 22 09:58:01 2013 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 CD90D11E810B for ; Sat, 22 Jun 2013 09:58:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.516 X-Spam-Level: X-Spam-Status: No, score=-2.516 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A14GgQlk-YHm for ; Sat, 22 Jun 2013 09:58:01 -0700 (PDT) Received: from mail-we0-x22e.google.com (mail-we0-x22e.google.com [IPv6:2a00:1450:400c:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id E63D321F9D31 for ; Sat, 22 Jun 2013 09:58:00 -0700 (PDT) Received: by mail-we0-f174.google.com with SMTP id q58so7310241wes.33 for ; Sat, 22 Jun 2013 09:57:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=DXSXC3Yf1eVKtwRCY7i4pjxJDdgi/Y62KNIXVNJSOAg=; b=CLHSHsbWQx7nbFnu1ZVReZ1fvtvK7OYrTCUEYIH2luBzhuvszzOs1+2CIbMXsTdrx9 FyHXG4xMnzaM+KcDhr8laFgL+G5aQWdeBcRInI6iPR76Ei/WQd0H3DBZd2zURRcvyGBC RRrrE4GD+VVSOKhcH9qlxlzFnv36yUwFHeFjNNNvFjLXtij4pH+7rUV7T3uGXutn+eIQ d1f3yFYeJiXI9YRZFgXNw8l16i1i8VkmNoynxhrnZYRLoAlf4chq4Af/rY9dSjwwyM45 vFweOCuJnac3G+BOcKOS3jH+NjFs5tVA4tKtCc2jPFqQ0TOq9+wkhAjEDEcwHX209hbx bv9w== MIME-Version: 1.0 X-Received: by 10.180.95.201 with SMTP id dm9mr1976601wib.21.1371920278871; Sat, 22 Jun 2013 09:57:58 -0700 (PDT) Received: by 10.194.44.138 with HTTP; Sat, 22 Jun 2013 09:57:58 -0700 (PDT) Date: Sat, 22 Jun 2013 09:57:58 -0700 Message-ID: From: R S To: "json@ietf.org" Content-Type: multipart/alternative; boundary=f46d044402b6e1e86c04dfc11470 Subject: [Json] Proposal: the minimal edit X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 22 Jun 2013 16:58:01 -0000 --f46d044402b6e1e86c04dfc11470 Content-Type: text/plain; charset=ISO-8859-1 >From charter: "The work is essentially a reclassification in place, with minimal changes. The working group will review errata and update the document as needed to incorporate those, and will correct significant errors and inconsistencies, but will keep changes to a minimum." I propose a new section, to appear after "Generators" and before "IANA Considerations" + N. Differences from ECMAScript + + ECMAScript implementations produce and consume primitive JSON values at the + root level of JSON documents. It's my opinion that none of the errors or inconsistencies present in the document are significant, since JSON works pretty well. I'll probably oppose any edits that aren't to the introduction or the security considerations, including updates to references such as ABNF and Unicode. Note that the IETF does not update all standards track documents with obsolete references, which demonstrates that leaving the current references in place is tractable. - Rob --f46d044402b6e1e86c04dfc11470 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
From charter= :

"The work is=A0essentially a reclassification in pl= ace, with minimal changes. The=A0= working group will review errata and update the document as needed to=A0incorporate those, and will correct = significant errors and=A0inconsis= tencies, but will keep changes to a minimum."

I propose a new section, to appear after "Genera= tors" and before "IANA Considerations"

+ N. Differences from ECMAScript
+
+ ECMAScript implementations produce and consume prim= itive JSON values at the=A0
+ root level of JSON documents.

It's my opinion that= none of the errors or inconsistencies present in the document are signific= ant, since JSON works pretty well. I'll probably oppose any edits that = aren't to the introduction or the security considerations, including up= dates to references such as ABNF and Unicode. Note that the IETF does not u= pdate all standards track documents with obsolete references, which demonst= rates that leaving the current references in place is tractable.

- Rob
--f46d044402b6e1e86c04dfc11470-- From cowan@ccil.org Sat Jun 22 10:23:26 2013 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 E89DE21E809A for ; Sat, 22 Jun 2013 10:23:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.447 X-Spam-Level: X-Spam-Status: No, score=-3.447 tagged_above=-999 required=5 tests=[AWL=0.152, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C6Y4BLEFUrhU for ; Sat, 22 Jun 2013 10:23:21 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id BFC1A11E810B for ; Sat, 22 Jun 2013 10:23:21 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1UqRWt-0007x3-NT; Sat, 22 Jun 2013 13:23:15 -0400 Date: Sat, 22 Jun 2013 13:23:15 -0400 From: John Cowan To: Norbert Lindenberg Message-ID: <20130622172315.GN31186@mercury.ccil.org> References: <05A7D2E5-C119-4900-B52B-54B0F1206300@lindenbergsoftware.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Cc: Stephen Dolan , "json@ietf.org" Subject: Re: [Json] Proposal: Code points and surrogates X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 22 Jun 2013 17:23:27 -0000 Norbert Lindenberg scripsit: > The specification of the JSON object in the ECMAScript Language > Specification [2] requires that unpaired surrogates in strings are > passed through by both parse() and stringify(), and that parse() > unescapes escape sequences for all surrogate values, paired or > not. Testing I've done indicates that the implementations in the major > browsers and in Node.js conform to this requirement. Indeed. But it does not say AFAIK how to map ECMAScript strings onto byte-oriented external representations, which a standard that specifies the meaning of "application/json" must necessarily do. Since there is no standard way to represent unpaired surrogates in any character encoding, we have the choice of creating a new one de facto or de jure, or banning them from the external representation (though they can still appear escaped). -- Long-short-short, long-short-short / Dactyls in dimeter, John Cowan Verse form with choriambs / (Masculine rhyme): cowan@ccil.org One sentence (two stanzas) / Hexasyllabically Challenges poets who / Don't have the time. --robison who's at texas dot net From tbray@textuality.com Sat Jun 22 10:31:18 2013 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 9E01711E811A for ; Sat, 22 Jun 2013 10:31:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.594 X-Spam-Level: X-Spam-Status: No, score=0.594 tagged_above=-999 required=5 tests=[AWL=-0.763, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 80QV26Lbi+Bv for ; Sat, 22 Jun 2013 10:31:14 -0700 (PDT) Received: from mail-vb0-x22c.google.com (mail-vb0-x22c.google.com [IPv6:2607:f8b0:400c:c02::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 5B4C711E810B for ; Sat, 22 Jun 2013 10:31:14 -0700 (PDT) Received: by mail-vb0-f44.google.com with SMTP id e15so7018778vbg.3 for ; Sat, 22 Jun 2013 10:31:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=E1A7Sdq3QF/JtWS+eCbTM8tZpb7X21Xr4DwTVTx9j20=; b=ZPyT7Pi2jzL+YDYhyJ6JgGPX2iTZ+j0uBVnTwYDusMHEEnRK7VBxgcluffnABRHNpa DDS4gsPQ47k+RYNGZQuRBlPFCOd0rFBXGMTeBBuDJvoQypa7aSGCTwqe4CMvyCbrUryF d7cRaMf8kk4vKwkxQkixd1SF/NoO26vbSqSg7kmpZKJr+oTB/0pT7X45iy9RhgbVruV4 rc9g85kZnnOQXnguQutYny0d0u8SGaxatSqxYPoi8Hi+jWhdsrZ2GhtQhZsTpBX11YP7 Bxu9LIluf9musaZjnAVdvtTsgJHj2uaebfmXc+lhh/ZBJMtopz2iLZLC0BptKl0KqdXV YP8A== MIME-Version: 1.0 X-Received: by 10.220.197.72 with SMTP id ej8mr8071489vcb.66.1371922272757; Sat, 22 Jun 2013 10:31:12 -0700 (PDT) Received: by 10.220.219.200 with HTTP; Sat, 22 Jun 2013 10:31:12 -0700 (PDT) X-Originating-IP: [24.84.235.32] In-Reply-To: References: Date: Sat, 22 Jun 2013 10:31:12 -0700 Message-ID: From: Tim Bray To: R S Content-Type: multipart/alternative; boundary=001a11c1f08eba3a1704dfc18b42 X-Gm-Message-State: ALoCoQnQ3OtBUYjTd3KKLGoYDbajJDL4eMjfTWgulXCD57ylNhDhFh+bRgunIVdTutIicnhgrp4E Cc: "json@ietf.org" Subject: Re: [Json] Proposal: the minimal edit X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 22 Jun 2013 17:31:18 -0000 --001a11c1f08eba3a1704dfc18b42 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable If we=E2=80=99re doing an ECMAdiff section... Since 4627 says =E2=80=9CA st= ring is a sequence of zero or more Unicode characters [UNICODE]=E2=80=9D by definitio= n this cannot include unpaired surrogates, since they=E2=80=99re not . So in Rob=E2=80=99s proposed section: ECMAScript implementations generate and consume unpaired Unicode surrogate code points in JSON documents. On Sat, Jun 22, 2013 at 9:57 AM, R S wrote: > From charter: > > "The work is essentially a reclassification in place, with minimal > changes. The working group will review errata and update the document as > needed to incorporate those, and will correct significant errors and inco= nsistencies, > but will keep changes to a minimum." > > I propose a new section, to appear after "Generators" and before "IANA > Considerations" > > + N. Differences from ECMAScript > + > + ECMAScript implementations produce and consume primitive JSON values at > the > + root level of JSON documents. > > It's my opinion that none of the errors or inconsistencies present in the > document are significant, since JSON works pretty well. I'll probably > oppose any edits that aren't to the introduction or the security > considerations, including updates to references such as ABNF and Unicode. > Note that the IETF does not update all standards track documents with > obsolete references, which demonstrates that leaving the current referenc= es > in place is tractable. > > - Rob > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > > --001a11c1f08eba3a1704dfc18b42 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
If we=E2=80=99re doing an ECMAdiff section... Since 4627 s= ays =E2=80=9CA string is a sequence of zero or more Unicode characters [UNI= CODE]=E2=80=9D by definition this cannot include unpaired surrogates, since= they=E2=80=99re not .=C2=A0

So in Rob=E2=80=99s proposed section:

ECMAScript implementations gen= erate and consume unpaired Unicode surrogate code points in JSON documents.=


On = Sat, Jun 22, 2013 at 9:57 AM, R S <sayrer@gmail.com> wrote:
From= charter:

"The work is=C2=A0essentially a reclassification in place, with minimal changes. The= =C2=A0working group will review errata and update = the document as needed to=C2=A0incorporate those, = and will correct significant errors and=C2=A0incon= sistencies, but will keep changes to a minimum."

I= propose a new section, to appear after "Generators" and before &= quot;IANA Considerations"
<= span style=3D"line-height:16px">
+ N. Differences from ECMAScript
<= span style=3D"line-height:16px">+
+ ECMAScript implementations produce and consume primitive JSON v= alues at the=C2=A0
<= span style=3D"line-height:16px">+ root level of JSON documents.

It's my opinion that none of the errors or = inconsistencies present in the document are significant, since JSON works p= retty well. I'll probably oppose any edits that aren't to the intro= duction or the security considerations, including updates to references suc= h as ABNF and Unicode. Note that the IETF does not update all standards tra= ck documents with obsolete references, which demonstrates that leaving the = current references in place is tractable.

- Rob

_______________________________________________
json mailing list
json@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/json


--001a11c1f08eba3a1704dfc18b42-- From tbray@textuality.com Sat Jun 22 10:48:19 2013 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 DA2C611E810B for ; Sat, 22 Jun 2013 10:48:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.637 X-Spam-Level: X-Spam-Status: No, score=0.637 tagged_above=-999 required=5 tests=[AWL=-0.720, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cvqkbJ4H95tr for ; Sat, 22 Jun 2013 10:48:15 -0700 (PDT) Received: from mail-ve0-x233.google.com (mail-ve0-x233.google.com [IPv6:2607:f8b0:400c:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id 5531721E80A3 for ; Sat, 22 Jun 2013 10:48:13 -0700 (PDT) Received: by mail-ve0-f179.google.com with SMTP id d10so7474495vea.38 for ; Sat, 22 Jun 2013 10:48:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=ktKPeVB0CDjMzh/55lm1XOOXGGMfr0e0KwZKFsBJ7qM=; b=ngqL/KRlIsxhYCHjILlFjM7R9MScX3X/hLfhC5q1Yk0c+9EUtGG3+btsPEAWxwXeLm sM4tvkwI4kh0mcs5CGQldTrVrGQ+Q2/1MvdGdGqM6grSrfyo+NtytVBR8zqXx6ljUquH /03XnSDwXXKN1ch0NX5MhaRinOK/zblnUY9K+5p3zkt0DCU7QfK8VN3HQus0pBwRtSrt nRObV02eFP1DdzSQRfynReXfp74ZcWaTpYGIutfz1/Xf/3BtYTb0xSab6EQBkvrUGW85 EzZy6E3aGh9e1yWIb4SuEglM4xW6mL4IGSy75HKl4jOyPckaOPpsBe8AxfPZdW4nHH19 HEMA== MIME-Version: 1.0 X-Received: by 10.52.236.199 with SMTP id uw7mr7149277vdc.18.1371923292276; Sat, 22 Jun 2013 10:48:12 -0700 (PDT) Received: by 10.220.219.200 with HTTP; Sat, 22 Jun 2013 10:48:12 -0700 (PDT) X-Originating-IP: [24.84.235.32] In-Reply-To: References: Date: Sat, 22 Jun 2013 10:48:12 -0700 Message-ID: From: Tim Bray To: R S Content-Type: multipart/alternative; boundary=089e0111d9247edbc304dfc1c8e4 X-Gm-Message-State: ALoCoQmj0MescdqxHv9D4vF9BLdDIvCet5THvHzXSq6zDEQp+BbWEZdMBro+m2QThCM1nKHoB2g/ Cc: "json@ietf.org" Subject: Re: [Json] Proposal: the minimal edit X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 22 Jun 2013 17:48:20 -0000 --089e0111d9247edbc304dfc1c8e4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable BTW I should say that I have some sympathy with Rob=E2=80=99s viewpoint her= e. It looks like it might be hard to get consensus about the nits we want to pick here on 4627, and JSON in the wild works just fine, and the real de facto irritant is that ECMAScript does some non-4627-blessed things. I=E2=80=99m= willing to put some more work into the struggle for consensus, but if we just decided to give up, just add a =E2=80=9CStupid ECMAScript Tricks=E2=80=9D s= ection then declare victory, that wouldn=E2=80=99t be a terrible outcome. -T On Sat, Jun 22, 2013 at 9:57 AM, R S wrote: > From charter: > > "The work is essentially a reclassification in place, with minimal > changes. The working group will review errata and update the document as > needed to incorporate those, and will correct significant errors and inco= nsistencies, > but will keep changes to a minimum." > > I propose a new section, to appear after "Generators" and before "IANA > Considerations" > > + N. Differences from ECMAScript > + > + ECMAScript implementations produce and consume primitive JSON values at > the > + root level of JSON documents. > > It's my opinion that none of the errors or inconsistencies present in the > document are significant, since JSON works pretty well. I'll probably > oppose any edits that aren't to the introduction or the security > considerations, including updates to references such as ABNF and Unicode. > Note that the IETF does not update all standards track documents with > obsolete references, which demonstrates that leaving the current referenc= es > in place is tractable. > > - Rob > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > > --089e0111d9247edbc304dfc1c8e4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
BTW I should say that I have some sympathy with Rob=E2=80= =99s viewpoint here.=C2=A0 It looks like it might be hard to get consensus = about the nits we want to pick here on 4627, and JSON in the wild works jus= t fine, and the real de facto irritant is that ECMAScript does some non-462= 7-blessed things.=C2=A0 I=E2=80=99m willing to put some more work into the = struggle for consensus, but if we just decided to give up, just add a =E2= =80=9CStupid ECMAScript Tricks=E2=80=9D section then declare victory, that = wouldn=E2=80=99t be a terrible outcome. -T


On Sat,= Jun 22, 2013 at 9:57 AM, R S <sayrer@gmail.com> wrote:
From charter:

"The work is=C2=A0essentially a reclassification in place, with minimal changes. The= =C2=A0working group will review errata and update = the document as needed to=C2=A0incorporate those, = and will correct significant errors and=C2=A0incon= sistencies, but will keep changes to a minimum."

I= propose a new section, to appear after "Generators" and before &= quot;IANA Considerations"
<= span style=3D"line-height:16px">
+ N. Differences from ECMAScript
<= span style=3D"line-height:16px">+
+ ECMAScript implementations produce and consume primitive JSON v= alues at the=C2=A0
<= span style=3D"line-height:16px">+ root level of JSON documents.

It's my opinion that none of the errors or = inconsistencies present in the document are significant, since JSON works p= retty well. I'll probably oppose any edits that aren't to the intro= duction or the security considerations, including updates to references suc= h as ABNF and Unicode. Note that the IETF does not update all standards tra= ck documents with obsolete references, which demonstrates that leaving the = current references in place is tractable.

- Rob

_______________________________________________
json mailing list
json@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/json


--089e0111d9247edbc304dfc1c8e4-- From paul.hoffman@vpnc.org Sat Jun 22 10:51:29 2013 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 E577921F998D for ; Sat, 22 Jun 2013 10:51:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.52 X-Spam-Level: X-Spam-Status: No, score=-102.52 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1pRuiZNNlx0H for ; Sat, 22 Jun 2013 10:51:29 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 799FC21F9980 for ; Sat, 22 Jun 2013 10:51:29 -0700 (PDT) Received: from [10.20.30.90] (50-0-66-165.dsl.dynamic.sonic.net [50.0.66.165]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r5MHpRq9084247 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Sat, 22 Jun 2013 10:51:28 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Paul Hoffman In-Reply-To: Date: Sat, 22 Jun 2013 10:51:27 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <35B486DC-C401-44A7-8D28-A3A1042B5B20@vpnc.org> References: To: json@ietf.org X-Mailer: Apple Mail (2.1508) Subject: Re: [Json] Proposal: the minimal edit X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 22 Jun 2013 17:51:30 -0000 On Jun 22, 2013, at 10:48 AM, Tim Bray wrote: > BTW I should say that I have some sympathy with Rob=92s viewpoint = here. It looks like it might be hard to get consensus about the nits we = want to pick here on 4627, and JSON in the wild works just fine, and the = real de facto irritant is that ECMAScript does some non-4627-blessed = things. I=92m willing to put some more work into the struggle for = consensus, but if we just decided to give up, just add a =93Stupid = ECMAScript Tricks=94 section then declare victory, that wouldn=92t be a = terrible outcome. -T Certainly +1 to being willing to do the struggle for consensus, but also = +1 to a reconsideration of paying more attention to the part of the = charter that says "essentially a reclassification in place, with minimal = changes". --Paul Hoffman= From mnot@mnot.net Sat Jun 22 11:07:40 2013 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 C351B21F9C4D for ; Sat, 22 Jun 2013 11:07:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wkQhACIp55Cw for ; Sat, 22 Jun 2013 11:07:36 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id 567CF21F9C49 for ; Sat, 22 Jun 2013 11:07:36 -0700 (PDT) Received: from [192.168.2.179] (unknown [173.228.102.82]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 23222509B6; Sat, 22 Jun 2013 14:07:32 -0400 (EDT) From: Mark Nottingham Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sat, 22 Jun 2013 11:07:31 -0700 Message-Id: To: "json@ietf.org" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) Cc: Erik Wilde Subject: [Json] Profiles in the JSON media type X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 22 Jun 2013 18:07:40 -0000 It'd be nice if a 'profile' parameter would be explicitly allowed on the = JSON media type, so that people could identify conventions in use in the = document format (e.g., a particular type of linking). https://tools.ietf.org/html/rfc6906 Just a placeholder / reminder; no need to discuss immediately. Cheers, -- Mark Nottingham http://www.mnot.net/ From sayrer@gmail.com Sat Jun 22 11:17:25 2013 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 8D92621E80A5 for ; Sat, 22 Jun 2013 11:17:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.523 X-Spam-Level: X-Spam-Status: No, score=-2.523 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id on6VMuZEDXc7 for ; Sat, 22 Jun 2013 11:17:25 -0700 (PDT) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) by ietfa.amsl.com (Postfix) with ESMTP id A737121E80A3 for ; Sat, 22 Jun 2013 11:17:24 -0700 (PDT) Received: by mail-wi0-f177.google.com with SMTP id ey16so1452253wid.16 for ; Sat, 22 Jun 2013 11:17:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=zkziYel4pW846Bx7TAvyxIz+tGdrZ341oaPy6zMkl50=; b=ibrASt5lqa5DOjzUsjT6xDnRgGf+TNaXKwmrM3huiAaN2UKJujLLudDXfpJQRdIMk2 8ZOxr3bp0gavtEuXVbJE76fQ49ldRZNUmrXrnkljBqZ5t68xcuwAsXKoU8gwxJ8Z1y19 GzTqBds+Glx+cr4r9sPJ3+TnFHhtFRv7FCYB4OHpm2vK7pbU3HRjwrK8EfK0fOFaZOp1 G4fEJmWijxFlticZ9zRSgMswX2OBuS8ugl10QtwZSqkFYMbjIOcnnWS25mOJuQGJ0E6R TMtVLpETqjt1Ab4k7CxX0PHIdBjp9rZ56j39mX7+tr09SGbDlbmrInDZ6rSuvhse2rzZ sIfg== MIME-Version: 1.0 X-Received: by 10.180.76.103 with SMTP id j7mr2087967wiw.21.1371925043548; Sat, 22 Jun 2013 11:17:23 -0700 (PDT) Received: by 10.194.44.138 with HTTP; Sat, 22 Jun 2013 11:17:23 -0700 (PDT) In-Reply-To: References: Date: Sat, 22 Jun 2013 11:17:23 -0700 Message-ID: From: R S To: Tim Bray Content-Type: multipart/alternative; boundary=f46d043c7cc6e1188c04dfc23001 Cc: "json@ietf.org" Subject: Re: [Json] Proposal: the minimal edit X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 22 Jun 2013 18:17:25 -0000 --f46d043c7cc6e1188c04dfc23001 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Sat, Jun 22, 2013 at 10:31 AM, Tim Bray wrote: > If we=92re doing an ECMAdiff section... Since 4627 says =93A string is a > sequence of zero or more Unicode characters [UNICODE]=94 by definition th= is > cannot include unpaired surrogates, since they=92re not . > > So in Rob=92s proposed section: > > ECMAScript implementations generate and consume unpaired Unicode surrogat= e > code points in JSON documents. > Yeah, that's fair. I'm not opposed to any text in that section that reflects reality and refrains from editorializing. It might be good to focus the WG on producing a document that can be said to meet the requirements in the charter, and postpone changes that aren't necessary for that. I think documenting these ECMAScript irritants is the only thing we're absolutely required to do. - Rob --f46d043c7cc6e1188c04dfc23001 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
On Sat, Jun 22, 2013 at 10:31 AM, Tim Bray <tbray@text= uality.com> wrote:
If we=92re doing an ECMAdif= f section... Since 4627 says =93A string is a sequence of zero or more Unic= ode characters [UNICODE]=94 by definition this cannot include unpaired surr= ogates, since they=92re not .=A0

So in Rob=92s proposed section:

ECMAScript implementations generate = and consume unpaired Unicode surrogate code points in JSON documents.

Yeah, that= 9;s fair. I'm not opposed to any text in that section that reflects rea= lity and refrains from editorializing.

It might be good to focus the WG= on producing a document that can be said to meet the requirements in the c= harter, and postpone changes that aren't necessary for that. I think do= cumenting these ECMAScript irritants is the only thing we're absolutely= required to do.

- Rob
--f46d043c7cc6e1188c04dfc23001-- From paul.hoffman@vpnc.org Sat Jun 22 11:30:07 2013 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 A558A21F9F8F for ; Sat, 22 Jun 2013 11:30:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.52 X-Spam-Level: X-Spam-Status: No, score=-102.52 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FrVWTCaMWe4U for ; Sat, 22 Jun 2013 11:30:07 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 35CE821F9F3C for ; Sat, 22 Jun 2013 11:30:07 -0700 (PDT) Received: from [10.20.30.90] (50-0-66-165.dsl.dynamic.sonic.net [50.0.66.165]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r5MIU6ss085317 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Sat, 22 Jun 2013 11:30:06 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Paul Hoffman In-Reply-To: Date: Sat, 22 Jun 2013 11:30:05 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <12894BF8-B678-44AD-981C-BE3193FEF413@vpnc.org> References: To: "json@ietf.org WG" X-Mailer: Apple Mail (2.1508) Subject: Re: [Json] Proposal: the minimal edit X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 22 Jun 2013 18:30:07 -0000 On Jun 22, 2013, at 11:17 AM, R S wrote: > ECMAScript implementations generate and consume unpaired Unicode = surrogate code points in JSON documents. >=20 > Yeah, that's fair. I'm not opposed to any text in that section that = reflects reality and refrains from editorializing. Well, Tim wanted to call the section =93Stupid ECMAScript Tricks=94, = which seems kinda editorial. :-) The second thing such a section would contain would be a sentence about = how parsers react when they encounter an object with duplicate names. = But, beside that, I'm not sure there is anything else that this section = would need to cover. If the WG went down this path, the document would need to deal with the = errata for RFC 4627, but those are pretty easy. --Paul Hoffman= From jorge@jorgechamorro.com Sat Jun 22 11:42:39 2013 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 9303F21F9F08 for ; Sat, 22 Jun 2013 11:42:39 -0700 (PDT) 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=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pimddp7uK4Th for ; Sat, 22 Jun 2013 11:42:39 -0700 (PDT) Received: from mail-wg0-x22b.google.com (mail-wg0-x22b.google.com [IPv6:2a00:1450:400c:c00::22b]) by ietfa.amsl.com (Postfix) with ESMTP id EA92E21F9E7A for ; Sat, 22 Jun 2013 11:42:38 -0700 (PDT) Received: by mail-wg0-f43.google.com with SMTP id z11so7205102wgg.34 for ; Sat, 22 Jun 2013 11:42:37 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=mKqpb8oVuYsZUiOCYGMYuLIN74v/DJP08LQD3kTaHuQ=; b=TEDhUzRCalhT8WRyUlz/MDYFwTdIk7pZiAuFbFQrsLr4rva/kkjX/54ex4KiKpn3Fm glc6ucXoKqgv87OFLs29O0A/IpVqsJOmepPSmQ6f8uAZBeuWUnjTplsny1ZftP9U3JXh +sS99v3Lzm285fYB3kmfVmXjqn3OD9oVDPnJ6zG8c/q+9at3OpJuQ84kkYM8LGaLFhyl l20PIuOgzbP0W2sbQvxzdagedslP5qJ4jcs8h8IWCMjhD3Gn3typn7bRTLOC8Vyq1DYP QY/SEKlWPrwfQiH9WEGYZJU/V2ZjeL0oybx1l7Zdakt0gj5EAFrROJs2P9tqQTV7bxH/ tNvg== X-Received: by 10.180.208.105 with SMTP id md9mr2014702wic.57.1371926557634; Sat, 22 Jun 2013 11:42:37 -0700 (PDT) Received: from [192.168.10.50] (139.Red-83-40-31.dynamicIP.rima-tde.net. [83.40.31.139]) by mx.google.com with ESMTPSA id fv11sm5567698wic.11.2013.06.22.11.42.36 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 22 Jun 2013 11:42:37 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=windows-1252 From: Jorge In-Reply-To: Date: Sat, 22 Jun 2013 20:42:34 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <60DB0682-C0BC-4BB6-960A-EDAF46193249@jorgechamorro.com> References: To: Tim Bray X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQkdTALSwsuI4IqSnC3YlzD8xXZc9n8+9tb7JjmiXs9t63lvGJuEWPIYofLpBOljQAvXhlvS Cc: "json@ietf.org" , R S Subject: Re: [Json] Proposal: the minimal edit X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 22 Jun 2013 18:42:39 -0000 On 22/06/2013, at 19:31, Tim Bray wrote: > If we=92re doing an ECMAdiff section... Since 4627 says =93A string is = a sequence of zero or more Unicode characters [UNICODE]=94 by definition = this cannot include unpaired surrogates, since they=92re not . =20 Yes they are if they are escaped. --=20 ( Jorge )();= From cowan@ccil.org Sat Jun 22 11:52:07 2013 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 0177021F9EF7 for ; Sat, 22 Jun 2013 11:52:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.449 X-Spam-Level: X-Spam-Status: No, score=-3.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i53WAz4u1bON for ; Sat, 22 Jun 2013 11:52:02 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id 9D68921F9EF2 for ; Sat, 22 Jun 2013 11:52:02 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1UqSun-0007oF-Kl; Sat, 22 Jun 2013 14:52:01 -0400 Date: Sat, 22 Jun 2013 14:52:01 -0400 From: John Cowan To: R S Message-ID: <20130622185201.GO31186@mercury.ccil.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Cc: "json@ietf.org" Subject: Re: [Json] Proposal: the minimal edit X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 22 Jun 2013 18:52:07 -0000 R S scripsit: > It's my opinion that none of the errors or inconsistencies present in > the document are significant, since JSON works pretty well. It does at the level of an informational protocol, but not at the level of standards track. Would you be willing to sign a contract, arm's-length, with someone whose only constraint was that their code passed *some* interpretation of the RFC? I certainly would not. As I pointed out before, the parser conformance clause (first paragraph of Section 4) is satisfied by any program that accepts arbitrary input and produces arbitrary output distinct from the input (or indeed no output at all, given the over-free wording in the second paragraph). > Note that the IETF does not update all standards track documents with > obsolete references, which demonstrates that leaving the current > references in place is tractable. I don't think that applies to documents entering the standards track in the first place. -- You are a child of the universe no less John Cowan than the trees and all other acyclic http://www.ccil.org/~cowan graphs; you have a right to be here. cowan@ccil.org --DeXiderata by Sean McGrath From nico@cryptonector.com Sat Jun 22 13:32:26 2013 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 E6B7721F9CD3 for ; Sat, 22 Jun 2013 13:32:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XpV5tKs4Kgcl for ; Sat, 22 Jun 2013 13:32:22 -0700 (PDT) Received: from homiemail-a16.g.dreamhost.com (caiajhbdcaid.dreamhost.com [208.97.132.83]) by ietfa.amsl.com (Postfix) with ESMTP id 1216821F9CB3 for ; Sat, 22 Jun 2013 13:32:22 -0700 (PDT) Received: from homiemail-a16.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a16.g.dreamhost.com (Postfix) with ESMTP id A2A8850808D for ; Sat, 22 Jun 2013 13:32:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=3pkQGIxvY6tpdvih6fvs CEuZ6bw=; b=NEi5RLkDDIg0oC/3xkszfhMtnheW5fK6d19iKxZ4c7GqzN7DThy8 3fHfFh0fQ2JYZKkqrwgH14U5hdOVaulW6TU0xRWfc+REs7pybT+H5soqHRulETRh ybHGhrP7TaxhcM7rMq8Ul6KEQQmWKaoXg2M1xA+8Cm+CM9qAn2iF6vA= Received: from mail-wi0-f177.google.com (mail-wi0-f177.google.com [209.85.212.177]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a16.g.dreamhost.com (Postfix) with ESMTPSA id 56ECD50808C for ; Sat, 22 Jun 2013 13:32:20 -0700 (PDT) Received: by mail-wi0-f177.google.com with SMTP id ey16so1497292wid.10 for ; Sat, 22 Jun 2013 13:32:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Q9YjQe0Uu/f2RSnoMjvYNbw2DWCM5gx1PpcMal++fzM=; b=P32/3MdYfvtPMauL04lazJEdunkmtc8JzHiCjZJJXbdepE21fCqLxPg/LGnxOeTssh k0qrFiOVLy46NJie8AHtLc+iFMMpo1iXz2fX68UDXIlfK9xO2Lnmu57i873JZBdx5XbY sDl+lt8Mn8H3t+mx4zj75ig5Blu/mVm7eiGnuo/6yDmCw3NPhp2HBUsWugVEC7ys/ARP v3r4RsfZ2g1tVUkdgsx4d/1FuqCAUixTIZ7l9O+kgDdW/PzyakBICty6NcL9uBkq4AO1 G2oilt2mHP3yCdX4RqWgLDnxGG5TFTOZ15gGkHYzR9a92qGipM5PGRLFhM8Oo1AhH2AA 9vmQ== MIME-Version: 1.0 X-Received: by 10.194.8.163 with SMTP id s3mr12863290wja.41.1371933138908; Sat, 22 Jun 2013 13:32:18 -0700 (PDT) Received: by 10.216.29.5 with HTTP; Sat, 22 Jun 2013 13:32:18 -0700 (PDT) Received: by 10.216.29.5 with HTTP; Sat, 22 Jun 2013 13:32:18 -0700 (PDT) In-Reply-To: References: <05A7D2E5-C119-4900-B52B-54B0F1206300@lindenbergsoftware.com> Date: Sat, 22 Jun 2013 15:32:18 -0500 Message-ID: From: Nico Williams To: Norbert Lindenberg Content-Type: multipart/alternative; boundary=047d7b5d253e66a06604dfc41398 Cc: Stephen Dolan , "json@ietf.org" Subject: Re: [Json] Proposal: Code points and surrogates X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 22 Jun 2013 20:32:27 -0000 --047d7b5d253e66a06604dfc41398 Content-Type: text/plain; charset=UTF-8 I don't think it's any more reasonable to require that parsers pass through any old non-Unicode string contents than it would be to require a specific range of real numbers to be passed by all parsers. Or at least it would be surprising to find JSON to be so. Also, I can agree that parsers should pass through any odd escaped non-character data, but not that they should unescape such data. --047d7b5d253e66a06604dfc41398 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

I don't think it's any more reasonable to require th= at parsers pass through any old non-Unicode string contents than it would b= e to require a specific range of real numbers to be passed by all parsers.= =C2=A0 Or at least it would be surprising to find JSON to be so.=C2=A0 Also= , I can agree that parsers should pass through any odd escaped non-characte= r data, but not that they should unescape such data.

--047d7b5d253e66a06604dfc41398-- From cowan@ccil.org Sat Jun 22 13:42:08 2013 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 DE27721F9C22 for ; Sat, 22 Jun 2013 13:42:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.452 X-Spam-Level: X-Spam-Status: No, score=-3.452 tagged_above=-999 required=5 tests=[AWL=0.147, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w2WcmDVlOBeb for ; Sat, 22 Jun 2013 13:42:04 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id 8BF1021F9BF9 for ; Sat, 22 Jun 2013 13:42:04 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1UqUdE-0001qY-3b; Sat, 22 Jun 2013 16:42:00 -0400 Date: Sat, 22 Jun 2013 16:42:00 -0400 From: John Cowan To: Nico Williams Message-ID: <20130622204200.GT31186@mercury.ccil.org> References: <05A7D2E5-C119-4900-B52B-54B0F1206300@lindenbergsoftware.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Cc: Norbert Lindenberg , Stephen Dolan , "json@ietf.org" Subject: [Json] Numeric ECMAScript limitations X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 22 Jun 2013 20:42:09 -0000 Nico Williams scripsit: > I don't think it's any more reasonable to require that parsers pass > through any old non-Unicode string contents than it would be to require > a specific range of real numbers to be passed by all parsers. Right, that's another thing for the ECMAScript Stupid Tricks section: ECMAscript JSON limits the range of numbers to the finite values of 64-bit IEEE floats, whereas RFC JSON has no fixed limitation, though it licenses parsers to specify one. -- John Cowan cowan@ccil.org http://ccil.org/~cowan Objective consideration of contemporary phenomena compel the conclusion that optimum or inadequate performance in the trend of competitive activities exhibits no tendency to be commensurate with innate capacity, but that a considerable element of the unpredictable must invariably be taken into account. --Ecclesiastes 9:11, Orwell/Brown version From sayrer@gmail.com Sat Jun 22 13:42:35 2013 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 8B4BB21F9E2A for ; Sat, 22 Jun 2013 13:42:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.53 X-Spam-Level: X-Spam-Status: No, score=-2.53 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rwkTLgUS+uvZ for ; Sat, 22 Jun 2013 13:42:34 -0700 (PDT) Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 6F43521F9C32 for ; Sat, 22 Jun 2013 13:42:34 -0700 (PDT) Received: by mail-wi0-f174.google.com with SMTP id k10so1548367wiv.13 for ; Sat, 22 Jun 2013 13:42:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=rVgXkFQ3UgMuICihDXas6i+LtajbAWBKeWW6kYulfD4=; b=YMdnQc6KBfX4vh8gHEc+ouH3Okkx6Kok44UBGjJVmg8HcuIMsIaASma+mkpcf3JsK/ k6t5kQ805qpLEAPmSMGo6HOfABoKJPImcq9UCzNW8hPnqTZ9YpjzZr+U3QYjwPlc0bMI WuhvpxEimXBlsPvQBfWhzaTbTCp02vC/LBbOjzT8t8Dt2NlabQLbTbGAvGhPe5VWoXz3 vv3kP+jRpKx6esNjbxYzdA404pWBZaQTvaB8dzoguX+a0we2TUKAUGhU8MORIB9sFUe5 A9nRz1zkWNffbRITdupELKpkBbbvCAvOG8qzKroSwpZ4/cEo8lqCq/2oB8W7FshqR3+p Mc9w== MIME-Version: 1.0 X-Received: by 10.194.63.229 with SMTP id j5mr12613257wjs.79.1371933753617; Sat, 22 Jun 2013 13:42:33 -0700 (PDT) Received: by 10.194.44.138 with HTTP; Sat, 22 Jun 2013 13:42:33 -0700 (PDT) In-Reply-To: References: Date: Sat, 22 Jun 2013 13:42:33 -0700 Message-ID: From: R S To: Tim Bray Content-Type: multipart/alternative; boundary=047d7ba975180a343b04dfc43833 Cc: "json@ietf.org" Subject: Re: [Json] Proposal: the minimal edit X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 22 Jun 2013 20:42:35 -0000 --047d7ba975180a343b04dfc43833 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Incorporating updates from Paul and Tim: I propose a new section, to appear after "Generators" and before "IANA Considerations" + N. Differences from ECMAScript + + ECMAScript implementations produce and consume primitive JSON values at the + root level of JSON documents. + + ECMAScript implementations generate and consume unpaired Unicode surrogate code points in JSON documents. + + When there are duplicate names within an object, ECMAScript parsers overwrite the value corresponding to + such names with the value that appears last in the serialization. Maybe this proposal should also deal with the errata for RFC 4627, since they are said to be easy. That proposal would produce a document for -03 or -04 that meets the requirements of the charter, and further proposals could be evaluated with cost/benefit analysis in mind. - Rob On Sat, Jun 22, 2013 at 11:17 AM, R S wrote: > On Sat, Jun 22, 2013 at 10:31 AM, Tim Bray wrote: > >> If we=92re doing an ECMAdiff section... Since 4627 says =93A string is a >> sequence of zero or more Unicode characters [UNICODE]=94 by definition t= his >> cannot include unpaired surrogates, since they=92re not . >> >> So in Rob=92s proposed section: >> >> ECMAScript implementations generate and consume unpaired Unicode >> surrogate code points in JSON documents. >> > > Yeah, that's fair. I'm not opposed to any text in that section that > reflects reality and refrains from editorializing. > > It might be good to focus the WG on producing a document that can be said > to meet the requirements in the charter, and postpone changes that aren't > necessary for that. I think documenting these ECMAScript irritants is the > only thing we're absolutely required to do. > > - Rob > --047d7ba975180a343b04dfc43833 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Incorporating updates from Paul and Tim:=

I propose a new section, to appear after "G= enerators" and before "IANA Considerations"

+ N. Differences from ECMAScript
+
+ ECMAScript implementations produce and consume primitive JSON = values at the=A0
+ root level of JSON documents.
+
+=A0ECMAScript implementations generate and consume = unpaired Unicode surrogate code points in JSON documents.
<= span style=3D"line-height:16px">+
+ When there are duplicate names within an object, ECMAScri= pt parsers overwrite the value corresponding to
+ such=A0names with the value that appears last in the serialization.

Maybe this proposal should also deal with the erra= ta for RFC 4627, since they are said to be easy. That proposal would produc= e a document for -03 or -04 that meets the requirements of the charter, and= further proposals could be evaluated with cost/benefit analysis in mind.

- Rob



On Sat, Jun 22, 2013= at 11:17 AM, R S <sayrer@gmail.com> wrote:
On Sat, J= un 22, 2013 at 10:31 AM, Tim Bray <tbray@textuality.com> = wrote:
If we=92re doing an ECMAdif= f section... Since 4627 says =93A string is a sequence of zero or more Unic= ode characters [UNICODE]=94 by definition this cannot include unpaired surr= ogates, since they=92re not .=A0

So in Rob=92s proposed section:

ECMAScript implementations generate = and consume unpaired Unicode surrogate code points in JSON documents.

Yeah, that= 9;s fair. I'm not opposed to any text in that section that reflects rea= lity and refrains from editorializing.

It might be good to focus the WG on pr= oducing a document that can be said to meet the requirements in the charter= , and postpone changes that aren't necessary for that. I think document= ing these ECMAScript irritants is the only thing we're absolutely requi= red to do.

- Rob
=

--047d7ba975180a343b04dfc43833-- From sayrer@gmail.com Sat Jun 22 13:50:36 2013 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 5EC8021F9E9D for ; Sat, 22 Jun 2013 13:50:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.235 X-Spam-Level: X-Spam-Status: No, score=-2.235 tagged_above=-999 required=5 tests=[AWL=-0.236, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_45=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HUiLdXNEoQFy for ; Sat, 22 Jun 2013 13:50:35 -0700 (PDT) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 6C28A21F9D52 for ; Sat, 22 Jun 2013 13:50:35 -0700 (PDT) Received: by mail-wi0-f173.google.com with SMTP id hq4so1553056wib.6 for ; Sat, 22 Jun 2013 13:50:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=zoRH0mNV9P7IkEidC14DVbe1LI/ZGqA2mrQiJmoYg94=; b=B1YJE9chSGZpPjjtFmNp/dfTATaeRyU3akTYS6BbLG2d+WPhgsijeUayyqseZIr9ny MZ5w2G7GgJLDWpbkbKgfpIOa8Z07Ck/deyegXBMOGUHh2/dDPsPt3X5lmpinbFtxJijx xSjoZW7QKo/IjYDaGuxwXlAjIKBc3hMn5EG+UtrRhryrl/3nPahStfSfCALEF9fTqqVi i8x4b8krxkFLFQ44hBn2vrr9jQXaQlaH5eg61Qr1w0Xstdjmg+oxYt9gZHG4ev+lIq6O gL45oHZ56Zuo1vCo8V8e0m11Bqat2hrbhARDfUqJdjHbNSF1PTQnWcE5il4+xAFhJLt9 EbkQ== MIME-Version: 1.0 X-Received: by 10.194.86.106 with SMTP id o10mr12512205wjz.93.1371934234610; Sat, 22 Jun 2013 13:50:34 -0700 (PDT) Received: by 10.194.44.138 with HTTP; Sat, 22 Jun 2013 13:50:34 -0700 (PDT) In-Reply-To: <20130622204200.GT31186@mercury.ccil.org> References: <05A7D2E5-C119-4900-B52B-54B0F1206300@lindenbergsoftware.com> <20130622204200.GT31186@mercury.ccil.org> Date: Sat, 22 Jun 2013 13:50:34 -0700 Message-ID: From: R S To: John Cowan Content-Type: multipart/alternative; boundary=089e0102e0dcb591c804dfc454b3 Cc: "json@ietf.org" , Nico Williams , Stephen Dolan , Norbert Lindenberg Subject: Re: [Json] Numeric ECMAScript limitations X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 22 Jun 2013 20:50:36 -0000 --089e0102e0dcb591c804dfc454b3 Content-Type: text/plain; charset=ISO-8859-1 On Sat, Jun 22, 2013 at 1:42 PM, John Cowan wrote: > Right, that's another thing for the ECMAScript Stupid Tricks section: > ECMAscript JSON limits the range of numbers to the finite values of > 64-bit IEEE floats, whereas RFC JSON has no fixed limitation, though it > licenses parsers to specify one. > I think ECMAScript JSON.parse implementations conform to RFC 4627 in this case, so a note is not strictly necessary. I wouldn't oppose including it, though. Similar interoperability issues could occur between Python and Java, for example. - Rob --089e0102e0dcb591c804dfc454b3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Sat, Jun 22, 2013 at 1:42 PM, John Cowan <cowan@m= ercury.ccil.org> wrote:
Right, that's another thing for the ECMAScript Stupid Tricks section: ECMAscript JSON limits the range of numbers to the finite values of
64-bit IEEE floats, whereas RFC JSON has no fixed limitation, though it
licenses parsers to specify one.

= I think ECMAScript JSON.parse implementations conform to RFC 4627 in this c= ase, so a note is not strictly necessary. I wouldn't oppose including i= t, though. Similar interoperability issues could occur between Python and J= ava, for example.

- Rob
--089e0102e0dcb591c804dfc454b3-- From cowan@ccil.org Sat Jun 22 13:59:42 2013 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 56E0D21F9F1B for ; Sat, 22 Jun 2013 13:59:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.454 X-Spam-Level: X-Spam-Status: No, score=-3.454 tagged_above=-999 required=5 tests=[AWL=0.145, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pEuwOnadxQHP for ; Sat, 22 Jun 2013 13:59:38 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id 0798221F9EC0 for ; Sat, 22 Jun 2013 13:59:38 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1UqUuG-0003Qs-OF; Sat, 22 Jun 2013 16:59:36 -0400 Date: Sat, 22 Jun 2013 16:59:36 -0400 From: John Cowan To: R S Message-ID: <20130622205936.GV31186@mercury.ccil.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Cc: Tim Bray , "json@ietf.org" Subject: Re: [Json] Proposal: the minimal edit X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 22 Jun 2013 20:59:42 -0000 R S scripsit: > + N. Differences from ECMAScript > + > + ECMAScript implementations produce and consume primitive JSON values at > + the root level of JSON documents. > + > + ECMAScript implementations generate and consume unpaired Unicode > + surrogate code points in JSON documents. > + > + When there are duplicate names within an object, ECMAScript parsers > + overwrite the value corresponding to such names with the value that > + appears last in the serialization. To which I add: + ECMAScript parsers only accept, and ECMAScript generators only generate, + numbers that correspond to the finite values of binary 64-bit IEEE + 754:2008 floating point numbers. We'll need a non-normative reference, too: IEEE Computer Society (August 29, 2008). IEEE Standard for Floating-Point Arithmetic. IEEE. doi:10.1109/IEEESTD.2008.4610935. ISBN 978-0-7381-5753-5. IEEE Std 754-2008. -- Time alone is real John Cowan the rest imaginary like a quaternion --phma http://www.ccil.org/~cowan From sayrer@gmail.com Sat Jun 22 14:13:25 2013 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 B9FAE21F9F1C for ; Sat, 22 Jun 2013 14:13:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.518 X-Spam-Level: X-Spam-Status: No, score=-2.518 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9SSFhH3fK9fa for ; Sat, 22 Jun 2013 14:13:24 -0700 (PDT) Received: from mail-we0-x22f.google.com (mail-we0-x22f.google.com [IPv6:2a00:1450:400c:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 6E7A021F9F18 for ; Sat, 22 Jun 2013 14:13:24 -0700 (PDT) Received: by mail-we0-f175.google.com with SMTP id t59so7406402wes.34 for ; Sat, 22 Jun 2013 14:13:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Ggg6Nr4dHdnL32Uu7QDj0TkU/qKtjPPKVF614weG7aE=; b=q0WEkYFLZqpnKxU01qpsO8IGAIjdYn4g9PFP4G/I67Nas31trhzR0fzyLtK5io9rOO +HDWFPcWZskgC5QFYBT9P6BVJvUwRpHLWEl7DAsYiR2B4E4g0Uy5GyQTEZFhXMplJwU2 8ptVoxAuVSjA7JhPm1jIhnf+FOlyf1Zcf694XpQGf54SOoZPNDcUNfD9sfGENGjE3iZZ Tn6iw1ynu89oy0BzqlVkRJETKCsJcNmmEkAwwJgKn51UR7JssRoCmivVObOi+vTyVbeb u886bpvO6JwjBytDhA+Z7MsdyLurChWQEqxG9oyyLhPGVQ5oWTgFhGslQlTCe7ExxVrD ykoQ== MIME-Version: 1.0 X-Received: by 10.194.86.106 with SMTP id o10mr12543623wjz.93.1371935603621; Sat, 22 Jun 2013 14:13:23 -0700 (PDT) Received: by 10.194.44.138 with HTTP; Sat, 22 Jun 2013 14:13:23 -0700 (PDT) In-Reply-To: <20130622205936.GV31186@mercury.ccil.org> References: <20130622205936.GV31186@mercury.ccil.org> Date: Sat, 22 Jun 2013 14:13:23 -0700 Message-ID: From: R S To: John Cowan Content-Type: multipart/alternative; boundary=089e0102e0dc4f06f204dfc4a642 Cc: Tim Bray , "json@ietf.org" Subject: Re: [Json] Proposal: the minimal edit X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 22 Jun 2013 21:13:25 -0000 --089e0102e0dc4f06f204dfc4a642 Content-Type: text/plain; charset=ISO-8859-1 On Sat, Jun 22, 2013 at 1:59 PM, John Cowan wrote: > R S scripsit: > > > + N. Differences from ECMAScript > > + > > + ECMAScript implementations produce and consume primitive JSON values at > > + the root level of JSON documents. > > + > > + ECMAScript implementations generate and consume unpaired Unicode > > + surrogate code points in JSON documents. > > + > > + When there are duplicate names within an object, ECMAScript parsers > > + overwrite the value corresponding to such names with the value that > > + appears last in the serialization. > > To which I add: > > + ECMAScript parsers only accept, This bit is not quite right. I think they'll accept anything that conforms to the JSON grammar, and then produce a number that is not what the sender intended if it's out of range. > and ECMAScript generators only generate, > + numbers that correspond to the finite values of binary 64-bit IEEE > + 754:2008 floating point numbers. > As I said in the other thread, I wouldn't oppose including text along these lines. It is a real problem and people do get bitten by it. For example: But I don't think it's required for the minimal edit I'm proposing here. It's one of the things we should look at as a follow on. - Rob --089e0102e0dc4f06f204dfc4a642 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Sat, Jun 22, 2013 at 1:59 PM, John Cowan <cowan@m= ercury.ccil.org> wrote:
R S scripsit:

> + N. Differences from ECMAScript
> +
> + ECMAScript implementations produce and consume primitive JSON values= at
> + the root level of JSON documents.
> +
> + ECMAScript implementations generate and consume unpaired Unicode
> + surrogate code points in JSON documents.
> +
> + When there are duplicate names within an object, ECMAScript parsers<= br>
> + overwrite the value corresponding to such names with the value= that
> + appears last in the serialization.

To which I add:

+ ECMAScript parsers only accept,

Th= is bit is not quite right. I think they'll accept anything that conform= s to the JSON grammar, and then produce a number that is not what the sende= r intended if it's out of range.

=A0
and ECMAScript generators onl= y generate,
+ numbers that correspond to the finite values of binary 64-bit IEEE
+ 754:2008 floating point numbers.=

As I said in the other thread, I wouldn't oppose including text along = these lines. It is a real problem and people do get bitten by it. For examp= le:

<https://dev.twitter.com/docs/twitter-ids-json-and-snowflake>
=

But I don't think it's r= equired for the minimal edit I'm proposing here. It's one of the th= ings we should look at as a follow on.

- Rob
--089e0102e0dc4f06f204dfc4a642-- From cowan@ccil.org Sat Jun 22 14:22:31 2013 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 9381221F9E2F for ; Sat, 22 Jun 2013 14:22:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.457 X-Spam-Level: X-Spam-Status: No, score=-3.457 tagged_above=-999 required=5 tests=[AWL=0.142, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SpNU3IEC3IXT for ; Sat, 22 Jun 2013 14:22:27 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id 92C2521F9CC1 for ; Sat, 22 Jun 2013 14:22:27 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1UqVGG-0005yA-2Z; Sat, 22 Jun 2013 17:22:20 -0400 Date: Sat, 22 Jun 2013 17:22:20 -0400 From: John Cowan To: R S Message-ID: <20130622212219.GW31186@mercury.ccil.org> References: <20130622205936.GV31186@mercury.ccil.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Cc: Tim Bray , "json@ietf.org" Subject: Re: [Json] Proposal: the minimal edit X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 22 Jun 2013 21:22:31 -0000 R S scripsit: > > + ECMAScript parsers only accept, > > This bit is not quite right. I think they'll accept anything that conforms > to the JSON grammar, and then produce a number that is not what the sender > intended if it's out of range. Fair enough. "Only interpret correctly", perhaps, then. > This says that some parsers may throw exceptions if the number is too big, though it doesn't mention any such. -- Clear? Huh! Why a four-year-old child John Cowan could understand this report. Run out cowan@ccil.org and find me a four-year-old child. I http://www.ccil.org/~cowan can't make head or tail out of it. --Rufus T. Firefly on government reports From sayrer@gmail.com Sat Jun 22 14:38:06 2013 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 2D1F721F9E9D for ; Sat, 22 Jun 2013 14:38:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.523 X-Spam-Level: X-Spam-Status: No, score=-2.523 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1793FNJRzgia for ; Sat, 22 Jun 2013 14:38:05 -0700 (PDT) Received: from mail-wg0-x236.google.com (mail-wg0-x236.google.com [IPv6:2a00:1450:400c:c00::236]) by ietfa.amsl.com (Postfix) with ESMTP id 3B3E821F9E95 for ; Sat, 22 Jun 2013 14:38:05 -0700 (PDT) Received: by mail-wg0-f54.google.com with SMTP id n11so7555922wgh.9 for ; Sat, 22 Jun 2013 14:38:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=iCoORbq4dwijVA7cYYrSKjHg8hG4SeFJsBw4Z0Q8crk=; b=i8/tPP9aTvgXWRmfGoKEjzmsAQXLpUKacmQJD0EUuFIcjilmhNBVLM883ujHSimYCH KlQGClwpjMUqUnF1+L+pPzhUFIqR5pQIpUNhfLxlWn628f7MhJ8o2/p0HWTOy4vCHWW/ nBLderphkw27r3aStx5Y2VPXuhDomC/h26B/Js6nrzxikNX3O84bi+ErOaPvg74XTvkZ +xlM+05UF1Q2fe2IwCWC7uQeyiPESqqav10hnS5Bokz+WsVJ06VOnZ05BTYPAmu5TgAO 7khDn809z0T2tVvU9r3v//nE6JTT/8YYHUTB7mXzJvz0+x/5aki3M3NFfWi3yu+d3Z0a Tgtg== MIME-Version: 1.0 X-Received: by 10.180.76.103 with SMTP id j7mr2346456wiw.21.1371937083149; Sat, 22 Jun 2013 14:38:03 -0700 (PDT) Received: by 10.194.44.138 with HTTP; Sat, 22 Jun 2013 14:38:03 -0700 (PDT) In-Reply-To: <20130622212219.GW31186@mercury.ccil.org> References: <20130622205936.GV31186@mercury.ccil.org> <20130622212219.GW31186@mercury.ccil.org> Date: Sat, 22 Jun 2013 14:38:03 -0700 Message-ID: From: R S To: John Cowan Content-Type: multipart/alternative; boundary=f46d043c7cc67ed4de04dfc4fec0 Cc: Tim Bray , "json@ietf.org" Subject: Re: [Json] Proposal: the minimal edit X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 22 Jun 2013 21:38:06 -0000 --f46d043c7cc67ed4de04dfc4fec0 Content-Type: text/plain; charset=ISO-8859-1 On Sat, Jun 22, 2013 at 2:22 PM, John Cowan wrote: > R S scripsit: > > > > + ECMAScript parsers only accept, > > > > This bit is not quite right. I think they'll accept anything that > conforms > > to the JSON grammar, and then produce a number that is not what the > sender > > intended if it's out of range. > > Fair enough. "Only interpret correctly", perhaps, then. > > > > > This says that some parsers may throw exceptions if the number is too > big, though it doesn't mention any such. That document is not exclusively targeted at ECMAScript programmers, and it is targeted at programmers with widely varying levels of skill. It's very easy to encounter such an exception in languages where integers are assumed to be 32 bits, even though that exception is rarely produced by a JSON library itself. - Rob --f46d043c7cc67ed4de04dfc4fec0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Sat, Jun 22, 2013 at 2:22 PM, John Cowan <cowan@m= ercury.ccil.org> wrote:
R S scripsit:

> > + ECMAScript parsers only accept,
>
> This bit is not quite right. I think they'll accept anything that = conforms
> to the JSON grammar, and then produce a number that is not what the se= nder
> intended if it's out of range.

Fair enough. =A0"Only interpret correctly", perhaps, then.<= br>
> <https://dev.twitter.com/docs/twitter-ids-json-and-s= nowflake>

This says that some parsers may throw exceptions if the number is too
big, though it doesn't mention any such.

That document is not exclusively targeted at ECMAScript programmers= , and it is targeted at programmers with widely varying levels of skill. It= 's very easy to encounter such an exception in languages where integers= are assumed to be 32 bits, even though that exception is rarely produced b= y a JSON library itself.

- Rob

--f46d043c7cc67ed4de04dfc4fec0-- From tbray@textuality.com Sat Jun 22 14:56:25 2013 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 ED11B21F81FF for ; Sat, 22 Jun 2013 14:56:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.675 X-Spam-Level: X-Spam-Status: No, score=0.675 tagged_above=-999 required=5 tests=[AWL=-0.682, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B7yXQtLAQ+tV for ; Sat, 22 Jun 2013 14:56:11 -0700 (PDT) Received: from mail-vb0-x22e.google.com (mail-vb0-x22e.google.com [IPv6:2607:f8b0:400c:c02::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 4FA0E21F9DE7 for ; Sat, 22 Jun 2013 14:56:11 -0700 (PDT) Received: by mail-vb0-f46.google.com with SMTP id 10so6940196vbe.5 for ; Sat, 22 Jun 2013 14:56:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=KgRtR45t5rz3Dgrv9c9nTnBDf/LnO2I2EKh0+C4Np8E=; b=Jx+j8uEaQdf+dzZ5JiviH2UODJmhIWq+v/l9Ij6sLEnnV2M2KciVLUv6mI3Ny+nGyr gRSTjxVjA8dImxivCfetVsncA6I+F07uHlGSCBbSg16JnI7PBkzNuWBfiDD5smSsO9uR AB+Xu0/lMSMdkvFWDzJG1EnOIIb2vpsu3vYSXkIbnV8Y5xq3bVaDseZXdnqB+lQ1vTcH iK89Mi0non5u3rZRcH3gbLfrBYXBY5ijdFoiFCq/qKeUM+9YNoBX/ZN0gyEAF3pwkg6X TeifdqF8ZnvtsLGVcNSauXsHSh/pX/juUnTkyqAhAnErMbuFXGqvVDCVU/bhJ3SxbdER yX9g== MIME-Version: 1.0 X-Received: by 10.220.197.72 with SMTP id ej8mr8345418vcb.66.1371938169554; Sat, 22 Jun 2013 14:56:09 -0700 (PDT) Received: by 10.220.219.200 with HTTP; Sat, 22 Jun 2013 14:56:09 -0700 (PDT) X-Originating-IP: [24.84.235.32] In-Reply-To: References: Date: Sat, 22 Jun 2013 14:56:09 -0700 Message-ID: From: Tim Bray To: Mark Nottingham Content-Type: multipart/alternative; boundary=001a11c1f08e40170c04dfc53f62 X-Gm-Message-State: ALoCoQkwSITNW7bPo5XHfw6b+g27eXXSE9k1pJtCd90T2JpuHnr7Yc8rF8OBtoihbyL+DY5NWsE6 Cc: Erik Wilde , "json@ietf.org" Subject: Re: [Json] Profiles in the JSON media type X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 22 Jun 2013 21:56:27 -0000 --001a11c1f08e40170c04dfc53f62 Content-Type: text/plain; charset=UTF-8 Hey Mark, what are the rules... if you want to use parameters on a media-type, do you have to say so explicitly in the initial media-type registration? -T On Sat, Jun 22, 2013 at 11:07 AM, Mark Nottingham wrote: > It'd be nice if a 'profile' parameter would be explicitly allowed on the > JSON media type, so that people could identify conventions in use in the > document format (e.g., a particular type of linking). > > https://tools.ietf.org/html/rfc6906 > > Just a placeholder / reminder; no need to discuss immediately. > > Cheers, > > -- > Mark Nottingham http://www.mnot.net/ > > > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > --001a11c1f08e40170c04dfc53f62 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hey Mark, what are the rules... if you want to use paramet= ers on a media-type, do you have to say so explicitly in the initial media-= type registration? -T


On Sat, Jun 22, 2013 at 11:07 AM, Mark Nottingham <mnot@mnot.net> wrote:
It'd be nice if a 'profile' parameter would be explicitly allow= ed on the JSON media type, so that people could identify conventions in use= in the document format (e.g., a particular type of linking).

https://t= ools.ietf.org/html/rfc6906

Just a placeholder / reminder; no need to discuss immediately.

Cheers,

--
Mark Nottingham =C2=A0 h= ttp://www.mnot.net/



_______________________________________________
json mailing list
json@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/json

--001a11c1f08e40170c04dfc53f62-- From tbray@textuality.com Sat Jun 22 15:02:35 2013 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 CCCD821F9DF2 for ; Sat, 22 Jun 2013 15:02:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.709 X-Spam-Level: X-Spam-Status: No, score=0.709 tagged_above=-999 required=5 tests=[AWL=-0.648, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7GErgIw6Pd4u for ; Sat, 22 Jun 2013 15:02:31 -0700 (PDT) Received: from mail-ve0-x22b.google.com (mail-ve0-x22b.google.com [IPv6:2607:f8b0:400c:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 565CD21F9DC6 for ; Sat, 22 Jun 2013 15:02:31 -0700 (PDT) Received: by mail-ve0-f171.google.com with SMTP id b10so7573801vea.30 for ; Sat, 22 Jun 2013 15:02:30 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=jPnIhMXarJQjE34A9gljFPYpvvOl3uK/Y8b7+/1CYqw=; b=TptCIHrdRk5FzobP0GT2pSZSKWHzFD1nexvUmwbyMe8mXANjwDkS/QlR5VTF6zwghM cVSeMesLZH7DZKfcCb9+5D3PAAg/7NJfCKKFw6rsgohJqMt9fshdOSEIDhu3EChhLoMc h4orUgv9HViIZu8xSkPzZFwt7AnVscOSz/kiB1hMcebybl6pNQHYfhuC662BrVz7iCym 3fh6p/VncAUjtj5D7i3uWspT8wiUVjhXCIcG0OrfOlcCafUyQSEtN4SBu/RruOjh4Ruk ++/iwHnAF8aP/FtHOw6VeIqlJ4Kp4CEdh+UGmSUaf+gajFTmHg3fZh0nX/yxbMC4L1CE wKxg== MIME-Version: 1.0 X-Received: by 10.220.123.131 with SMTP id p3mr8265166vcr.69.1371938550783; Sat, 22 Jun 2013 15:02:30 -0700 (PDT) Received: by 10.220.219.200 with HTTP; Sat, 22 Jun 2013 15:02:30 -0700 (PDT) X-Originating-IP: [24.84.235.32] In-Reply-To: <20130622205936.GV31186@mercury.ccil.org> References: <20130622205936.GV31186@mercury.ccil.org> Date: Sat, 22 Jun 2013 15:02:30 -0700 Message-ID: From: Tim Bray To: John Cowan Content-Type: multipart/alternative; boundary=089e013cbb22f92f2a04dfc55511 X-Gm-Message-State: ALoCoQlLtmmLpzrgLI4I8KelAaTDGxcI2ULuMjPJ95d81B81mr8IcVBHHyDeIkA5ortxr5lCMhXs Cc: "json@ietf.org" , R S Subject: Re: [Json] Proposal: the minimal edit X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 22 Jun 2013 22:02:36 -0000 --089e013cbb22f92f2a04dfc55511 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Since there are those who (gasp!) are not native speakers of IEEE Floats, it=E2=80=99s probably helpful to say something like =E2=80=9Cwhich have 53 = bits of precision (2**53 is roughly 9.007 * 10**15)=E2=80=9D On Sat, Jun 22, 2013 at 1:59 PM, John Cowan wrote: > R S scripsit: > > > + N. Differences from ECMAScript > > + > > + ECMAScript implementations produce and consume primitive JSON values = at > > + the root level of JSON documents. > > + > > + ECMAScript implementations generate and consume unpaired Unicode > > + surrogate code points in JSON documents. > > + > > + When there are duplicate names within an object, ECMAScript parsers > > + overwrite the value corresponding to such names with the value that > > + appears last in the serialization. > > To which I add: > > + ECMAScript parsers only accept, and ECMAScript generators only generate= , > + numbers that correspond to the finite values of binary 64-bit IEEE > + 754:2008 floating point numbers. > > We'll need a non-normative reference, too: > > IEEE Computer Society (August 29, 2008). IEEE Standard for > Floating-Point Arithmetic. IEEE. doi:10.1109/IEEESTD.2008.4610935. > ISBN 978-0-7381-5753-5. IEEE Std 754-2008. > > -- > Time alone is real John Cowan > the rest imaginary > like a quaternion --phma http://www.ccil.org/~cowan > --089e013cbb22f92f2a04dfc55511 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Since there are those who (gasp!) are not native speakers = of IEEE Floats, it=E2=80=99s probably helpful to say something like =E2=80= =9Cwhich have 53 bits of precision (2**53 is roughly 9.007 * 10**15)=E2=80= =9D


On Sat, Jun 22, 2013 at 1:59 PM, John Co= wan <cowan@mercury.ccil.org> wrote:
R S scripsit:

> + N. Differences from ECMAScript
> +
> + ECMAScript implementations produce and consume primitive JSON values= at
> + the root level of JSON documents.
> +
> + ECMAScript implementations generate and consume unpaired Unicode
> + surrogate code points in JSON documents.
> +
> + When there are duplicate names within an object, ECMAScript parsers<= br>
> + overwrite the value corresponding to such names with the value= that
> + appears last in the serialization.

To which I add:

+ ECMAScript parsers only accept, and ECMAScript generators only generate,<= br> + numbers that correspond to the finite values of binary 64-bit IEEE
+ 754:2008 floating point numbers.

We'll need a non-normative reference, too:

=C2=A0 =C2=A0 IEEE Computer Society (August 29, 2008). IEEE Standard for =C2=A0 =C2=A0 Floating-Point Arithmetic. IEEE. =C2=A0doi:10.1109/IEEESTD.20= 08.4610935.
=C2=A0 =C2=A0 ISBN 978-0-7381-5753-5. IEEE Std 754-2008.

--
Time alone is real =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0John Cowan <cowan@= ccil.org>
=C2=A0 the rest imaginary
like a quaternion =C2=A0 =C2=A0 =C2=A0 --phma =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0http://www.c= cil.org/~cowan

--089e013cbb22f92f2a04dfc55511-- From cabo@tzi.org Sat Jun 22 15:03:59 2013 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 4649921F9BF6 for ; Sat, 22 Jun 2013 15:03:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Uexf8EKVNfJ for ; Sat, 22 Jun 2013 15:03:51 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id B0EB921F9DE7 for ; Sat, 22 Jun 2013 15:03:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r5MM3ls6027751; Sun, 23 Jun 2013 00:03:47 +0200 (CEST) Received: from alma.fritz.box (p5B3FF3E1.dip0.t-ipconnect.de [91.63.243.225]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 29CA8783D; Sun, 23 Jun 2013 00:03:47 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <20130622212219.GW31186@mercury.ccil.org> Date: Sun, 23 Jun 2013 00:03:46 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <8DB99A42-7666-443A-9C99-53F8A1AACF17@tzi.org> References: <20130622205936.GV31186@mercury.ccil.org> <20130622212219.GW31186@mercury.ccil.org> To: John Cowan X-Mailer: Apple Mail (2.1508) Cc: "json@ietf.org" , Tim Bray , R S Subject: Re: [Json] Proposal: the minimal edit X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 22 Jun 2013 22:03:59 -0000 On Jun 22, 2013, at 23:22, John Cowan wrote: >> This bit is not quite right. I think they'll accept anything that = conforms >> to the JSON grammar, and then produce a number that is not what the = sender >> intended if it's out of range. >=20 > Fair enough. "Only interpret correctly", perhaps, then. Trying to understand this discussion: Is the IEEE 754 number a JavaScript parser generates from [1.1] = "interpreted correctly"? There is no way to "correctly" represent 1.1 in IEEE 754 double = precision binary. So maybe it is more useful to point out that parsers (and that = observation is not limited to JavaScript) might convert JSON's decimal = numbers to a (binary or other) form, losing precision and range in the = process. Section 4 now says: An implementation may set limits on the size of texts that it accepts. An implementation may set limits on the maximum depth of nesting. --> An implementation may set limits on the range of = numbers. <-- An implementation may set limits on the length and character contents of strings. So maybe it is useful to point out that parsers (again, not just the = ones that try to conform to a version of ECMAscript) are also likely to = set limits on the precision of numbers (maybe that even was meant to be = included by the term "range" here, although I'd prefer the stricter = interpretation of that term). Gr=FC=DFe, Carsten From cabo@tzi.org Sat Jun 22 15:10:37 2013 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 54CF921F9E58 for ; Sat, 22 Jun 2013 15:10:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XnLQu77DmhHZ for ; Sat, 22 Jun 2013 15:10:31 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 3540221F9C7A for ; Sat, 22 Jun 2013 15:10:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r5MMASMZ010114; Sun, 23 Jun 2013 00:10:28 +0200 (CEST) Received: from alma.fritz.box (p5B3FF3E1.dip0.t-ipconnect.de [91.63.243.225]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id AF96F783E; Sun, 23 Jun 2013 00:10:28 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <05A7D2E5-C119-4900-B52B-54B0F1206300@lindenbergsoftware.com> Date: Sun, 23 Jun 2013 00:10:28 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <05A7D2E5-C119-4900-B52B-54B0F1206300@lindenbergsoftware.com> To: Norbert Lindenberg X-Mailer: Apple Mail (2.1508) Cc: json@ietf.org Subject: Re: [Json] Proposal: Code points and surrogates X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 22 Jun 2013 22:10:37 -0000 On Jun 18, 2013, at 09:43, Norbert Lindenberg = wrote: > JSON allows are you trying to say (a) a conforming parser is required to accept or (b) a conforming parser is not required to reject Gr=FC=DFe, Carsten From cowan@ccil.org Sat Jun 22 15:39:13 2013 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 F3AC721F9E69 for ; Sat, 22 Jun 2013 15:39:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.459 X-Spam-Level: X-Spam-Status: No, score=-3.459 tagged_above=-999 required=5 tests=[AWL=0.140, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id neNeNidgrrCa for ; Sat, 22 Jun 2013 15:39:08 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id A27B721F9E57 for ; Sat, 22 Jun 2013 15:39:08 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1UqWSY-0004q3-UH; Sat, 22 Jun 2013 18:39:07 -0400 Date: Sat, 22 Jun 2013 18:39:06 -0400 From: John Cowan To: Carsten Bormann Message-ID: <20130622223906.GX31186@mercury.ccil.org> References: <20130622205936.GV31186@mercury.ccil.org> <20130622212219.GW31186@mercury.ccil.org> <8DB99A42-7666-443A-9C99-53F8A1AACF17@tzi.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8DB99A42-7666-443A-9C99-53F8A1AACF17@tzi.org> User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Cc: R S , Tim Bray , "json@ietf.org" Subject: Re: [Json] Proposal: the minimal edit X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 22 Jun 2013 22:39:13 -0000 Carsten Bormann scripsit: > So maybe it is more useful to point out that parsers (and that > observation is not limited to JavaScript) might convert JSON's decimal > numbers to a (binary or other) form, losing precision and range in > the process. I had range rather than precision in mind: if you parse "[1, 10, 1E400]", you are likely to get either an exception or an array with 1.0, 10.0, and Inf in it. But my point is that ECMAScript implementations MUST NOT represent 1E400 other than as Inf, nor 1.9999999999999999999999999 as other than 2.0. The same is not true in other languages, notably various Lisps. > Section 4 now says: > > An implementation may set limits on the size of texts that it > accepts. An implementation may set limits on the maximum depth of > nesting. --> An implementation may set limits on the range of numbers. <-- > An implementation may set limits on the length and character contents > of strings. > > So maybe it is useful to point out that parsers (again, not just the > ones that try to conform to a version of ECMAscript) are also likely > to set limits on the precision of numbers +1 -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org To say that Bilbo's breath was taken away is no description at all. There are no words left to express his staggerment, since Men changed the language that they learned of elves in the days when all the world was wonderful. --The Hobbit From paul.hoffman@vpnc.org Sat Jun 22 16:54:48 2013 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 6ED5921F9E95 for ; Sat, 22 Jun 2013 16:54:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.521 X-Spam-Level: X-Spam-Status: No, score=-102.521 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tYJCHwvBm+Nb for ; Sat, 22 Jun 2013 16:54:47 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 8729321F9E87 for ; Sat, 22 Jun 2013 16:54:47 -0700 (PDT) Received: from [10.20.30.90] (50-0-66-165.dsl.dynamic.sonic.net [50.0.66.165]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r5MNsi3r094550 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 22 Jun 2013 16:54:45 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Paul Hoffman In-Reply-To: <20130622223906.GX31186@mercury.ccil.org> Date: Sat, 22 Jun 2013 16:54:43 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130622205936.GV31186@mercury.ccil.org> <20130622212219.GW31186@mercury.ccil.org> <8DB99A42-7666-443A-9C99-53F8A1AACF17@tzi.org> <20130622223906.GX31186@mercury.ccil.org> To: John Cowan X-Mailer: Apple Mail (2.1508) Cc: "json@ietf.org WG" Subject: Re: [Json] Proposal: the minimal edit X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 22 Jun 2013 23:54:48 -0000 On Jun 22, 2013, at 3:39 PM, John Cowan wrote: > Carsten Bormann scripsit: >=20 >> So maybe it is more useful to point out that parsers (and that >> observation is not limited to JavaScript) might convert JSON's = decimal >> numbers to a (binary or other) form, losing precision and range in >> the process. >=20 > I had range rather than precision in mind: if you parse "[1, 10, = 1E400]", > you are likely to get either an exception or an array with 1.0, 10.0, > and Inf in it. But my point is that ECMAScript implementations MUST > NOT represent 1E400 other than as Inf, nor 1.9999999999999999999999999 > as other than 2.0. The same is not true in other languages, notably > various Lisps. I would propose that this proposal is in the wrong thread. Robert = started this thread as "really minimal changes", and this is clearly an = addition, or possibly a note for the likely implementation guidance = document. --Paul Hoffman= From dret@berkeley.edu Sat Jun 22 15:42:01 2013 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 0113D21F9E65 for ; Sat, 22 Jun 2013 15:42:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id elhvm8sLodBZ for ; Sat, 22 Jun 2013 15:41:56 -0700 (PDT) Received: from cm02fe.IST.Berkeley.EDU (cm02fe.IST.Berkeley.EDU [169.229.218.143]) by ietfa.amsl.com (Postfix) with ESMTP id D8A7121F9E61 for ; Sat, 22 Jun 2013 15:41:56 -0700 (PDT) Received: from 99-38-249-227.lightspeed.sntcca.sbcglobal.net ([99.38.249.227] helo=[192.168.1.68]) by cm02fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth plain:dret@berkeley.edu) (envelope-from ) id 1UqWVG-0001Ta-87; Sat, 22 Jun 2013 15:41:56 -0700 Message-ID: <51C62831.3090004@berkeley.edu> Date: Sat, 22 Jun 2013 15:41:53 -0700 From: Erik Wilde User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Tim Bray , "json@ietf.org" References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sat, 22 Jun 2013 16:55:05 -0700 Cc: Mark Nottingham Subject: Re: [Json] Profiles in the JSON media type X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 22 Jun 2013 22:42:01 -0000 On 2013-06-22 14:56 , Tim Bray wrote: > Hey Mark, what are the rules... if you want to use parameters on a > media-type, do you have to say so explicitly in the initial media-type > registration? -T yes, that's the rule. at least that's my reading of http://tools.ietf.org/html/rfc4288#section-4.3, which says that "the names, values, and meanings of any parameters MUST be fully specified when a media type is registered in the standards tree, and SHOULD be specified as completely as possible when media types are registered in the vendor or personal trees." for this reason, http://tools.ietf.org/html/rfc6906#section-3.1 says "For newly defined media types that may be used with profiles, it is therefore recommended that they SHOULD define a media type parameter called 'profile' and specify that this media type parameter follows the semantics of a profile as laid out in this document." cheers, dret. -- erik wilde | mailto:dret@berkeley.edu - tel:+1-510-2061079 | | UC Berkeley - School of Information (ISchool) | | http://dret.net/netdret http://twitter.com/dret | From ietf@lindenbergsoftware.com Sat Jun 22 22:43:01 2013 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 C0CD011E80DC for ; Sat, 22 Jun 2013 22:43:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.718 X-Spam-Level: X-Spam-Status: No, score=-3.718 tagged_above=-999 required=5 tests=[AWL=-0.119, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rSeDkMbolMlc for ; Sat, 22 Jun 2013 22:42:56 -0700 (PDT) Received: from mirach.lunarpages.com (mirach.lunarpages.com [216.97.235.70]) by ietfa.amsl.com (Postfix) with ESMTP id E158D21F8C20 for ; Sat, 22 Jun 2013 22:42:55 -0700 (PDT) Received: from 50-0-136-241.dsl.dynamic.sonic.net ([50.0.136.241]:52914 helo=[192.168.0.5]) by mirach.lunarpages.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1Uqd4f-0015KP-2G; Sat, 22 Jun 2013 22:42:53 -0700 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Norbert Lindenberg In-Reply-To: Date: Sat, 22 Jun 2013 22:42:48 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <64BAD44A-6C70-409E-BC93-0ED72E48AF49@lindenbergsoftware.com> References: <05A7D2E5-C119-4900-B52B-54B0F1206300@lindenbergsoftware.com> To: Carsten Bormann X-Mailer: Apple Mail (2.1283) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - mirach.lunarpages.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - lindenbergsoftware.com X-Get-Message-Sender-Via: mirach.lunarpages.com: authenticated_id: ietf@lindenbergsoftware.com Cc: Norbert Lindenberg , json@ietf.org Subject: Re: [Json] Proposal: Code points and surrogates X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 23 Jun 2013 05:43:01 -0000 On Jun 22, 2013, at 15:10 , Carsten Bormann wrote: > On Jun 18, 2013, at 09:43, Norbert Lindenberg = wrote: >=20 >> JSON allows >=20 > are you trying to say >=20 > (a) a conforming parser is required to accept >=20 > or >=20 > (b) a conforming parser is not required to reject I mean "the JSON grammar allows" (the proposed text would go into a = subsection of the Grammar section). According to the last sentence of section 4, parsers are not required to = accept any characters or code points at all. Norbert= From cowan@ccil.org Sat Jun 22 22:47:42 2013 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 967A521F9BB9 for ; Sat, 22 Jun 2013 22:47:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.461 X-Spam-Level: X-Spam-Status: No, score=-3.461 tagged_above=-999 required=5 tests=[AWL=0.138, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dTPNKtw9m7Ih for ; Sat, 22 Jun 2013 22:47:38 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id 488DB21F9C09 for ; Sat, 22 Jun 2013 22:47:38 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1Uqd9B-0003Y9-Lk; Sun, 23 Jun 2013 01:47:33 -0400 Date: Sun, 23 Jun 2013 01:47:33 -0400 From: John Cowan To: Norbert Lindenberg Message-ID: <20130623054733.GA13346@mercury.ccil.org> References: <05A7D2E5-C119-4900-B52B-54B0F1206300@lindenbergsoftware.com> <64BAD44A-6C70-409E-BC93-0ED72E48AF49@lindenbergsoftware.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <64BAD44A-6C70-409E-BC93-0ED72E48AF49@lindenbergsoftware.com> User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Cc: Carsten Bormann , json@ietf.org Subject: Re: [Json] Proposal: Code points and surrogates X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 23 Jun 2013 05:47:42 -0000 Norbert Lindenberg scripsit: > According to the last sentence of section 4, parsers are not required > to accept any characters or code points at all. According to my reading of Section 4 as a whole, they are required to accept all JSON texts at first, but then are free to reject them afterwards. -- We do, doodley do, doodley do, doodley do, John Cowan What we must, muddily must, muddily must, muddily must; Muddily do, muddily do, muddily do, muddily do, http://www.ccil.org/~cowan Until we bust, bodily bust, bodily bust, bodily bust. --Bokonon From lear@cisco.com Sun Jun 23 22:25:51 2013 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 A80F511E811B for ; Sun, 23 Jun 2013 22:25:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.642 X-Spam-Level: X-Spam-Status: No, score=-110.642 tagged_above=-999 required=5 tests=[AWL=-0.044, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fq-p-uZMH6Wu for ; Sun, 23 Jun 2013 22:25:47 -0700 (PDT) Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id 9BD3421E80A9 for ; Sun, 23 Jun 2013 22:25:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7210; q=dns/txt; s=iport; t=1372051548; x=1373261148; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=BFgtKkHROAXQ28IlLHartVj3jFkoL06BWL4BD5uJftc=; b=Sv5lwg/RroHQck2fiRkNS61U4cWPpIN1qu6XFS+1QycrynxXMWaIHwfv PxvLMQOCO8Kt9XodJGnTQI3truV4wJuOvR1g4GDVj6m06ZHl4Q/2vthKY HNSbPDqcLhDmqRtLmM8SDHGxUhkm7Q+She9TPPD7oigzwSdeOR0rmlPv4 U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmEFABrXx1GQ/khR/2dsb2JhbABbgkVEMYNOhV22VX0WdIIjAQEBBAEBASBLCgEQCxgJFgsCAgkDAgECARUwBg0BBQIBAYgKDKgFkFkEj08Hgk+BFAOXQ5FEgxI6 X-IronPort-AV: E=Sophos;i="4.87,926,1363132800"; d="scan'208,217";a="14467829" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-3.cisco.com with ESMTP; 24 Jun 2013 05:25:46 +0000 Received: from ams3-vpn-dhcp5150.cisco.com (ams3-vpn-dhcp5150.cisco.com [10.61.84.29]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r5O5Pd7o019198 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 24 Jun 2013 05:25:42 GMT Message-ID: <51C7D853.1070704@cisco.com> Date: Mon, 24 Jun 2013 07:25:39 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: R S References: In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: multipart/alternative; boundary="------------080100070506010801010808" Cc: "json@ietf.org" Subject: Re: [Json] Proposal: the minimal edit X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 24 Jun 2013 05:25:51 -0000 This is a multi-part message in MIME format. --------------080100070506010801010808 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Robert, I like the idea for a minimal edit. I would be interested in what ends up in such a section. When it is thought to be complete I will want want to know what implementations should do to avoid interoperability problems. Once you've written that out in normative language, if we can get consensus on THAT I wonder if there will be ANY differences with ECMAscript. Interoperability is the issue. Eliot On 6/22/13 6:57 PM, R S wrote: > From charter: > > "The work is essentially a reclassification in place, with minimal > changes. The working group will review errata and update the document > as needed to incorporate those, and will correct significant errors > and inconsistencies, but will keep changes to a minimum." > > I propose a new section, to appear after "Generators" and before "IANA > Considerations" > > + N. Differences from ECMAScript > + > + ECMAScript implementations produce and consume primitive JSON values > at the > + root level of JSON documents. > > It's my opinion that none of the errors or inconsistencies present in > the document are significant, since JSON works pretty well. I'll > probably oppose any edits that aren't to the introduction or the > security considerations, including updates to references such as ABNF > and Unicode. Note that the IETF does not update all standards track > documents with obsolete references, which demonstrates that leaving > the current references in place is tractable. > > - Rob > > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json --------------080100070506010801010808 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Robert,

I like the idea for a minimal edit.  I would be interested in what ends up in such a section.  When it is thought to be complete I will want want to know what implementations should do to avoid interoperability problems.  Once you've written that out in normative language, if we can get consensus on THAT I wonder if there will be ANY differences with ECMAscript.

Interoperability is the issue.

Eliot

On 6/22/13 6:57 PM, R S wrote:
From charter:

"The work is essentially a reclassification in place, with minimal changes. The working group will review errata and update the document as needed to incorporate those, and will correct significant errors and inconsistencies, but will keep changes to a minimum."

I propose a new section, to appear after "Generators" and before "IANA Considerations"

+ N. Differences from ECMAScript
+
+ ECMAScript implementations produce and consume primitive JSON values at the 
+ root level of JSON documents.

It's my opinion that none of the errors or inconsistencies present in the document are significant, since JSON works pretty well. I'll probably oppose any edits that aren't to the introduction or the security considerations, including updates to references such as ABNF and Unicode. Note that the IETF does not update all standards track documents with obsolete references, which demonstrates that leaving the current references in place is tractable.

- Rob


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

--------------080100070506010801010808-- From duerst@it.aoyama.ac.jp Sun Jun 23 23:11:33 2013 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 3068F21F997F for ; Sun, 23 Jun 2013 23:11:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.237 X-Spam-Level: X-Spam-Status: No, score=-103.237 tagged_above=-999 required=5 tests=[AWL=0.553, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AhCPwTQn6ZEd for ; Sun, 23 Jun 2013 23:11:27 -0700 (PDT) Received: from scintmta02.scbb.aoyama.ac.jp (scintmta02.scbb.aoyama.ac.jp [133.2.253.34]) by ietfa.amsl.com (Postfix) with ESMTP id 6891D21F9815 for ; Sun, 23 Jun 2013 23:11:26 -0700 (PDT) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id r5O6BEbj031356; Mon, 24 Jun 2013 15:11:14 +0900 Received: from (unknown [133.2.206.134]) by scmse02.scbb.aoyama.ac.jp with smtp id 22e9_2237_dfe06804_dc94_11e2_994b_001e6722eec2; Mon, 24 Jun 2013 15:11:14 +0900 Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id 573E4C0002; Mon, 24 Jun 2013 15:09:48 +0900 (JST) Message-ID: <51C7E2ED.7000404@it.aoyama.ac.jp> Date: Mon, 24 Jun 2013 15:10:53 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: Tim Bray References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Mark Nottingham , Erik Wilde , "json@ietf.org" Subject: Re: [Json] Profiles in the JSON media type X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 24 Jun 2013 06:11:33 -0000 On 2013/06/23 6:56, Tim Bray wrote: > Hey Mark, what are the rules... if you want to use parameters on a > media-type, do you have to say so explicitly in the initial media-type > registration? -T They have to be explicitly described in the registration, but it's possible to add parameters when updating a registration. There was such a discussion just recently on the relevant mailing list, please see http://www.ietf.org/mail-archive/web/media-types. Of course the interoperability concerns with such additions should be considered carefully. Regards, Martin. From duerst@it.aoyama.ac.jp Sun Jun 23 23:18:35 2013 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 ED36321E80B8 for ; Sun, 23 Jun 2013 23:18:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.971 X-Spam-Level: X-Spam-Status: No, score=-102.971 tagged_above=-999 required=5 tests=[AWL=0.219, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_84=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dIXxBO-d57F9 for ; Sun, 23 Jun 2013 23:18:29 -0700 (PDT) Received: from scintmta02.scbb.aoyama.ac.jp (scintmta02.scbb.aoyama.ac.jp [133.2.253.34]) by ietfa.amsl.com (Postfix) with ESMTP id 1D81721E80B3 for ; Sun, 23 Jun 2013 23:18:28 -0700 (PDT) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id r5O6IP2a004531; Mon, 24 Jun 2013 15:18:25 +0900 Received: from (unknown [133.2.206.134]) by scmse02.scbb.aoyama.ac.jp with smtp id 22e5_17b5_e0ce013a_dc95_11e2_ae55_001e6722eec2; Mon, 24 Jun 2013 15:18:25 +0900 Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id 66DA8C0002; Mon, 24 Jun 2013 15:16:59 +0900 (JST) Message-ID: <51C7E49C.5040401@it.aoyama.ac.jp> Date: Mon, 24 Jun 2013 15:18:04 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: John Cowan References: <6BCAAC4F-2B45-43BA-A40B-96F3369A5851@tzi.org> <20130622005014.GA31186@mercury.ccil.org> In-Reply-To: <20130622005014.GA31186@mercury.ccil.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Tim Bray , Carsten Bormann , Jacob Davies , Paul Hoffman , JSON WG Subject: Re: [Json] Consensus call: establishing name equality X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 24 Jun 2013 06:18:36 -0000 On 2013/06/22 9:50, John Cowan wrote: > Jacob Davies scripsit: > >> C6 A process shall not assume that the interpretations of two >> canonical-equivalent character sequences are distinct. > > JSON, like XML, does not assume they are distinct: it decides that they > are distinct. This is what in Unicode is called a higher-order protocol. This is just playing with words. In the general use of the words, I'd think that "decide" is a specific(ally narrow) version of "assume". And just as a higher-order protocol would be extremely ill-advised to treat upper-case and lower-case characters as distinct in a situation where the two get converted into each other all the time, the same applies here. I don't remember having seen the phrase "higher-order protocol" anywhere near or in relationship to C6; if you have, I'd appreciate you telling me where. The truth of the matter is that C6, to a large extent, is based on wishful thinking: Canonically equivalent strings are one and the same, and software may and will convert from one normalization form to another at almost every corner, so you're never sure which one you get, and better don't bet on getting one or the other. In actual practice, the kinds of software that changes character normalization has turned out to be few and far between. The MacIntosh file system is (one of) the exception(s) that proves the rule. In particular, there are no known instances of changes of character normalization during network transit, which is what's most important for us here. Regards, Martin. From cabo@tzi.org Mon Jun 24 01:16:03 2013 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 41D4E21F9A82 for ; Mon, 24 Jun 2013 01:16:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.212 X-Spam-Level: X-Spam-Status: No, score=-106.212 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zsuhJlnydxqg for ; Mon, 24 Jun 2013 01:15:56 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 6244921F9A72 for ; Mon, 24 Jun 2013 01:15:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r5O8FUkV004860; Mon, 24 Jun 2013 10:15:30 +0200 (CEST) Received: from [192.168.217.105] (p548945FE.dip0.t-ipconnect.de [84.137.69.254]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 031BF7B40; Mon, 24 Jun 2013 10:15:29 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Content-Type: text/plain; charset=utf-8 From: Carsten Bormann In-Reply-To: Date: Mon, 24 Jun 2013 10:15:29 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <0C11C9BF-DD21-4863-A3C9-C3987EEA4B64@tzi.org> References: <6BCAAC4F-2B45-43BA-A40B-96F3369A5851@tzi.org> To: Jacob Davies X-Mailer: Apple Mail (2.1508) Cc: JSON WG Subject: Re: [Json] Consensus call: establishing name equality X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 24 Jun 2013 08:16:03 -0000 On Jun 22, 2013, at 01:54, Jacob Davies wrote: > Well, even given those givens, what about this: >=20 > http://www.unicode.org/versions/Unicode6.2.0/ch03.pdf > =46rom Section 3.2: >=20 > C6 A process shall not assume that the interpretations of two > canonical-equivalent character sequences are distinct. I think that this argument suffers a bit from not distinguishing a = string and its representation. JSON is never "interpreting" strings, so this clause doesn't seem to = apply. It *is* processing the representation of a string in order to derive the = actual string from that. E.g., by unescaping the character sequences in that representation into = the characters of the string, and by removing the enclosing quotes etc. = It may indeed be worth pointing out that this processing is not = "interpreting" the Unicode character sequences either *). (On of the persistent problems with IETF specifications is that the only = formal description method used widely, ABNF, makes the reader focus on = the representation, when actually it would often be more useful to focus = on the represented data object. It is almost always crucial to clearly = distinguish the two. Clearly, what we are interchanging are the = represented objects, so some purists argue we never need to even talk = about their interpretation. That is a fallacy, because there is no = interchange unless the interpretations match well enough.) I think the discussion here would benefit a lot from always clearly = making this distinction. "a" is not a three-character string, it is a three-character JSON = representation of a single-character string. Gr=C3=BC=C3=9Fe, Carsten *): How do you like "\u028=C3=A4"? Well, that may seem invalid and is a = bit hard to read, but if may mail client hadn't normalized it under my = fingers, it would be the same as "\u028a\u0308", which is a credible = upsilon diaeresis (=CA=8A=CC=88, always a two-character string as there = is no combined form). (In building JSON for interchange, it is probably = not so bright to assume it will never be normalized in transit. At = least if you assume that JSON should survive being sent around in e-mail = messages. But that observation is firmly in best practices land...) From mmorley@mpcm.com Mon Jun 24 09:13:13 2013 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 6CCD521E80F8 for ; Mon, 24 Jun 2013 09:13:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9eiajj34rqIA for ; Mon, 24 Jun 2013 09:13:13 -0700 (PDT) Received: from mail-la0-x229.google.com (mail-la0-x229.google.com [IPv6:2a00:1450:4010:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id 8ED8511E8146 for ; Mon, 24 Jun 2013 09:13:12 -0700 (PDT) Received: by mail-la0-f41.google.com with SMTP id fn20so10780736lab.28 for ; Mon, 24 Jun 2013 09:13:10 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :x-gm-message-state; bh=orZWVCNUwjCyQ8i6wLQRVYVlCV2Rm5+nmCy+Z7tD7c4=; b=XE0ymB/7EPzMFLjJ9bGP4L4UKfXWRjPalt4cerg9c3W45RQIQfsf0Mw7e8j56c4Hsa Okd6ht9/0BkMFRK7NixZWarhDR0fouCGqikxXHHxK7PwJGAGdkKWVFKwNEYqjZPlll3S PDfqnFkQeiefwIkgRudHBhButLKok3fTpR2YwE0+sKLobsDqOLDEsaiA/cM8mhtwIGc5 LRtFqwTc33sMvD/4IS7/962ts8hGbt/aidZLIHsjULt6B3+rDymLh228j98g3Ha9brOv scGiLxmPmB7SEQhnpB7LcuN9CqkRIpjhI845VxbHcqzkN9WoJayoPPI2Z+hlkCqN9ct6 Ga9g== MIME-Version: 1.0 X-Received: by 10.112.150.231 with SMTP id ul7mr13310803lbb.92.1372090390049; Mon, 24 Jun 2013 09:13:10 -0700 (PDT) Sender: mmorley@mpcm.com Received: by 10.114.187.113 with HTTP; Mon, 24 Jun 2013 09:13:09 -0700 (PDT) In-Reply-To: <90B659B8-D4AC-41AF-8C06-67FC65C8BD74@vpnc.org> References: <90B659B8-D4AC-41AF-8C06-67FC65C8BD74@vpnc.org> Date: Mon, 24 Jun 2013 12:13:09 -0400 X-Google-Sender-Auth: O2JyBC3edJk2djSdj3-YiAFxkaE Message-ID: From: Matthew Morley To: Paul Hoffman Content-Type: multipart/alternative; boundary=047d7b3434c24c825104dfe8b046 X-Gm-Message-State: ALoCoQnRm2oy7eKyI4xpstrpXvh0OrFU4UVvy2xqfVkNGVwmTntENhGXqbqjeorb3v4NK+pJz64I Cc: JSON WG Subject: Re: [Json] Consensus call: document title X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 24 Jun 2013 16:13:13 -0000 --047d7b3434c24c825104dfe8b046 Content-Type: text/plain; charset=ISO-8859-1 1,2 On Fri, Jun 21, 2013 at 12:38 PM, Paul Hoffman wrote: > There are three proposals for dealing with the document title: > 0) Leave the title in the current draft as-is: > The application/json Media Type for JavaScript Object Notation > (JSON) > 1) Change the title to > The JSON Data Interchange Format > 2) Change the title to > The JSON Format for Encoding Data > > Please respond to this message with a list of proposals you could accept, > ordered from highest to lowest. Do not list proposals you cannot live with. > If you cannot accept any of the proposals, please respond and say why. > > Based on the responses we receive, we will try to judge the consensus of > the WG. > > -- The JSON WG co-chairs > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > -- Matthew P. C. Morley --047d7b3434c24c825104dfe8b046 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
1,2


On Fri, Jun 21, 2013 at 12:38 PM, Paul Hoffman <paul.hoff= man@vpnc.org> wrote:
There are three proposals for dealing with t= he document title:
=A0 0) Leave the title in the current draft as-is:
=A0 =A0 =A0 =A0The application/json Media Type for JavaScript Object Notati= on (JSON)
=A0 1) Change the title to
=A0 =A0 =A0 =A0The JSON Data Interchange Format
=A0 2) Change the title to
=A0 =A0 =A0 =A0The JSON Format for Encoding Data

Please respond to this message with a list of proposals you could accept, o= rdered from highest to lowest. Do not list proposals you cannot live with. = If you cannot accept any of the proposals, please respond and say why.

Based on the responses we receive, we will try to judge the consensus of th= e WG.

-- The JSON WG co-chairs
_______________________________________________
json mailing list
json@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/json



--
Matthew P. C= . Morley
--047d7b3434c24c825104dfe8b046-- From cowan@ccil.org Mon Jun 24 09:52:41 2013 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 BAB3911E816D for ; Mon, 24 Jun 2013 09:52:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.463 X-Spam-Level: X-Spam-Status: No, score=-3.463 tagged_above=-999 required=5 tests=[AWL=0.136, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NLdHBuk-38OL for ; Mon, 24 Jun 2013 09:52:36 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id E715111E8168 for ; Mon, 24 Jun 2013 09:52:35 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1UrA0G-0008Nd-Lc; Mon, 24 Jun 2013 12:52:32 -0400 Date: Mon, 24 Jun 2013 12:52:32 -0400 From: John Cowan To: Carsten Bormann Message-ID: <20130624165232.GC11572@mercury.ccil.org> References: <6BCAAC4F-2B45-43BA-A40B-96F3369A5851@tzi.org> <0C11C9BF-DD21-4863-A3C9-C3987EEA4B64@tzi.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <0C11C9BF-DD21-4863-A3C9-C3987EEA4B64@tzi.org> User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Cc: Jacob Davies , JSON WG Subject: Re: [Json] Consensus call: establishing name equality X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 24 Jun 2013 16:52:41 -0000 Carsten Bormann scripsit: > (On of the persistent problems with IETF specifications is that the only > formal description method used widely, ABNF, makes the reader focus > on the representation, when actually it would often be more useful to > focus on the represented data object. It is almost always crucial to > clearly distinguish the two. Indeed it is! > Clearly, what we are interchanging are the represented objects, I would say just the opposite: clearly, what we are exchanging is the representations. The represented objects never go anywhere: they are re-created at the destination and are hopefully isomorphic to those that existed at the source. I'm not sure if you really disagree or it was just a lapsus linguae. > so some purists argue we never need to even talk about their > interpretation. That is a fallacy, because there is no interchange > unless the interpretations match well enough.) Indeed. > *): How do you like "\u028ä"? Well, that may seem invalid and is a > bit hard to read, but if may mail client hadn't normalized it under my > fingers, The moral here is never to place a combining character directly after markup, or it will combine with the markup. The W3C Character Model draft makes this point. > it would be the same as "\u028a\u0308", which is a credible > upsilon diaeresis Not so much; Latin upsilon (used in IPA) has serifs, which makes it quite un-Greek in form. The proper upsilon with diaeresis (dialytika) is U+03CB. -- John Cowan http://ccil.org/~cowan cowan@ccil.org [P]olice in many lands are now complaining that local arrestees are insisting on having their Miranda rights read to them, just like perps in American TV cop shows. When it's explained to them that they are in a different country, where those rights do not exist, they become outraged. --Neal Stephenson From ietf@lindenbergsoftware.com Mon Jun 24 11:07:21 2013 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 16D5621E8159 for ; Mon, 24 Jun 2013 11:07:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.412 X-Spam-Level: X-Spam-Status: No, score=-3.412 tagged_above=-999 required=5 tests=[AWL=-0.413, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yrlcdTSYZabc for ; Mon, 24 Jun 2013 11:07:15 -0700 (PDT) Received: from mirach.lunarpages.com (mirach.lunarpages.com [216.97.235.70]) by ietfa.amsl.com (Postfix) with ESMTP id 491DB21E8156 for ; Mon, 24 Jun 2013 11:07:15 -0700 (PDT) Received: from 50-0-136-241.dsl.dynamic.sonic.net ([50.0.136.241]:53824 helo=[192.168.0.5]) by mirach.lunarpages.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1UrBAV-0010NJ-FC; Mon, 24 Jun 2013 11:07:11 -0700 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=windows-1252 From: Norbert Lindenberg In-Reply-To: Date: Mon, 24 Jun 2013 11:07:08 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <54386FE8-9313-4840-836C-AAC6549B46BA@lindenbergsoftware.com> References: To: Tim Bray X-Mailer: Apple Mail (2.1283) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - mirach.lunarpages.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - lindenbergsoftware.com X-Get-Message-Sender-Via: mirach.lunarpages.com: authenticated_id: ietf@lindenbergsoftware.com Cc: Norbert Lindenberg , "json@ietf.org" , R S Subject: Re: [Json] Proposal: the minimal edit X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 24 Jun 2013 18:07:21 -0000 On Jun 22, 2013, at 10:31 , Tim Bray wrote: > So in Rob=92s proposed section: >=20 > ECMAScript implementations generate and consume unpaired Unicode = surrogate code points in JSON documents. What are "unpaired Unicode surrogate code points"? I'm familiar with = surrogate code points, and with unpaired surrogate code units in UTF-16. If you mean one of those, then this behavior is conformant with the JSON = grammar, specifically the "unescaped" production. The behavior likely = also exists in several other JSON implementations - for example, the = source code of the string parsing functions in the Java org.json library = and the C# fastJSON library doesn't seem to do anything to prevent = unpaired surrogate code units from passing through and escape sequences = from being unescaped to unpaired surrogate code units. Norbert= From ietf@lindenbergsoftware.com Mon Jun 24 11:28:32 2013 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 B4CD311E8173 for ; Mon, 24 Jun 2013 11:28:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.692 X-Spam-Level: X-Spam-Status: No, score=-3.692 tagged_above=-999 required=5 tests=[AWL=-0.093, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RpEnQlG3JhS5 for ; Mon, 24 Jun 2013 11:28:26 -0700 (PDT) Received: from mirach.lunarpages.com (mirach.lunarpages.com [216.97.235.70]) by ietfa.amsl.com (Postfix) with ESMTP id EC2D611E8151 for ; Mon, 24 Jun 2013 11:28:26 -0700 (PDT) Received: from 50-0-136-241.dsl.dynamic.sonic.net ([50.0.136.241]:53913 helo=[192.168.0.5]) by mirach.lunarpages.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1UrBV2-0014Un-5c; Mon, 24 Jun 2013 11:28:24 -0700 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Norbert Lindenberg In-Reply-To: <20130622185201.GO31186@mercury.ccil.org> Date: Mon, 24 Jun 2013 11:28:21 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <8EBBDB20-7455-4DCF-941A-3D91C1C05A72@lindenbergsoftware.com> References: <20130622185201.GO31186@mercury.ccil.org> To: John Cowan X-Mailer: Apple Mail (2.1283) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - mirach.lunarpages.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - lindenbergsoftware.com X-Get-Message-Sender-Via: mirach.lunarpages.com: authenticated_id: ietf@lindenbergsoftware.com Cc: Norbert Lindenberg , "json@ietf.org" , R S Subject: Re: [Json] Proposal: the minimal edit X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 24 Jun 2013 18:28:32 -0000 On Jun 22, 2013, at 11:52 , John Cowan wrote: > R S scripsit: >=20 >> It's my opinion that none of the errors or inconsistencies present in >> the document are significant, since JSON works pretty well. >=20 > It does at the level of an informational protocol, but not at the = level of > standards track. Would you be willing to sign a contract, = arm's-length, > with someone whose only constraint was that their code passed *some* > interpretation of the RFC? I certainly would not. As I pointed out > before, the parser conformance clause (first paragraph of Section 4) > is satisfied by any program that accepts arbitrary input and produces > arbitrary output distinct from the input (or indeed no output at all, > given the over-free wording in the second paragraph). I agree with John - for a standard, some of the errors, undefined = terminology, and inconsistencies seem unacceptable. The ones that worry = me in particular (I tend to worry about internationalization): - The RFC uses the term "Unicode character", which isn't defined in the = Unicode standard as far as I can tell. If it means "Unicode assigned = character", the most likely candidate, then it's inconsistent with the = "unescaped" production in the grammar, which allows all Unicode code = points. - The RFC says "JSON text SHALL be encoded in Unicode", which is = obviously meant as a normative statement, but, as John pointed out, is = meaningless because Unicode is not an encoding. Other text in the RFC = seems to assume that "encoded in Unicode" means "encoded in UTF-8, = UTF-16BE, UTF-16LE, UTF-32BE, or UTF-32-LE". Norbert= From ietf@lindenbergsoftware.com Mon Jun 24 11:41:37 2013 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 E8F5B11E8178 for ; Mon, 24 Jun 2013 11:41:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.687 X-Spam-Level: X-Spam-Status: No, score=-3.687 tagged_above=-999 required=5 tests=[AWL=-0.088, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IA77d4Tj+rmO for ; Mon, 24 Jun 2013 11:41:33 -0700 (PDT) Received: from mirach.lunarpages.com (mirach.lunarpages.com [216.97.235.70]) by ietfa.amsl.com (Postfix) with ESMTP id 268E811E8174 for ; Mon, 24 Jun 2013 11:41:33 -0700 (PDT) Received: from 50-0-136-241.dsl.dynamic.sonic.net ([50.0.136.241]:53939 helo=[192.168.0.5]) by mirach.lunarpages.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1UrBhh-00176B-5h; Mon, 24 Jun 2013 11:41:29 -0700 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=windows-1252 From: Norbert Lindenberg In-Reply-To: Date: Mon, 24 Jun 2013 11:41:26 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Tim Bray X-Mailer: Apple Mail (2.1283) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - mirach.lunarpages.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - lindenbergsoftware.com X-Get-Message-Sender-Via: mirach.lunarpages.com: authenticated_id: ietf@lindenbergsoftware.com Cc: Norbert Lindenberg , "json@ietf.org" , R S Subject: Re: [Json] Proposal: the minimal edit X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 24 Jun 2013 18:41:38 -0000 On Jun 22, 2013, at 10:48 , Tim Bray wrote: > BTW I should say that I have some sympathy with Rob=92s viewpoint = here. It looks like it might be hard to get consensus about the nits we = want to pick here on 4627, and JSON in the wild works just fine, and the = real de facto irritant is that ECMAScript does some non-4627-blessed = things. I=92m willing to put some more work into the struggle for = consensus, but if we just decided to give up, just add a =93Stupid = ECMAScript Tricks=94 section then declare victory, that wouldn=92t be a = terrible outcome. -T Which of these "non-4627-blessed things" is done only by ECMAScript? The = one Rob mentioned, producing and consuming primitive JSON values at the = root level, can also be found, e.g., in the JSON implementation in = Python: = http://docs.python.org/3/library/json.html#top-level-non-object-non-array-= values A section about ECMAScript may be useful because of the central position = of JavaScript in browsers in the web eco system. But the assumption that = all other JSON implementations are in agreement and only ECMAScript does = "stupid tricks" doesn't match reality. Norbert From cowan@ccil.org Mon Jun 24 11:53:27 2013 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 0D86E21E8167 for ; Mon, 24 Jun 2013 11:53:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.465 X-Spam-Level: X-Spam-Status: No, score=-3.465 tagged_above=-999 required=5 tests=[AWL=0.134, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t+NM9Ht0PHPO for ; Mon, 24 Jun 2013 11:53:21 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id 737DA21E8163 for ; Mon, 24 Jun 2013 11:53:16 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1UrBt5-0003UZ-0H; Mon, 24 Jun 2013 14:53:15 -0400 Date: Mon, 24 Jun 2013 14:53:14 -0400 From: John Cowan To: Norbert Lindenberg Message-ID: <20130624185314.GB19899@mercury.ccil.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Cc: R S , Tim Bray , "json@ietf.org" Subject: Re: [Json] Proposal: the minimal edit X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 24 Jun 2013 18:53:27 -0000 Norbert Lindenberg scripsit: > Which of these "non-4627-blessed things" is done only by ECMAScript? The > one Rob mentioned, producing and consuming primitive JSON values at > the root level, can also be found, e.g., in the JSON implementation > in Python: Yes, but that's just the *implementation* in Python. The Python *standard* (insofar as there is such a thing) has nothing to say about JSON, whereas the ECMAScript standard does. It's standard vs. standard that needs to be called out, not standard vs. implementation. -- Knowledge studies others / Wisdom is self-known; John Cowan Muscle masters brothers / Self-mastery is bone; cowan@ccil.org Content need never borrow / Ambition wanders blind; http://ccil.org/~cowan Vitality cleaves to the marrow / Leaving death behind. --Tao 33 (Bynner) From cabo@tzi.org Mon Jun 24 12:06:15 2013 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 C47D721E8170 for ; Mon, 24 Jun 2013 12:06:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.213 X-Spam-Level: X-Spam-Status: No, score=-106.213 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MhQiYUamlNy5 for ; Mon, 24 Jun 2013 12:06:09 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 84D0B21E8160 for ; Mon, 24 Jun 2013 12:06:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r5OJ67Rn023259; Mon, 24 Jun 2013 21:06:07 +0200 (CEST) Received: from [192.168.217.105] (p548945FE.dip0.t-ipconnect.de [84.137.69.254]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id F22F6320B; Mon, 24 Jun 2013 21:06:06 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <20130624165232.GC11572@mercury.ccil.org> Date: Mon, 24 Jun 2013 21:06:05 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <9FCF74E1-288A-44C5-A7F1-1EA01CBB5CFE@tzi.org> References: <6BCAAC4F-2B45-43BA-A40B-96F3369A5851@tzi.org> <0C11C9BF-DD21-4863-A3C9-C3987EEA4B64@tzi.org> <20130624165232.GC11572@mercury.ccil.org> To: John Cowan X-Mailer: Apple Mail (2.1508) Cc: JSON WG Subject: Re: [Json] Consensus call: establishing name equality X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 24 Jun 2013 19:06:15 -0000 Hey John, it is dangerous to write to a mailing list where people cite the = previous writer in Latin :-) On Jun 24, 2013, at 18:52, John Cowan wrote: > Carsten Bormann scripsit: >=20 >> Clearly, what we are interchanging are the represented objects, >=20 > I would say just the opposite: clearly, what we are exchanging is the > representations. =20 We completely agree. I was just using "represented" as a short form of "converted to a = representation". To repeat, we are not interchanging the objects, but representations of = them. >> a credible >> upsilon diaeresis=20 >=20 > Not so much; Latin upsilon (used in IPA) has serifs, which makes it > quite un-Greek in form. The proper upsilon with diaeresis (dialytika) > is U+03CB. I know that I should have added "IPA" to this... :-) (Of course, it just was a constructed example. =20 I have never seen this particular problem in actual interchange.) Gr=FC=DFe, Carsten From cabo@tzi.org Mon Jun 24 13:04:40 2013 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 CF9F411E8186 for ; Mon, 24 Jun 2013 13:04:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.214 X-Spam-Level: X-Spam-Status: No, score=-106.214 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XLPJVOS556pb for ; Mon, 24 Jun 2013 13:04:35 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id AEB3F11E8185 for ; Mon, 24 Jun 2013 13:04:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r5OK4SJf004523; Mon, 24 Jun 2013 22:04:28 +0200 (CEST) Received: from [192.168.217.105] (p548945FE.dip0.t-ipconnect.de [84.137.69.254]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id A9C59323C; Mon, 24 Jun 2013 22:04:27 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <20130624185314.GB19899@mercury.ccil.org> Date: Mon, 24 Jun 2013 22:04:26 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <4D90CADD-9197-4243-AE77-D03B48AFD2BC@tzi.org> References: <20130624185314.GB19899@mercury.ccil.org> To: John Cowan X-Mailer: Apple Mail (2.1508) Cc: Norbert Lindenberg , "json@ietf.org" , Tim Bray , R S Subject: Re: [Json] Proposal: the minimal edit X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 24 Jun 2013 20:04:40 -0000 On Jun 24, 2013, at 20:53, John Cowan wrote: > It's standard vs. standard that needs to be > called out, not standard vs. implementation. Actually, I'm more interested in interoperability standards reflecting = interoperability reality than reflecting other standards. There is a fine line to walk here, of course. In particular, "allowing" more and more deviations from a normative = reference encourages implementors to turn that normative reference into = soup *). So it is quite understandable that the community behind that = normative reference will be outraged each time that happens. Documenting reality is not enough. Behavior that creates = interoperability problems needs to be discouraged, even if it is = widespread. =20 Conformity is not enough. Behavior that creates interoperability = problems needs to be discouraged, even if it is condoned by a normative = reference. Gr=FC=DFe, Carsten *) I'm using that word as a technical term here. Quick usage example: HTML was based on SGML, but turned it into soup. From ietf@lindenbergsoftware.com Mon Jun 24 13:05:58 2013 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 4EC8111E8187 for ; Mon, 24 Jun 2013 13:05:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.683 X-Spam-Level: X-Spam-Status: No, score=-3.683 tagged_above=-999 required=5 tests=[AWL=-0.084, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m6+6LApxH-1y for ; Mon, 24 Jun 2013 13:05:53 -0700 (PDT) Received: from mirach.lunarpages.com (mirach.lunarpages.com [216.97.235.70]) by ietfa.amsl.com (Postfix) with ESMTP id 7E36011E8186 for ; Mon, 24 Jun 2013 13:05:53 -0700 (PDT) Received: from 50-0-136-241.dsl.dynamic.sonic.net ([50.0.136.241]:54207 helo=[192.168.0.5]) by mirach.lunarpages.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1UrD1K-001Mk4-Qm; Mon, 24 Jun 2013 13:05:50 -0700 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Norbert Lindenberg In-Reply-To: <20130624185314.GB19899@mercury.ccil.org> Date: Mon, 24 Jun 2013 13:05:46 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <27AE5D05-12CC-473E-B356-AA2B9B59E3F4@lindenbergsoftware.com> References: <20130624185314.GB19899@mercury.ccil.org> To: John Cowan X-Mailer: Apple Mail (2.1283) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - mirach.lunarpages.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - lindenbergsoftware.com X-Get-Message-Sender-Via: mirach.lunarpages.com: authenticated_id: ietf@lindenbergsoftware.com Cc: Norbert Lindenberg , "json@ietf.org" , Tim Bray , R S Subject: Re: [Json] Proposal: the minimal edit X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 24 Jun 2013 20:05:58 -0000 On Jun 24, 2013, at 11:53 , John Cowan wrote: > Norbert Lindenberg scripsit: >=20 >> Which of these "non-4627-blessed things" is done only by ECMAScript? = The >> one Rob mentioned, producing and consuming primitive JSON values at >> the root level, can also be found, e.g., in the JSON implementation >> in Python: >=20 > Yes, but that's just the *implementation* in Python. The Python = *standard* > (insofar as there is such a thing) has nothing to say about JSON, = whereas > the ECMAScript standard does. It's standard vs. standard that needs = to be > called out, not standard vs. implementation. If that's the intent of the proposed new section, it should start with = "The ECMAScript Language Specification [ECMA262] requires = implementations to ..." rather than "ECMAScript implementations ...". [ECMA262] Ecma International, "ECMAScript Language Specification", = Standard ECMA-262, 5.1 Edition, June 2011, . Norbert= From cowan@ccil.org Mon Jun 24 13:40:23 2013 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 0420421E8149 for ; Mon, 24 Jun 2013 13:40:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.467 X-Spam-Level: X-Spam-Status: No, score=-3.467 tagged_above=-999 required=5 tests=[AWL=0.132, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RRa3jMVqwcA9 for ; Mon, 24 Jun 2013 13:40:18 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id 9825321E8108 for ; Mon, 24 Jun 2013 13:40:18 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1UrDYe-000617-4Y; Mon, 24 Jun 2013 16:40:16 -0400 Date: Mon, 24 Jun 2013 16:40:16 -0400 From: John Cowan To: Norbert Lindenberg Message-ID: <20130624204016.GD19899@mercury.ccil.org> References: <20130624185314.GB19899@mercury.ccil.org> <27AE5D05-12CC-473E-B356-AA2B9B59E3F4@lindenbergsoftware.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <27AE5D05-12CC-473E-B356-AA2B9B59E3F4@lindenbergsoftware.com> User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Cc: R S , Tim Bray , "json@ietf.org" Subject: Re: [Json] Proposal: the minimal edit X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 24 Jun 2013 20:40:23 -0000 Norbert Lindenberg scripsit: > If that's the intent of the proposed new section, it should start > with "The ECMAScript Language Specification [ECMA262] requires > implementations to ..." rather than "ECMAScript implementations ...". +1 -- John Cowan http://www.ccil.org/~cowan The internet is a web of tiny tyrannies giving an illusion of anarchy. --David Rush From paul.hoffman@vpnc.org Mon Jun 24 14:28:28 2013 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 2B26811E8188 for ; Mon, 24 Jun 2013 14:28:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.511 X-Spam-Level: X-Spam-Status: No, score=-102.511 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BMn5R+Tnmubk for ; Mon, 24 Jun 2013 14:28:26 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id D4D0711E8166 for ; Mon, 24 Jun 2013 14:28:26 -0700 (PDT) Received: from [10.20.30.90] (50-0-66-165.dsl.dynamic.sonic.net [50.0.66.165]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r5OLSL6P086960 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 24 Jun 2013 14:28:22 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Paul Hoffman In-Reply-To: Date: Mon, 24 Jun 2013 14:28:21 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: R S X-Mailer: Apple Mail (2.1508) Cc: "json@ietf.org WG" Subject: Re: [Json] Proposal: the minimal edit X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 24 Jun 2013 21:28:28 -0000 A few people on this thread have said they might support Rob's idea if = they knew all the changes, and a few changes were thrown back and forth. = I propose the following is a full set of what is needed. Please note the = wording at the beginning of the proposed Section 1.3: this is about what = ECMAScript actually says about JSON, not what that means to ECMAScript = implementations. Thoughts? --Paul Hoffman Add Section 1.2, "Changes from RFC 4627" This section lists all changes between this document and the text in RFC 4627. - Applied errata #607 from RFC 4627 to correctly align the artwork for the definition of "object". - Applied errata #3607 from RFC 4627 by removing the security consideration that begins "A JSON text can be safely passed" and the JavaScript code that went with that consideration. - Added Section 1.3, "Differences from the JSON Definition in = ECMAScript".=20 - Changed the [ECMA] and [UNICODE] references to be = non-version-specific. Add Section 1.3, "Differences from the JSON Definition in ECMAScript" The following lists the known major differences between this document = and the definition of JSON in Section 15.12 of [ECMA]. - ECMAScript implementations produce and consume primitive JSON = values at the root level of JSON documents. - ECMAScript implementations can generate and consume code points in = JSON strings that are not Unicode characters. - When there are duplicate names within an object, ECMAScript JSON = parsers overwrite the value corresponding to such names with the value that appears last in the = serialization. In Section 6, remove "A JSON text can be safely passed" and the = JavaScript code in the following paragraph. In Section 9, change the title in the reference to [ECMA] to be be = non-version-specific: [ECMA] European Computer Manufacturers Association, "ECMAScript Language Specification", . In Section 9, change the reference to [UNICODE] to be be = non-version-specific: [UNICODE] The Unicode Consortium, "The Unicode Standard", . From tbray@textuality.com Mon Jun 24 14:42:59 2013 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 A1AAA21F9F1F for ; Mon, 24 Jun 2013 14:42:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.206 X-Spam-Level: X-Spam-Status: No, score=-0.206 tagged_above=-999 required=5 tests=[AWL=-0.658, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_SORBS_DUL=0.877, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oGgb33CfpRLR for ; Mon, 24 Jun 2013 14:42:56 -0700 (PDT) Received: from mail-ve0-x230.google.com (mail-ve0-x230.google.com [IPv6:2607:f8b0:400c:c01::230]) by ietfa.amsl.com (Postfix) with ESMTP id BCEA721F9F09 for ; Mon, 24 Jun 2013 14:42:55 -0700 (PDT) Received: by mail-ve0-f176.google.com with SMTP id c13so9266374vea.7 for ; Mon, 24 Jun 2013 14:42:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=t+2wx2CIiPs5SX69R7Jml0xGInTfX4oU9i92KVGpDP8=; b=M28LAO9glKM2gYRSmm4Of1HSiYKNH+bZhThur1GLJ5RvVCeQ8qMPOY81IVeA5gJuc0 nc6Mb7od3x2OThDf+Ok4uu8U4IX8lASMDi1BUzNs8mZjoWgvea1Lr+rGyfoujQ7A0J25 RyZ2Fskx4fBxZNNqbq4ttwoC/eZFcOKJvuF2AWAfxbTaJLIQFNg5Pq5v21Qz3FATxoyO j7+p4vAi99KDAlZU5HgK4ouMRtSg10omn0IqHqZtjHjRE0rL0w+h4Pvbp9RTm+SVl2DP Oa7hsBD3IBcRcBO4+biqFNWfJ3fgNYAFatYwT4gP/jozFGI/Kk452QehgHRxggPsKycp 6jwQ== MIME-Version: 1.0 X-Received: by 10.220.48.73 with SMTP id q9mr12297290vcf.36.1372110175231; Mon, 24 Jun 2013 14:42:55 -0700 (PDT) Received: by 10.220.219.200 with HTTP; Mon, 24 Jun 2013 14:42:55 -0700 (PDT) X-Originating-IP: [96.49.81.176] In-Reply-To: References: Date: Mon, 24 Jun 2013 14:42:55 -0700 Message-ID: From: Tim Bray To: Paul Hoffman Content-Type: multipart/alternative; boundary=001a11c2e25896766004dfed4bad X-Gm-Message-State: ALoCoQngNJGvBxpQ8V2Rnl4x2jT3PaSW7IYbazn1SfMg6f+GPxoYXMUZrSBeK+P8rFwQlU3ezZHN Cc: "json@ietf.org WG" , R S Subject: Re: [Json] Proposal: the minimal edit X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 24 Jun 2013 21:42:59 -0000 --001a11c2e25896766004dfed4bad Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable In general I=E2=80=99d support this, with one nit: s/that are not Unicode characters/that can never be Unicode characters/ (just to make it clear we=E2=80=99re not talking about unassigned code points, which don't seem to distress anyone). Strongest argument in favor of this approach: JSON works. -T On Mon, Jun 24, 2013 at 2:28 PM, Paul Hoffman wrote= : > > > A few people on this thread have said they might support Rob's idea if > they knew all the changes, and a few changes were thrown back and forth. = I > propose the following is a full set of what is needed. Please note the > wording at the beginning of the proposed Section 1.3: this is about what > ECMAScript actually says about JSON, not what that means to ECMAScript > implementations. > > Thoughts? > > --Paul Hoffman > > Add Section 1.2, "Changes from RFC 4627" > > This section lists all changes between this document and the text in > RFC 4627. > > - Applied errata #607 from RFC 4627 to correctly align the artwork > for the definition of "object". > > - Applied errata #3607 from RFC 4627 by removing the security > consideration that begins "A JSON text can be safely passed" > and the JavaScript code that went with that consideration. > > - Added Section 1.3, "Differences from the JSON Definition in > ECMAScript". > > - Changed the [ECMA] and [UNICODE] references to be > non-version-specific. > > Add Section 1.3, "Differences from the JSON Definition in ECMAScript" > > The following lists the known major differences between this document > and the definition of JSON > in Section 15.12 of [ECMA]. > > - ECMAScript implementations produce and consume primitive JSON values > at the root level of JSON > documents. > > - ECMAScript implementations can generate and consume code points in > JSON strings that are not > Unicode characters. > > - When there are duplicate names within an object, ECMAScript JSON > parsers overwrite the value > corresponding to such names with the value that appears last in the > serialization. > > In Section 6, remove "A JSON text can be safely passed" and the JavaScrip= t > code in the following > paragraph. > > In Section 9, change the title in the reference to [ECMA] to be be > non-version-specific: > > [ECMA] European Computer Manufacturers Association, "ECMAScript > Language Specification", > ecma-st/ECMA-262.pdf>. > > In Section 9, change the reference to [UNICODE] to be be > non-version-specific: > > [UNICODE] The Unicode Consortium, "The Unicode Standard", > . > > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > --001a11c2e25896766004dfed4bad Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
In general I=E2=80=99d support this, with one nit: s/= that are not Unicode=20 characters/that can never be Unicode characters/ (just to make it clear=20 we=E2=80=99re not talking about unassigned code points, which don't see= m to=20 distress anyone).

Strongest argument in favor of this approach: JSON works. -T


On Mon, Jun = 24, 2013 at 2:28 PM, Paul Hoffman <paul.hoffman@vpnc.org> wrote:
<no hat>

A few people on this thread have said they might support Rob's idea if = they knew all the changes, and a few changes were thrown back and forth. I = propose the following is a full set of what is needed. Please note the word= ing at the beginning of the proposed Section 1.3: this is about what ECMASc= ript actually says about JSON, not what that means to ECMAScript implementa= tions.

Thoughts?

--Paul Hoffman

Add Section 1.2, "Changes from RFC 4627"

=C2=A0 =C2=A0This section lists all changes between this document and the t= ext in
=C2=A0 =C2=A0RFC 4627.

=C2=A0 =C2=A0- Applied errata #607 from RFC 4627 to correctly align the art= work
=C2=A0 =C2=A0 =C2=A0for the definition of "object".

=C2=A0 =C2=A0- Applied errata #3607 from RFC 4627 by removing the security<= br> =C2=A0 =C2=A0 =C2=A0consideration that begins "A JSON text can be safe= ly passed"
=C2=A0 =C2=A0 =C2=A0and the JavaScript code that went with that considerati= on.

=C2=A0 =C2=A0- Added Section 1.3, "Differences from the JSON Definitio= n in ECMAScript".

=C2=A0 =C2=A0- Changed the [ECMA] and [UNICODE] references to be non-versio= n-specific.

Add Section 1.3, "Differences from the JSON Definition in ECMAScript&q= uot;

=C2=A0 =C2=A0The following lists the known major differences between this d= ocument and the definition of JSON
=C2=A0 =C2=A0in Section 15.12 of [ECMA].

=C2=A0 =C2=A0- ECMAScript implementations produce and consume primitive JSO= N values at the root level of JSON
=C2=A0 =C2=A0 =C2=A0documents.

=C2=A0 =C2=A0- ECMAScript implementations can generate and consume code poi= nts in JSON strings that are not
=C2=A0 =C2=A0 =C2=A0Unicode characters.

=C2=A0 =C2=A0- When there are duplicate names within an object, ECMAScript = JSON parsers overwrite the value
=C2=A0 =C2=A0 =C2=A0corresponding to such names with the value that appears= last in the serialization.

In Section 6, remove "A JSON text can be safely passed" and the J= avaScript code in the following
paragraph.

In Section 9, change the title in the reference to [ECMA] to be be non-vers= ion-specific:

=C2=A0 =C2=A0[ECMA] =C2=A0 =C2=A0European Computer Manufacturers Associatio= n, "ECMAScript
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Language Specification"= ;,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<http://www.ecm= a-international.org/publications/files/
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ecma-st/ECMA-262.pdf>.
In Section 9, change the reference to [UNICODE] to be be non-version-specif= ic:

=C2=A0 =C2=A0[UNICODE] =C2=A0The Unicode Consortium, "The Unicode Stan= dard",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <http://www.unicode.org/vers= ions/latest/>.


_______________________________________________
json mailing list
json@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/json

--001a11c2e25896766004dfed4bad-- From dret@berkeley.edu Mon Jun 24 16:00:01 2013 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 BF23121E80C9 for ; Mon, 24 Jun 2013 16:00:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.449 X-Spam-Level: X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nxJJVYZlb2Q8 for ; Mon, 24 Jun 2013 15:59:57 -0700 (PDT) Received: from cm05fe.IST.Berkeley.EDU (cm05fe.IST.Berkeley.EDU [169.229.218.146]) by ietfa.amsl.com (Postfix) with ESMTP id 8E52221F9EEE for ; Mon, 24 Jun 2013 15:59:57 -0700 (PDT) Received: from mobile-166-137-186-253.mycingular.net ([166.137.186.253] helo=dretair.local) by cm05fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth plain:dret@berkeley.edu) (envelope-from ) id 1UrFjl-0002TD-H8; Mon, 24 Jun 2013 15:59:55 -0700 Message-ID: <51C8CF6D.7000806@berkeley.edu> Date: Mon, 24 Jun 2013 15:59:57 -0700 From: Erik Wilde User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= References: <51C7E2ED.7000404@it.aoyama.ac.jp> In-Reply-To: <51C7E2ED.7000404@it.aoyama.ac.jp> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: Mark Nottingham , Tim Bray , "json@ietf.org" Subject: Re: [Json] Profiles in the JSON media type X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 24 Jun 2013 23:00:02 -0000 hello martin. On 2013-06-23 23:10 , "Martin J. Dürst" wrote: > They have to be explicitly described in the registration, but it's > possible to add parameters when updating a registration. There was such > a discussion just recently on the relevant mailing list, please see > http://www.ietf.org/mail-archive/web/media-types. > Of course the interoperability concerns with such additions should be > considered carefully. that of course is very true. however, in the case of profiles, you can look at them as "hints" which are not allowed to change the semantics of the basic media type. so i would assume that if the profile parameter is ignored, no harm is being done. but then again, components could also start throwing errors because of an unknown parameter showing up, and i guess that problem simply cannot be avoided. fyi: http://tools.ietf.org/html/draft-wilde-atom-profile-01 is a draft for re-registering the atom media type with the exact same goal of adding a profile media type parameter. cheers, dret. -- erik wilde | mailto:dret@berkeley.edu - tel:+1-510-2061079 | | UC Berkeley - School of Information (ISchool) | | http://dret.net/netdret http://twitter.com/dret | From cowan@ccil.org Mon Jun 24 16:35:29 2013 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 DECC521F9EC2 for ; Mon, 24 Jun 2013 16:35:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.469 X-Spam-Level: X-Spam-Status: No, score=-3.469 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o+zFB8MIxlB7 for ; Mon, 24 Jun 2013 16:35:25 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id 90D2621F9EBA for ; Mon, 24 Jun 2013 16:35:24 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1UrGI5-0006ce-37; Mon, 24 Jun 2013 19:35:21 -0400 Date: Mon, 24 Jun 2013 19:35:21 -0400 From: John Cowan To: Tim Bray Message-ID: <20130624233521.GF19899@mercury.ccil.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Cc: R S , Paul Hoffman , "json@ietf.org WG" Subject: Re: [Json] Proposal: the minimal edit X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 24 Jun 2013 23:35:30 -0000 Tim Bray scripsit: > In general I’d support this, with one nit: s/that are not Unicode > characters/that can never be Unicode characters/ (just to make it clear > we’re not talking about unassigned code points, which don't seem to > distress anyone). Well, that excludes not only surrogate code points, which are the really dangerous ones (because they have no standard representation) but non-character code points as well, which shouldn't be interchanged but aren't actually dangerous. I don't know if you mean to do that or not. -- The experiences of the past show John Cowan that there has always been a discrepancy cowan@ccil.org between plans and performance. http://www.ccil.org/~cowan --Emperor Hirohito, August 1945 From paul.hoffman@vpnc.org Mon Jun 24 16:42:18 2013 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 B086B11E817F for ; Mon, 24 Jun 2013 16:42:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.513 X-Spam-Level: X-Spam-Status: No, score=-102.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2GebPIZzVuE5 for ; Mon, 24 Jun 2013 16:42:17 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id D658F11E8167 for ; Mon, 24 Jun 2013 16:42:17 -0700 (PDT) Received: from [10.20.30.90] (50-0-66-165.dsl.dynamic.sonic.net [50.0.66.165]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r5ONgFh3090798 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 24 Jun 2013 16:42:16 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Paul Hoffman In-Reply-To: <20130624233521.GF19899@mercury.ccil.org> Date: Mon, 24 Jun 2013 16:42:15 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <3D442E5F-F9ED-47DB-9E1D-29ACA8588717@vpnc.org> References: <20130624233521.GF19899@mercury.ccil.org> To: John Cowan X-Mailer: Apple Mail (2.1508) Cc: "json@ietf.org WG" Subject: Re: [Json] Proposal: the minimal edit X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 24 Jun 2013 23:42:18 -0000 On Jun 24, 2013, at 4:35 PM, John Cowan wrote: > Tim Bray scripsit: >=20 >> In general I=92d support this, with one nit: s/that are not Unicode >> characters/that can never be Unicode characters/ (just to make it = clear >> we=92re not talking about unassigned code points, which don't seem to >> distress anyone). >=20 > Well, that excludes not only surrogate code points, which are the = really > dangerous ones (because they have no standard representation) but = non-character > code points as well, which shouldn't be interchanged but aren't = actually > dangerous. I don't know if you mean to do that or not. I'm not sure what you mean by "exclude". The sentence Tim was referring = to is about inclusion: - ECMAScript implementations can generate and consume code points in = JSON strings that are not Unicode characters. --Paul Hoffman= From ietf@lindenbergsoftware.com Mon Jun 24 16:58:26 2013 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 90BC821F9D1D for ; Mon, 24 Jun 2013 16:58:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.679 X-Spam-Level: X-Spam-Status: No, score=-3.679 tagged_above=-999 required=5 tests=[AWL=-0.080, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IzmrxkBuVvCU for ; Mon, 24 Jun 2013 16:58:20 -0700 (PDT) Received: from mirach.lunarpages.com (mirach.lunarpages.com [216.97.235.70]) by ietfa.amsl.com (Postfix) with ESMTP id 5506321F9D72 for ; Mon, 24 Jun 2013 16:58:20 -0700 (PDT) Received: from 50-0-136-241.dsl.dynamic.sonic.net ([50.0.136.241]:55038 helo=[192.168.0.5]) by mirach.lunarpages.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1UrGeH-001vde-Bj; Mon, 24 Jun 2013 16:58:17 -0700 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=windows-1252 From: Norbert Lindenberg In-Reply-To: <3D442E5F-F9ED-47DB-9E1D-29ACA8588717@vpnc.org> Date: Mon, 24 Jun 2013 16:58:14 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <3BBF18FB-63DE-40DE-93B4-1F8343386872@lindenbergsoftware.com> References: <20130624233521.GF19899@mercury.ccil.org> <3D442E5F-F9ED-47DB-9E1D-29ACA8588717@vpnc.org> To: Paul Hoffman , John Cowan , Tim Bray X-Mailer: Apple Mail (2.1283) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - mirach.lunarpages.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - lindenbergsoftware.com X-Get-Message-Sender-Via: mirach.lunarpages.com: authenticated_id: ietf@lindenbergsoftware.com Cc: Norbert Lindenberg , "json@ietf.org WG" Subject: Re: [Json] Proposal: the minimal edit X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 24 Jun 2013 23:58:26 -0000 On Jun 24, 2013, at 16:42 , Paul Hoffman wrote: > On Jun 24, 2013, at 4:35 PM, John Cowan = wrote: >=20 >> Tim Bray scripsit: >>=20 >>> In general I=92d support this, with one nit: s/that are not Unicode >>> characters/that can never be Unicode characters/ (just to make it = clear >>> we=92re not talking about unassigned code points, which don't seem = to >>> distress anyone). >>=20 >> Well, that excludes not only surrogate code points, which are the = really >> dangerous ones (because they have no standard representation) but = non-character >> code points as well, which shouldn't be interchanged but aren't = actually >> dangerous. I don't know if you mean to do that or not. >=20 > I'm not sure what you mean by "exclude". The sentence Tim was = referring to is about inclusion: >=20 > - ECMAScript implementations can generate and consume code points in = JSON strings that are not > Unicode characters. Which definition of "Unicode character" are the three of you referring = to? Thanks, Norbert From tbray@textuality.com Mon Jun 24 17:05:26 2013 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 8022021E8159 for ; Mon, 24 Jun 2013 17:05:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.168 X-Spam-Level: X-Spam-Status: No, score=-0.168 tagged_above=-999 required=5 tests=[AWL=-0.620, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_SORBS_DUL=0.877, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ivKVsJY5Em-Q for ; Mon, 24 Jun 2013 17:05:21 -0700 (PDT) Received: from mail-ve0-x22c.google.com (mail-ve0-x22c.google.com [IPv6:2607:f8b0:400c:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 45AB721E814A for ; Mon, 24 Jun 2013 17:05:21 -0700 (PDT) Received: by mail-ve0-f172.google.com with SMTP id jz10so9483430veb.17 for ; Mon, 24 Jun 2013 17:05:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=KLnlyLjqPd7Q0dMUq3+UXNHtlt9WLO71lvDQkzMG5kw=; b=L6oGEeAG3dCe4W22FdceHjPfkuG8Ss7dUXMlwvHDygP2Q5WJCWTmTWc5lso3Fcomho 2/5/tAkLP2CpQ+C9snT+8trIHGdObxj+9CQdlzrhpgIIdoRs6RslTGI22oSdEPFIYa2B bCIeiVPwf42xIGQlqseHTA/BFWv4I/Cd+HC0Llqtq32VrjcxxQnbmhk1ZuUoFBvjzve+ e03uQVk2tfaMox23sGDoSaZaSOzY6IZQB2A4o/F0YwCsYS6pk2Ey38gU2j5s9r4cJq35 jlpTpHVMRlxpCHb6Q7/aRpGb6IUXNn/Ku/xNEOq7oNAPucnlGqBJtCDU3vheA4yATV08 sGcA== MIME-Version: 1.0 X-Received: by 10.221.36.4 with SMTP id sy4mr3728286vcb.11.1372118720682; Mon, 24 Jun 2013 17:05:20 -0700 (PDT) Received: by 10.220.219.200 with HTTP; Mon, 24 Jun 2013 17:05:20 -0700 (PDT) X-Originating-IP: [96.49.81.176] In-Reply-To: <3BBF18FB-63DE-40DE-93B4-1F8343386872@lindenbergsoftware.com> References: <20130624233521.GF19899@mercury.ccil.org> <3D442E5F-F9ED-47DB-9E1D-29ACA8588717@vpnc.org> <3BBF18FB-63DE-40DE-93B4-1F8343386872@lindenbergsoftware.com> Date: Mon, 24 Jun 2013 17:05:20 -0700 Message-ID: From: Tim Bray To: Norbert Lindenberg Content-Type: multipart/alternative; boundary=001a11339f38efb1f904dfef4828 X-Gm-Message-State: ALoCoQmPgzaKAba3nDVG32I6WCUrrwqqkaXjOzmqF9mdE5MSlmX1R5U3d6+837UAf0ZI2jyNBZ0G Cc: John Cowan , Paul Hoffman , "json@ietf.org WG" Subject: Re: [Json] Proposal: the minimal edit X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 25 Jun 2013 00:05:26 -0000 --001a11339f38efb1f904dfef4828 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I meant Surrogates or Noncharacters (per Unicode section 2.4). -T On Mon, Jun 24, 2013 at 4:58 PM, Norbert Lindenberg < ietf@lindenbergsoftware.com> wrote: > > On Jun 24, 2013, at 16:42 , Paul Hoffman wrote: > > > On Jun 24, 2013, at 4:35 PM, John Cowan wrote: > > > >> Tim Bray scripsit: > >> > >>> In general I=E2=80=99d support this, with one nit: s/that are not Uni= code > >>> characters/that can never be Unicode characters/ (just to make it cle= ar > >>> we=E2=80=99re not talking about unassigned code points, which don't s= eem to > >>> distress anyone). > >> > >> Well, that excludes not only surrogate code points, which are the real= ly > >> dangerous ones (because they have no standard representation) but > non-character > >> code points as well, which shouldn't be interchanged but aren't actual= ly > >> dangerous. I don't know if you mean to do that or not. > > > > I'm not sure what you mean by "exclude". The sentence Tim was referring > to is about inclusion: > > > > - ECMAScript implementations can generate and consume code points in > JSON strings that are not > > Unicode characters. > > Which definition of "Unicode character" are the three of you referring to= ? > > Thanks, > Norbert > > --001a11339f38efb1f904dfef4828 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I meant Surrogates or Noncharacters (per Unicode section 2= .4). -T


On Mon, Jun 24, 2013 at 4:58 PM, Norbert Lindenberg &= lt;ietf@li= ndenbergsoftware.com> wrote:

On Jun 24, 2013, at 16:42 , Paul Hoffman wrote:

> On Jun 24, 2013, at 4:35 PM, John Cowan <cowan@mercury.ccil.org> wrote:
>
>> Tim Bray scripsit:
>>
>>> In general I=E2=80=99d support this, with one nit: s/that are = not Unicode
>>> characters/that can never be Unicode characters/ (just to make= it clear
>>> we=E2=80=99re not talking about unassigned code points, which = don't seem to
>>> distress anyone).
>>
>> Well, that excludes not only surrogate code points, which are the = really
>> dangerous ones (because they have no standard representation) but = non-character
>> code points as well, which shouldn't be interchanged but aren&= #39;t actually
>> dangerous. =C2=A0I don't know if you mean to do that or not. >
> I'm not sure what you mean by "exclude". The sentence Ti= m was referring to is about inclusion:
>
> =C2=A0- ECMAScript implementations can generate and consume code point= s in JSON strings that are not
> =C2=A0 =C2=A0Unicode characters.

Which definition of "Unicode character" are the three of yo= u referring to?

Thanks,
Norbert


--001a11339f38efb1f904dfef4828-- From paul.hoffman@vpnc.org Mon Jun 24 17:28:05 2013 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 EC5DE21E8149 for ; Mon, 24 Jun 2013 17:28:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.514 X-Spam-Level: X-Spam-Status: No, score=-102.514 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3eLx-cNYWn5b for ; Mon, 24 Jun 2013 17:28:05 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 15EEF21E8132 for ; Mon, 24 Jun 2013 17:28:05 -0700 (PDT) Received: from [10.20.30.90] (50-0-66-165.dsl.dynamic.sonic.net [50.0.66.165]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r5P0S2T7092202 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 24 Jun 2013 17:28:03 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Paul Hoffman In-Reply-To: <3BBF18FB-63DE-40DE-93B4-1F8343386872@lindenbergsoftware.com> Date: Mon, 24 Jun 2013 17:28:02 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <6B5B32EF-E4EA-461A-8C73-262375703A04@vpnc.org> References: <20130624233521.GF19899@mercury.ccil.org> <3D442E5F-F9ED-47DB-9E1D-29ACA8588717@vpnc.org> <3BBF18FB-63DE-40DE-93B4-1F8343386872@lindenbergsoftware.com> To: Norbert Lindenberg X-Mailer: Apple Mail (2.1508) Cc: "json@ietf.org WG" Subject: Re: [Json] Proposal: the minimal edit X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 25 Jun 2013 00:28:06 -0000 On Jun 24, 2013, at 4:58 PM, Norbert Lindenberg = wrote: >=20 > On Jun 24, 2013, at 16:42 , Paul Hoffman wrote: >=20 >> On Jun 24, 2013, at 4:35 PM, John Cowan = wrote: >>=20 >>> Tim Bray scripsit: >>>=20 >>>> In general I=92d support this, with one nit: s/that are not Unicode >>>> characters/that can never be Unicode characters/ (just to make it = clear >>>> we=92re not talking about unassigned code points, which don't seem = to >>>> distress anyone). >>>=20 >>> Well, that excludes not only surrogate code points, which are the = really >>> dangerous ones (because they have no standard representation) but = non-character >>> code points as well, which shouldn't be interchanged but aren't = actually >>> dangerous. I don't know if you mean to do that or not. >>=20 >> I'm not sure what you mean by "exclude". The sentence Tim was = referring to is about inclusion: >>=20 >> - ECMAScript implementations can generate and consume code points in = JSON strings that are not >> Unicode characters. >=20 > Which definition of "Unicode character" are the three of you referring = to? Does it actually matter? This thread is about making minimal changes to = the current spec. The current spec says "Unicode characters". The = proposed addition to the spec indicates that, for some definition of = "Unicode character" that is not in RFC 4627, ECMAScript can have strings = with more than just Unicode characters. Do you believe that proposed sentence is incorrect? --Paul Hoffman= From cowan@ccil.org Mon Jun 24 18:28:53 2013 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 64ACF21E8156 for ; Mon, 24 Jun 2013 18:28:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.471 X-Spam-Level: X-Spam-Status: No, score=-3.471 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id obyot9YN-JTH for ; Mon, 24 Jun 2013 18:28:48 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id F26F621E812C for ; Mon, 24 Jun 2013 18:28:47 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1UrI3q-00012h-Ec; Mon, 24 Jun 2013 21:28:46 -0400 Date: Mon, 24 Jun 2013 21:28:46 -0400 From: John Cowan To: Paul Hoffman Message-ID: <20130625012846.GL19899@mercury.ccil.org> References: <20130624233521.GF19899@mercury.ccil.org> <3D442E5F-F9ED-47DB-9E1D-29ACA8588717@vpnc.org> <3BBF18FB-63DE-40DE-93B4-1F8343386872@lindenbergsoftware.com> <6B5B32EF-E4EA-461A-8C73-262375703A04@vpnc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6B5B32EF-E4EA-461A-8C73-262375703A04@vpnc.org> User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Cc: Norbert Lindenberg , "json@ietf.org WG" Subject: Re: [Json] Proposal: the minimal edit X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 25 Jun 2013 01:28:53 -0000 Paul Hoffman scripsit: > Do you believe that proposed sentence is incorrect? No, nor is "Cats are members of the species _Felis catus_." But what business either one has in the proposed spec is unclear. -- Real FORTRAN programmers can program FORTRAN John Cowan in any language. --Ed Post cowan@ccil.org From cowan@ccil.org Mon Jun 24 18:30:02 2013 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 C8D8F21E8168 for ; Mon, 24 Jun 2013 18:30:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.473 X-Spam-Level: X-Spam-Status: No, score=-3.473 tagged_above=-999 required=5 tests=[AWL=0.126, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wnxHpwjRkspV for ; Mon, 24 Jun 2013 18:29:58 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id 73C1121E814A for ; Mon, 24 Jun 2013 18:29:58 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1UrHuT-00007Z-2j; Mon, 24 Jun 2013 21:19:05 -0400 Date: Mon, 24 Jun 2013 21:19:05 -0400 From: John Cowan To: Paul Hoffman Message-ID: <20130625011904.GJ19899@mercury.ccil.org> References: <20130624233521.GF19899@mercury.ccil.org> <3D442E5F-F9ED-47DB-9E1D-29ACA8588717@vpnc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3D442E5F-F9ED-47DB-9E1D-29ACA8588717@vpnc.org> User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Cc: "json@ietf.org WG" Subject: Re: [Json] Proposal: the minimal edit X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 25 Jun 2013 01:30:02 -0000 Paul Hoffman scripsit: > I'm not sure what you mean by "exclude". The sentence Tim was referring > to is about inclusion: > > - ECMAScript implementations can generate and consume code points > in JSON strings that are not Unicode characters. There is no point in putting this item into a list of differences unless it is not true of RFC-JSON. If this language is to be added, it follows that RFC-JSON excludes certain code points that are not Unicode characters. But exactly which code points? As worded, presumably all of them: the surrogate code points, the non-character code points (a term of art in Unicode; it does not mean "code points that are not characters", but refers to a specific list of 66 code points), and the unassigned (as of some particular Unicode version) code points. Tim's proposed revision replaced the last five words with "that can never be Unicode characters", thus excluding from RFC-JSON only the surrogate code points and the non-character code points, but not the unassigned code points. As it turns out, this is indeed what he meant to say. My preference would be to exclude only the surrogates, not the non-characters, which is yet a third position. My suggested wording would be simply "that are surrogates". (Strictly speaking, code points are not characters; code points *represent* characters. This editorial point is orthogonal to the current discussion.) -- He made the Legislature meet at one-horse John Cowan tank-towns out in the alfalfa belt, so that cowan@ccil.org hardly nobody could get there and most of http://www.ccil.org/~cowan the leaders would stay home and let him go --H.L. Mencken's to work and do things as he pleased. Declaration of Independence From ietf@lindenbergsoftware.com Mon Jun 24 18:35:40 2013 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 3A4EC11E80E1 for ; Mon, 24 Jun 2013 18:35:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.676 X-Spam-Level: X-Spam-Status: No, score=-3.676 tagged_above=-999 required=5 tests=[AWL=-0.077, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j1+wkbeYMNMe for ; Mon, 24 Jun 2013 18:35:34 -0700 (PDT) Received: from mirach.lunarpages.com (mirach.lunarpages.com [216.97.235.70]) by ietfa.amsl.com (Postfix) with ESMTP id B983111E80F9 for ; Mon, 24 Jun 2013 18:35:31 -0700 (PDT) Received: from 50-0-136-241.dsl.dynamic.sonic.net ([50.0.136.241]:55309 helo=[192.168.0.5]) by mirach.lunarpages.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1UrIAL-0027oX-J2; Mon, 24 Jun 2013 18:35:29 -0700 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=windows-1252 From: Norbert Lindenberg In-Reply-To: <6B5B32EF-E4EA-461A-8C73-262375703A04@vpnc.org> Date: Mon, 24 Jun 2013 18:35:24 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130624233521.GF19899@mercury.ccil.org> <3D442E5F-F9ED-47DB-9E1D-29ACA8588717@vpnc.org> <3BBF18FB-63DE-40DE-93B4-1F8343386872@lindenbergsoftware.com> <6B5B32EF-E4EA-461A-8C73-262375703A04@vpnc.org> To: Paul Hoffman X-Mailer: Apple Mail (2.1283) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - mirach.lunarpages.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - lindenbergsoftware.com X-Get-Message-Sender-Via: mirach.lunarpages.com: authenticated_id: ietf@lindenbergsoftware.com Cc: Norbert Lindenberg , "json@ietf.org WG" Subject: Re: [Json] Proposal: the minimal edit X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 25 Jun 2013 01:35:40 -0000 On Jun 24, 2013, at 17:28 , Paul Hoffman wrote: >>> - ECMAScript implementations can generate and consume code points in = JSON strings that are not >>> Unicode characters. >>=20 >> Which definition of "Unicode character" are the three of you = referring to? >=20 > Does it actually matter? This thread is about making minimal changes = to the current spec. The current spec says "Unicode characters". The = proposed addition to the spec indicates that, for some definition of = "Unicode character" that is not in RFC 4627, ECMAScript can have strings = with more than just Unicode characters. >=20 > Do you believe that proposed sentence is incorrect? Without a definition of "Unicode character" we can't determine whether = the sentence is correct or not. On the other hand, all code points that an ECMAScript implementation can = generate and consume are allowed by the JSON grammar, so by that measure = there's no difference between the two specifications. I think what Tim and others really want to say is "JSON over the wire = must not use surrogate code points", with Tim adding "... or = non-character code points". =46rom that would follow that "ECMAScript = implementations can generate and consume code points in JSON strings = that must not be used in JSON over the wire". And I think that's the = kind of information that actually matters from an interoperability point = of view. It's not a minimal edit though. Norbert= From ietf@lindenbergsoftware.com Mon Jun 24 18:38:41 2013 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 0A69B11E817F for ; Mon, 24 Jun 2013 18:38:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.673 X-Spam-Level: X-Spam-Status: No, score=-3.673 tagged_above=-999 required=5 tests=[AWL=-0.074, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ysRLqHVbNm1O for ; Mon, 24 Jun 2013 18:38:36 -0700 (PDT) Received: from mirach.lunarpages.com (mirach.lunarpages.com [216.97.235.70]) by ietfa.amsl.com (Postfix) with ESMTP id 285A811E80E4 for ; Mon, 24 Jun 2013 18:38:36 -0700 (PDT) Received: from 50-0-136-241.dsl.dynamic.sonic.net ([50.0.136.241]:55358 helo=[192.168.0.5]) by mirach.lunarpages.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1UrIDJ-0028By-T9; Mon, 24 Jun 2013 18:38:33 -0700 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Norbert Lindenberg In-Reply-To: Date: Mon, 24 Jun 2013 18:38:29 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <991E82C3-888C-46AC-9E52-2F3892DDDC4F@lindenbergsoftware.com> References: To: Paul Hoffman X-Mailer: Apple Mail (2.1283) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - mirach.lunarpages.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - lindenbergsoftware.com X-Get-Message-Sender-Via: mirach.lunarpages.com: authenticated_id: ietf@lindenbergsoftware.com Cc: Norbert Lindenberg , "json@ietf.org WG" , R S Subject: Re: [Json] Proposal: the minimal edit X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 25 Jun 2013 01:38:41 -0000 On Jun 24, 2013, at 14:28 , Paul Hoffman wrote: > The following lists the known major differences between this = document and the definition of JSON > in Section 15.12 of [ECMA]. The JSON section didn't exist before the 5th edition of ECMA-262, and = its number might change in the 6th or a later edition, so it would be = better to refer to "section 15.12 of edition 5.1, or successor". > [ECMA] European Computer Manufacturers Association, "ECMAScript > Language Specification", > ecma-st/ECMA-262.pdf>. The former ECMA changed its name to "Ecma International" in 1994. Norbert From paul.hoffman@vpnc.org Mon Jun 24 19:11:54 2013 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 74EA221F9A3C for ; Mon, 24 Jun 2013 19:11:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.515 X-Spam-Level: X-Spam-Status: No, score=-102.515 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o60gt7d2v1Nj for ; Mon, 24 Jun 2013 19:11:54 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id E4F5921F9A16 for ; Mon, 24 Jun 2013 19:11:53 -0700 (PDT) Received: from [10.20.30.90] (50-0-66-165.dsl.dynamic.sonic.net [50.0.66.165]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r5P2Bqhd096436 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 24 Jun 2013 19:11:53 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Paul Hoffman In-Reply-To: <20130625011904.GJ19899@mercury.ccil.org> Date: Mon, 24 Jun 2013 19:11:52 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <5FF84B9F-F637-48AC-921F-173F3370EF17@vpnc.org> References: <20130624233521.GF19899@mercury.ccil.org> <3D442E5F-F9ED-47DB-9E1D-29ACA8588717@vpnc.org> <20130625011904.GJ19899@mercury.ccil.org> To: John Cowan X-Mailer: Apple Mail (2.1508) Cc: "json@ietf.org WG" Subject: Re: [Json] Proposal: the minimal edit X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 25 Jun 2013 02:11:54 -0000 On Jun 24, 2013, at 6:19 PM, John Cowan wrote: > Paul Hoffman scripsit: >=20 >> I'm not sure what you mean by "exclude". The sentence Tim was = referring >> to is about inclusion: >>=20 >> - ECMAScript implementations can generate and consume code points >> in JSON strings that are not Unicode characters. >=20 > There is no point in putting this item into a list of differences > unless it is not true of RFC-JSON. Agree. > If this language is to be added, it > follows that RFC-JSON excludes certain code points that are not = Unicode > characters. =20 There are many people in the WG who believe that is the case. > But exactly which code points? =20 Why is that question important? As long as there is a difference, why = does there have to be a specific list for this purpose? > As worded, presumably > all of them: the surrogate code points, the non-character code points > (a term of art in Unicode; it does not mean "code points that are not > characters", but refers to a specific list of 66 code points), and the > unassigned (as of some particular Unicode version) code points. Errr, why make that presumption? The sentence stands on its own, without = presumptions. Rob's suggestion to make this all simple is the basis for = this thread. > Tim's proposed revision replaced the last five words with "that can = never > be Unicode characters", thus excluding from RFC-JSON only the = surrogate > code points and the non-character code points, but not the unassigned > code points. As it turns out, this is indeed what he meant to say. The sentence above is more general. If it is still true, I thought it = would probably be supported by more people who wanted simplicity in the = -bis document. > My preference would be to exclude only the surrogates, not the > non-characters, which is yet a third position. My suggested wording > would be simply "that are surrogates". Why are you wanting to exclude anything? This section is a list of = differences. Do you believe you know exactly which non-characters are = allowed by ECMAScript? I ask because there were differing opinions = earlier. --Paul Hoffman= From sayrer@gmail.com Mon Jun 24 19:13:07 2013 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 41D3121E8050 for ; Mon, 24 Jun 2013 19:13:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.528 X-Spam-Level: X-Spam-Status: No, score=-2.528 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3uRyCdSlHA-n for ; Mon, 24 Jun 2013 19:13:05 -0700 (PDT) Received: from mail-wg0-x22b.google.com (mail-wg0-x22b.google.com [IPv6:2a00:1450:400c:c00::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 23CB321E804C for ; Mon, 24 Jun 2013 19:13:04 -0700 (PDT) Received: by mail-wg0-f43.google.com with SMTP id z11so8871290wgg.10 for ; Mon, 24 Jun 2013 19:13:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=aVz2ozgIWkIjjw0qt4GRG+TtoathvFkTj+Gmfch7CLE=; b=XR6fjG9ZzaUvS2JmSK4+hWnPyQLnyHhtJIKjYY6WSyhcWO+Ohbpz75WY5d19932QY8 +P2t+xla7r4MHS11iyvTuqNGXfz9rDfydXM2E1NTSvda/czrIFvawyi1MvY4cX8znhSI 2USPu2wBlVYle0RefscVO0LmdIAXFDMr++2zFVjMgt5YJ8dIUNUhC/6QN7bFcFwftBHE YuPgPq5kye1oXECo2kItht0uBZeaUyRuGD4zdJGemxZqT7d/Ey/Oz9lov4g5P9QKVn4T 0SObtulyq0g8TFuB02iFWATOSrN8aGZ7LOMoZBXytzwXsM7g49/xQou1pWDgG3qxjgGl OMww== MIME-Version: 1.0 X-Received: by 10.180.206.77 with SMTP id lm13mr7599319wic.18.1372126383880; Mon, 24 Jun 2013 19:13:03 -0700 (PDT) Received: by 10.194.44.138 with HTTP; Mon, 24 Jun 2013 19:13:03 -0700 (PDT) Received: by 10.194.44.138 with HTTP; Mon, 24 Jun 2013 19:13:03 -0700 (PDT) In-Reply-To: References: Date: Mon, 24 Jun 2013 19:13:03 -0700 Message-ID: From: R S To: Paul Hoffman Content-Type: multipart/alternative; boundary=001a11c380aeb2c1d804dff1119f Cc: "json@ietf.org WG" Subject: Re: [Json] Proposal: the minimal edit X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 25 Jun 2013 02:13:07 -0000 --001a11c380aeb2c1d804dff1119f Content-Type: text/plain; charset=ISO-8859-1 This looks good to me. It can serve as a baseline for further proposals at the very least. - Rob On Jun 24, 2013 2:28 PM, "Paul Hoffman" wrote: > > > A few people on this thread have said they might support Rob's idea if > they knew all the changes, and a few changes were thrown back and forth. I > propose the following is a full set of what is needed. Please note the > wording at the beginning of the proposed Section 1.3: this is about what > ECMAScript actually says about JSON, not what that means to ECMAScript > implementations. > > Thoughts? > > --Paul Hoffman > > Add Section 1.2, "Changes from RFC 4627" > > This section lists all changes between this document and the text in > RFC 4627. > > - Applied errata #607 from RFC 4627 to correctly align the artwork > for the definition of "object". > > - Applied errata #3607 from RFC 4627 by removing the security > consideration that begins "A JSON text can be safely passed" > and the JavaScript code that went with that consideration. > > - Added Section 1.3, "Differences from the JSON Definition in > ECMAScript". > > - Changed the [ECMA] and [UNICODE] references to be > non-version-specific. > > Add Section 1.3, "Differences from the JSON Definition in ECMAScript" > > The following lists the known major differences between this document > and the definition of JSON > in Section 15.12 of [ECMA]. > > - ECMAScript implementations produce and consume primitive JSON values > at the root level of JSON > documents. > > - ECMAScript implementations can generate and consume code points in > JSON strings that are not > Unicode characters. > > - When there are duplicate names within an object, ECMAScript JSON > parsers overwrite the value > corresponding to such names with the value that appears last in the > serialization. > > In Section 6, remove "A JSON text can be safely passed" and the JavaScript > code in the following > paragraph. > > In Section 9, change the title in the reference to [ECMA] to be be > non-version-specific: > > [ECMA] European Computer Manufacturers Association, "ECMAScript > Language Specification", > ecma-st/ECMA-262.pdf>. > > In Section 9, change the reference to [UNICODE] to be be > non-version-specific: > > [UNICODE] The Unicode Consortium, "The Unicode Standard", > . > > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > --001a11c380aeb2c1d804dff1119f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

This looks good to me. It can serve as a baseline for furthe= r proposals at the very least.

- Rob

On Jun 24, 2013 2:28 PM, "Paul Hoffman"= ; <paul.hoffman@vpnc.org>= ; wrote:
<no hat>

A few people on this thread have said they might support Rob's idea if = they knew all the changes, and a few changes were thrown back and forth. I = propose the following is a full set of what is needed. Please note the word= ing at the beginning of the proposed Section 1.3: this is about what ECMASc= ript actually says about JSON, not what that means to ECMAScript implementa= tions.

Thoughts?

--Paul Hoffman

Add Section 1.2, "Changes from RFC 4627"

=A0 =A0This section lists all changes between this document and the text in=
=A0 =A0RFC 4627.

=A0 =A0- Applied errata #607 from RFC 4627 to correctly align the artwork =A0 =A0 =A0for the definition of "object".

=A0 =A0- Applied errata #3607 from RFC 4627 by removing the security
=A0 =A0 =A0consideration that begins "A JSON text can be safely passed= "
=A0 =A0 =A0and the JavaScript code that went with that consideration.

=A0 =A0- Added Section 1.3, "Differences from the JSON Definition in E= CMAScript".

=A0 =A0- Changed the [ECMA] and [UNICODE] references to be non-version-spec= ific.

Add Section 1.3, "Differences from the JSON Definition in ECMAScript&q= uot;

=A0 =A0The following lists the known major differences between this documen= t and the definition of JSON
=A0 =A0in Section 15.12 of [ECMA].

=A0 =A0- ECMAScript implementations produce and consume primitive JSON valu= es at the root level of JSON
=A0 =A0 =A0documents.

=A0 =A0- ECMAScript implementations can generate and consume code points in= JSON strings that are not
=A0 =A0 =A0Unicode characters.

=A0 =A0- When there are duplicate names within an object, ECMAScript JSON p= arsers overwrite the value
=A0 =A0 =A0corresponding to such names with the value that appears last in = the serialization.

In Section 6, remove "A JSON text can be safely passed" and the J= avaScript code in the following
paragraph.

In Section 9, change the title in the reference to [ECMA] to be be non-vers= ion-specific:

=A0 =A0[ECMA] =A0 =A0European Computer Manufacturers Association, "ECM= AScript
=A0 =A0 =A0 =A0 =A0 =A0 =A0Language Specification",
=A0 =A0 =A0 =A0 =A0 =A0 =A0<http://www.ecma-international.org/p= ublications/files/
=A0 =A0 =A0 =A0 =A0 =A0 =A0ecma-st/ECMA-262.pdf>.

In Section 9, change the reference to [UNICODE] to be be non-version-specif= ic:

=A0 =A0[UNICODE] =A0The Unicode Consortium, "The Unicode Standard"= ;,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 <http://www.unicode.org/versions/latest/>.=


_______________________________________________
json mailing list
json@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/json
--001a11c380aeb2c1d804dff1119f-- From paul.hoffman@vpnc.org Mon Jun 24 19:14:57 2013 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 B8CBD21E8050 for ; Mon, 24 Jun 2013 19:14:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.516 X-Spam-Level: X-Spam-Status: No, score=-102.516 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZCEkXqtYkHgY for ; Mon, 24 Jun 2013 19:14:57 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 37CDC21E804C for ; Mon, 24 Jun 2013 19:14:57 -0700 (PDT) Received: from [10.20.30.90] (50-0-66-165.dsl.dynamic.sonic.net [50.0.66.165]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r5P2EucP096552 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 24 Jun 2013 19:14:56 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Paul Hoffman In-Reply-To: Date: Mon, 24 Jun 2013 19:14:55 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130624233521.GF19899@mercury.ccil.org> <3D442E5F-F9ED-47DB-9E1D-29ACA8588717@vpnc.org> <3BBF18FB-63DE-40DE-93B4-1F8343386872@lindenbergsoftware.com> <6B5B32EF-E4EA-461A-8C73-262375703A04@vpnc.org> To: Norbert Lindenberg X-Mailer: Apple Mail (2.1508) Cc: "json@ietf.org WG" Subject: Re: [Json] Proposal: the minimal edit X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 25 Jun 2013 02:14:57 -0000 On Jun 24, 2013, at 6:35 PM, Norbert Lindenberg = wrote: >=20 > On Jun 24, 2013, at 17:28 , Paul Hoffman wrote: >=20 >>>> - ECMAScript implementations can generate and consume code points = in JSON strings that are not >>>> Unicode characters. >>>=20 >>> Which definition of "Unicode character" are the three of you = referring to? >>=20 >> Does it actually matter? This thread is about making minimal changes = to the current spec. The current spec says "Unicode characters". The = proposed addition to the spec indicates that, for some definition of = "Unicode character" that is not in RFC 4627, ECMAScript can have strings = with more than just Unicode characters. >>=20 >> Do you believe that proposed sentence is incorrect? >=20 > Without a definition of "Unicode character" we can't determine whether = the sentence is correct or not. I believe you can. If you look at the mailing list, you will see that = some people interpret ECMAScript as allowing every code point in = strings. There are some code points that do not represent Unicode = characters. Isn't that sufficient? > On the other hand, all code points that an ECMAScript implementation = can generate and consume are allowed by the JSON grammar, so by that = measure there's no difference between the two specifications. There is wide disagreement on that statement in the WG so far. > I think what Tim and others really want to say is "JSON over the wire = must not use surrogate code points", with Tim adding "... or = non-character code points". =46rom that would follow that "ECMAScript = implementations can generate and consume code points in JSON strings = that must not be used in JSON over the wire". And I think that's the = kind of information that actually matters from an interoperability point = of view. It's not a minimal edit though. Exactly right. The attempt in this thread is *not* to list = interoperability points, just cleanup. --Paul Hoffman= From paul.hoffman@vpnc.org Mon Jun 24 19:19:23 2013 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 2618421E804C for ; Mon, 24 Jun 2013 19:19:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.517 X-Spam-Level: X-Spam-Status: No, score=-102.517 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OP4rGi5qA6rJ for ; Mon, 24 Jun 2013 19:19:22 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id BAD6711E80F1 for ; Mon, 24 Jun 2013 19:19:22 -0700 (PDT) Received: from [10.20.30.90] (50-0-66-165.dsl.dynamic.sonic.net [50.0.66.165]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r5P2JK3d096697 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 24 Jun 2013 19:19:21 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Paul Hoffman In-Reply-To: <5FF84B9F-F637-48AC-921F-173F3370EF17@vpnc.org> Date: Mon, 24 Jun 2013 19:19:20 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <6DE2EFD8-4FE4-410E-AB0C-B0B34F313FEB@vpnc.org> References: <20130624233521.GF19899@mercury.ccil.org> <3D442E5F-F9ED-47DB-9E1D-29ACA8588717@vpnc.org> <20130625011904.GJ19899@mercury.ccil.org> <5FF84B9F-F637-48AC-921F-173F3370EF17@vpnc.org> To: "json@ietf.org WG" X-Mailer: Apple Mail (2.1508) Subject: Re: [Json] Proposal: the minimal edit X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 25 Jun 2013 02:19:23 -0000 Asked a different way: Given a section titled "Differences from the JSON Definition in = ECMAScript" that begins "The following lists the known major differences = between this document and the definition of JSON in Section 15.12 of = [ECMA]", what would you say about the perceived difference in the code = points that ECMAScript implementations can generate and consume relative = to RFC 4627? --Paul Hoffman= From cowan@ccil.org Mon Jun 24 19:33:21 2013 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 3179511E80F8 for ; Mon, 24 Jun 2013 19:33:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.475 X-Spam-Level: X-Spam-Status: No, score=-3.475 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n0IoU8EgoNhc for ; Mon, 24 Jun 2013 19:33:16 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id AB5D311E80F1 for ; Mon, 24 Jun 2013 19:33:16 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1UrJ4E-0007Ti-VP; Mon, 24 Jun 2013 22:33:15 -0400 Date: Mon, 24 Jun 2013 22:33:14 -0400 From: John Cowan To: Paul Hoffman Message-ID: <20130625023314.GD14060@mercury.ccil.org> References: <20130624233521.GF19899@mercury.ccil.org> <3D442E5F-F9ED-47DB-9E1D-29ACA8588717@vpnc.org> <20130625011904.GJ19899@mercury.ccil.org> <5FF84B9F-F637-48AC-921F-173F3370EF17@vpnc.org> <6DE2EFD8-4FE4-410E-AB0C-B0B34F313FEB@vpnc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6DE2EFD8-4FE4-410E-AB0C-B0B34F313FEB@vpnc.org> User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Cc: "json@ietf.org WG" Subject: Re: [Json] Proposal: the minimal edit X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 25 Jun 2013 02:33:21 -0000 Paul Hoffman scripsit: > Given a section titled "Differences from the JSON Definition in > ECMAScript" that begins "The following lists the known major differences > between this document and the definition of JSON in Section 15.12 of > [ECMA]", what would you say about the perceived difference in the > code points that ECMAScript implementations can generate and consume > relative to RFC 4627? Actually, I wouldn't say anything at this stage, now that I think about it. The time to write a list giving the differences between ECMA-JSON and RFC-JSON is after we know what it is that RFC-JSON says. Right now we don't. -- John Cowan cowan@ccil.org http://www.ccil.org/~cowan Thor Heyerdahl recounts his attempt to prove Rudyard Kipling's theory that the mongoose first came to India on a raft from Polynesia. --blurb for Rikki-Kon-Tiki-Tavi From paul.hoffman@vpnc.org Mon Jun 24 19:43:35 2013 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 AD05111E80FA for ; Mon, 24 Jun 2013 19:43:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.518 X-Spam-Level: X-Spam-Status: No, score=-102.518 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ja76uM3PCNfO for ; Mon, 24 Jun 2013 19:43:34 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 9A4C321E805D for ; Mon, 24 Jun 2013 19:43:32 -0700 (PDT) Received: from [10.20.30.90] (50-0-66-165.dsl.dynamic.sonic.net [50.0.66.165]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r5P2hU8N097334 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 24 Jun 2013 19:43:30 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Paul Hoffman In-Reply-To: <20130625023314.GD14060@mercury.ccil.org> Date: Mon, 24 Jun 2013 19:43:29 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130624233521.GF19899@mercury.ccil.org> <3D442E5F-F9ED-47DB-9E1D-29ACA8588717@vpnc.org> <20130625011904.GJ19899@mercury.ccil.org> <5FF84B9F-F637-48AC-921F-173F3370EF17@vpnc.org> <6DE2EFD8-4FE4-410E-AB0C-B0B34F313FEB@vpnc.org> <20130625023314.GD14060@mercury.ccil.org> To: John Cowan X-Mailer: Apple Mail (2.1508) Cc: "json@ietf.org WG" Subject: Re: [Json] Proposal: the minimal edit X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 25 Jun 2013 02:43:35 -0000 On Jun 24, 2013, at 7:33 PM, John Cowan wrote: > Paul Hoffman scripsit: >=20 >> Given a section titled "Differences from the JSON Definition in >> ECMAScript" that begins "The following lists the known major = differences >> between this document and the definition of JSON in Section 15.12 of >> [ECMA]", what would you say about the perceived difference in the >> code points that ECMAScript implementations can generate and consume >> relative to RFC 4627? >=20 > Actually, I wouldn't say anything at this stage, now that I think > about it. The time to write a list giving the differences between > ECMA-JSON and RFC-JSON is after we know what it is that RFC-JSON says. > Right now we don't. I apologize if I didn't make it clear, but the proposal that I made = earlier says *exactly* what is in what you call RFC-JSON. It is the = current draft, with only the changes that I listed. This is what Robert = proposed at the beginning of this thread. --Paul Hoffman= From cowan@ccil.org Mon Jun 24 19:43:39 2013 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 1F58321E808B for ; Mon, 24 Jun 2013 19:43:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.477 X-Spam-Level: X-Spam-Status: No, score=-3.477 tagged_above=-999 required=5 tests=[AWL=0.122, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q563FcBL2lYF for ; Mon, 24 Jun 2013 19:43:34 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id BA39D21E8050 for ; Mon, 24 Jun 2013 19:43:26 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1UrJE4-0008Se-1S; Mon, 24 Jun 2013 22:43:24 -0400 Date: Mon, 24 Jun 2013 22:43:24 -0400 From: John Cowan To: Paul Hoffman Message-ID: <20130625024323.GE14060@mercury.ccil.org> References: <20130624233521.GF19899@mercury.ccil.org> <3D442E5F-F9ED-47DB-9E1D-29ACA8588717@vpnc.org> <3BBF18FB-63DE-40DE-93B4-1F8343386872@lindenbergsoftware.com> <6B5B32EF-E4EA-461A-8C73-262375703A04@vpnc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Cc: Norbert Lindenberg , "json@ietf.org WG" Subject: Re: [Json] Proposal: the minimal edit X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 25 Jun 2013 02:43:39 -0000 Paul Hoffman scripsit: > > On the other hand, all code points that an ECMAScript implementation > > can generate and consume are allowed by the JSON grammar, so by that > > measure there's no difference between the two specifications. > > There is wide disagreement on that statement in the WG so far. I have seen no disagreement about the truth of it, but much about the desirability of it. -- John Cowan cowan@ccil.org http://ccil.org/~cowan The present impossibility of giving a scientific explanation is no proof that there is no scientific explanation. The unexplained is not to be identified with the unexplainable, and the strange and extraordinary nature of a fact is not a justification for attributing it to powers above nature. --The Catholic Encyclopedia, s.v. "telepathy" (1913) From tbray@textuality.com Mon Jun 24 19:46:15 2013 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 9098821E8087 for ; Mon, 24 Jun 2013 19:46:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.74 X-Spam-Level: X-Spam-Status: No, score=0.74 tagged_above=-999 required=5 tests=[AWL=-0.617, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4COpRaVC6OTy for ; Mon, 24 Jun 2013 19:46:11 -0700 (PDT) Received: from mail-vb0-x235.google.com (mail-vb0-x235.google.com [IPv6:2607:f8b0:400c:c02::235]) by ietfa.amsl.com (Postfix) with ESMTP id 79E5E21E8050 for ; Mon, 24 Jun 2013 19:46:11 -0700 (PDT) Received: by mail-vb0-f53.google.com with SMTP id p12so8797717vbe.40 for ; Mon, 24 Jun 2013 19:46:11 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=70N4rdMGXeLrCSphApd7ORrl2ie3TccfHbhJF1EgWAo=; b=gIN7Wp3UAzPykjCmjMUvIXh1PyiAVlQZW3TEU5bhjibmFTbwnxkXfC3CyVxtBzI6kD mx5APLVOk7+Zo2qDwZ05//mcDqOdoVGI9EkNMQVjWDexVMyv8JSBkXUhgJAnyB4zlN7e iXf+YKZzZvVd+Ga3mCafqX24EswNKWHKQeJB5m0cpZcuUaIHSTz8/h6jgrnDFa7uNAyY /yKguWj9EU/+2gXzrh+sGsgCUVLfkxZIPx2LcTsKd3VJrS0zRUNVky3WXOLyPaGgXiEX yxOfDK8sf7XChvqkLwE7dEhmB/eB5pEQUYFd08IzhNxWeIqvuKbunm+WzL2Y5SPxSNyw 4X9g== MIME-Version: 1.0 X-Received: by 10.52.236.199 with SMTP id uw7mr11260273vdc.18.1372128369904; Mon, 24 Jun 2013 19:46:09 -0700 (PDT) Received: by 10.220.219.200 with HTTP; Mon, 24 Jun 2013 19:46:09 -0700 (PDT) X-Originating-IP: [24.84.235.32] In-Reply-To: <20130625023314.GD14060@mercury.ccil.org> References: <20130624233521.GF19899@mercury.ccil.org> <3D442E5F-F9ED-47DB-9E1D-29ACA8588717@vpnc.org> <20130625011904.GJ19899@mercury.ccil.org> <5FF84B9F-F637-48AC-921F-173F3370EF17@vpnc.org> <6DE2EFD8-4FE4-410E-AB0C-B0B34F313FEB@vpnc.org> <20130625023314.GD14060@mercury.ccil.org> Date: Mon, 24 Jun 2013 19:46:09 -0700 Message-ID: From: Tim Bray To: John Cowan Content-Type: multipart/alternative; boundary=089e0111d924132a8204dff188fb X-Gm-Message-State: ALoCoQkGLjrw88Akle5aywF/vIRziatoWhhn+/sPiz9S1Ec717lN86WcnTV/sH8Chdjj4VzqN5da Cc: Paul Hoffman , "json@ietf.org WG" Subject: Re: [Json] Proposal: the minimal edit X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 25 Jun 2013 02:46:15 -0000 --089e0111d924132a8204dff188fb Content-Type: text/plain; charset=UTF-8 No, John, Paul provided a completely worked through proposal encompassing a small but nonzero set of changes, the largest being the vs-ECMA section. -T On Mon, Jun 24, 2013 at 7:33 PM, John Cowan wrote: > Paul Hoffman scripsit: > > > Given a section titled "Differences from the JSON Definition in > > ECMAScript" that begins "The following lists the known major differences > > between this document and the definition of JSON in Section 15.12 of > > [ECMA]", what would you say about the perceived difference in the > > code points that ECMAScript implementations can generate and consume > > relative to RFC 4627? > > Actually, I wouldn't say anything at this stage, now that I think > about it. The time to write a list giving the differences between > ECMA-JSON and RFC-JSON is after we know what it is that RFC-JSON says. > Right now we don't. > > -- > John Cowan cowan@ccil.org http://www.ccil.org/~cowan > Thor Heyerdahl recounts his attempt to prove Rudyard Kipling's theory > that the mongoose first came to India on a raft from Polynesia. > --blurb for Rikki-Kon-Tiki-Tavi > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > --089e0111d924132a8204dff188fb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
No, John, Paul provided a completely worked through propos= al encompassing a small but nonzero set of changes, the largest being the v= s-ECMA section. -T


On Mon, Jun 24, 2013 at 7:33 PM, John Cowan <cowan@mercury.ccil.org= > wrote:
Paul Hoffman scripsit:

> Given a section titled "Differences from the JSON Definition in > ECMAScript" that begins "The following lists the known major= differences
> between this document and the definition of JSON in Section 15.12 of > [ECMA]", what would you say about the perceived difference in the=
> code points that ECMAScript implementations can generate and consume > relative to RFC 4627?

Actually, I wouldn't say anything at this stage, now that I think=
about it. =C2=A0The time to write a list giving the differences between
ECMA-JSON and RFC-JSON is after we know what it is that RFC-JSON says.
Right now we don't.

--
John Cowan =C2=A0cowan@ccil.org =C2= =A0http://www.ccil= .org/~cowan
Thor Heyerdahl recounts his attempt to prove Rudyard Kipling's th= eory
that the mongoose first came to India on a raft from Polynesia.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 --blurb for Rikki-Kon-Tiki-Tavi
___________________________________= ____________
json mailing list
json@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/json

--089e0111d924132a8204dff188fb-- From ietf@lindenbergsoftware.com Mon Jun 24 20:12:14 2013 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 EC2EB11E8105 for ; Mon, 24 Jun 2013 20:12:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.67 X-Spam-Level: X-Spam-Status: No, score=-3.67 tagged_above=-999 required=5 tests=[AWL=-0.071, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cdCsVeIe--6i for ; Mon, 24 Jun 2013 20:12:09 -0700 (PDT) Received: from mirach.lunarpages.com (mirach.lunarpages.com [216.97.235.70]) by ietfa.amsl.com (Postfix) with ESMTP id 25C3821F91A5 for ; Mon, 24 Jun 2013 20:12:09 -0700 (PDT) Received: from 50-0-136-241.dsl.dynamic.sonic.net ([50.0.136.241]:55760 helo=[192.168.0.5]) by mirach.lunarpages.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1UrJfs-002JmA-4T; Mon, 24 Jun 2013 20:12:08 -0700 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Norbert Lindenberg In-Reply-To: Date: Mon, 24 Jun 2013 20:12:03 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <09DF5600-BB4B-49F3-B6A9-35F04B77B131@lindenbergsoftware.com> References: <20130624233521.GF19899@mercury.ccil.org> <3D442E5F-F9ED-47DB-9E1D-29ACA8588717@vpnc.org> <3BBF18FB-63DE-40DE-93B4-1F8343386872@lindenbergsoftware.com> <6B5B32EF-E4EA-461A-8C73-262375703A04@vpnc.org> To: Paul Hoffman X-Mailer: Apple Mail (2.1283) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - mirach.lunarpages.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - lindenbergsoftware.com X-Get-Message-Sender-Via: mirach.lunarpages.com: authenticated_id: ietf@lindenbergsoftware.com Cc: Norbert Lindenberg , "json@ietf.org WG" Subject: Re: [Json] Proposal: the minimal edit X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 25 Jun 2013 03:12:15 -0000 On Jun 24, 2013, at 19:14 , Paul Hoffman wrote: > >=20 > On Jun 24, 2013, at 6:35 PM, Norbert Lindenberg = wrote: >=20 >>=20 >> On Jun 24, 2013, at 17:28 , Paul Hoffman wrote: >>=20 >>>>> - ECMAScript implementations can generate and consume code points = in JSON strings that are not >>>>> Unicode characters. >>>>=20 >>>> Which definition of "Unicode character" are the three of you = referring to? >>>=20 >>> Does it actually matter? This thread is about making minimal changes = to the current spec. The current spec says "Unicode characters". The = proposed addition to the spec indicates that, for some definition of = "Unicode character" that is not in RFC 4627, ECMAScript can have strings = with more than just Unicode characters. >>>=20 >>> Do you believe that proposed sentence is incorrect? >>=20 >> Without a definition of "Unicode character" we can't determine = whether the sentence is correct or not. >=20 > I believe you can. If you look at the mailing list, you will see that = some people interpret ECMAScript as allowing every code point in = strings. I'm one of these people. > There are some code points that do not represent Unicode characters. Absent an agreed-upon definition of "Unicode character", I can simply = define the term to be a synonym of "code point", which renders the = sentence incorrect. Code point, assigned code point, reserved code point, surrogate code = point, and noncharacter code point are terms that the Unicode standard = defines and that should be used in the RFC. Norbert= From sayrer@gmail.com Mon Jun 24 20:15:25 2013 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 14BCB21F9D07 for ; Mon, 24 Jun 2013 20:15:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.532 X-Spam-Level: X-Spam-Status: No, score=-2.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id haQZ-J4581Av for ; Mon, 24 Jun 2013 20:15:24 -0700 (PDT) Received: from mail-wg0-x22e.google.com (mail-wg0-x22e.google.com [IPv6:2a00:1450:400c:c00::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 4E03621F9CEC for ; Mon, 24 Jun 2013 20:15:24 -0700 (PDT) Received: by mail-wg0-f46.google.com with SMTP id c11so8827443wgh.25 for ; Mon, 24 Jun 2013 20:15:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Ey5+lwSSe/uvT93teob9qvHJRdfkupAG+kDZZv2LfCE=; b=L90CChrjhc77QTq8/9XRfsiJlreKgyy6cwGvNkgTbeQ7EQBdsO2uwXgI1xQ35qP8OB hea5bJlHZKlJZY8DrHyrln8swfF3hzHFH29hlxpHaMV7tOPTUdI11n1CI3CJeYuCY5oC dZ2Mz0VVKFOzfxjgqe2KT06We3RXDKjCg0+/b407c60+DhvISGXuVWXoHN92kJuJrEg5 3g9bo+EXjy26mV7sV+1qaJZV8Sa+9bnTo909fH7o9RWTlAJMghtXxmuNdxNdyAaO4b9N KNqRUoGsuvjmtOfJtbZwaeMjzmvZWNF5KYVFUGfkxyTiYQD3C976NlaYdjps0v3zuEyW Qr7g== MIME-Version: 1.0 X-Received: by 10.194.58.239 with SMTP id u15mr18471897wjq.87.1372130122254; Mon, 24 Jun 2013 20:15:22 -0700 (PDT) Received: by 10.194.44.138 with HTTP; Mon, 24 Jun 2013 20:15:22 -0700 (PDT) In-Reply-To: <09DF5600-BB4B-49F3-B6A9-35F04B77B131@lindenbergsoftware.com> References: <20130624233521.GF19899@mercury.ccil.org> <3D442E5F-F9ED-47DB-9E1D-29ACA8588717@vpnc.org> <3BBF18FB-63DE-40DE-93B4-1F8343386872@lindenbergsoftware.com> <6B5B32EF-E4EA-461A-8C73-262375703A04@vpnc.org> <09DF5600-BB4B-49F3-B6A9-35F04B77B131@lindenbergsoftware.com> Date: Mon, 24 Jun 2013 20:15:22 -0700 Message-ID: From: R S To: Norbert Lindenberg Content-Type: multipart/alternative; boundary=047d7ba97b9485d04704dff1f07d Cc: Paul Hoffman , "json@ietf.org WG" Subject: Re: [Json] Proposal: the minimal edit X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 25 Jun 2013 03:15:25 -0000 --047d7ba97b9485d04704dff1f07d Content-Type: text/plain; charset=ISO-8859-1 On Mon, Jun 24, 2013 at 8:12 PM, Norbert Lindenberg < ietf@lindenbergsoftware.com> wrote: > > Code point, assigned code point, reserved code point, surrogate code > point, and noncharacter code point are terms that the Unicode standard > defines and that should be used in the RFC. > That sounds like a possible follow-on proposal. The group is chartered to reclassify RFC 4627 in place, and the existing Unicode terminology just isn't a deal breaker. If it were, JSON interoperability would be much worse. - Rob --047d7ba97b9485d04704dff1f07d Content-Type: text/html; charset=ISO-8859-1
On Mon, Jun 24, 2013 at 8:12 PM, Norbert Lindenberg <ietf@lindenbergsoftware.com> wrote:

Code point, assigned code point, reserved code point, surrogate code point, and noncharacter code point are terms that the Unicode standard defines and that should be used in the RFC.

That sounds like a possible follow-on proposal. The group is chartered to reclassify RFC 4627 in place, and the existing Unicode terminology just isn't a deal breaker. If it were, JSON interoperability would be much worse.

- Rob
--047d7ba97b9485d04704dff1f07d-- From ietf@lindenbergsoftware.com Mon Jun 24 20:15:55 2013 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 EE9F721E8090 for ; Mon, 24 Jun 2013 20:15:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.668 X-Spam-Level: X-Spam-Status: No, score=-3.668 tagged_above=-999 required=5 tests=[AWL=-0.069, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jeoqx+TR5G7s for ; Mon, 24 Jun 2013 20:15:50 -0700 (PDT) Received: from mirach.lunarpages.com (mirach.lunarpages.com [216.97.235.70]) by ietfa.amsl.com (Postfix) with ESMTP id 2A05821F9CEC for ; Mon, 24 Jun 2013 20:15:50 -0700 (PDT) Received: from 50-0-136-241.dsl.dynamic.sonic.net ([50.0.136.241]:55785 helo=[192.168.0.5]) by mirach.lunarpages.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1UrJjR-002KEF-36; Mon, 24 Jun 2013 20:15:49 -0700 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Norbert Lindenberg In-Reply-To: <20130625024323.GE14060@mercury.ccil.org> Date: Mon, 24 Jun 2013 20:15:44 -0700 Content-Transfer-Encoding: 7bit Message-Id: <3D0E6548-91DA-4DDA-AA82-99C5A166D37E@lindenbergsoftware.com> References: <20130624233521.GF19899@mercury.ccil.org> <3D442E5F-F9ED-47DB-9E1D-29ACA8588717@vpnc.org> <3BBF18FB-63DE-40DE-93B4-1F8343386872@lindenbergsoftware.com> <6B5B32EF-E4EA-461A-8C73-262375703A04@vpnc.org> <20130625024323.GE14060@mercury.ccil.org> To: John Cowan X-Mailer: Apple Mail (2.1283) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - mirach.lunarpages.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - lindenbergsoftware.com X-Get-Message-Sender-Via: mirach.lunarpages.com: authenticated_id: ietf@lindenbergsoftware.com Cc: Norbert Lindenberg , Paul Hoffman , "json@ietf.org WG" Subject: Re: [Json] Proposal: the minimal edit X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 25 Jun 2013 03:15:56 -0000 On Jun 24, 2013, at 19:43 , John Cowan wrote: > Paul Hoffman scripsit: > >>> On the other hand, all code points that an ECMAScript implementation >>> can generate and consume are allowed by the JSON grammar, so by that >>> measure there's no difference between the two specifications. >> >> There is wide disagreement on that statement in the WG so far. > > I have seen no disagreement about the truth of it, but much about the > desirability of it. Thank you, John. Norbert From cowan@ccil.org Mon Jun 24 20:20:20 2013 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 2D58021E808F for ; Mon, 24 Jun 2013 20:20:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.472 X-Spam-Level: X-Spam-Status: No, score=-2.472 tagged_above=-999 required=5 tests=[AWL=-0.885, BAYES_00=-2.599, FAKE_REPLY_C=2.012, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D0fZUQCmFf4x for ; Mon, 24 Jun 2013 20:20:15 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id C183921E8090 for ; Mon, 24 Jun 2013 20:20:14 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1UrJni-0003Yj-AU for json@ietf.org; Mon, 24 Jun 2013 23:20:14 -0400 Date: Mon, 24 Jun 2013 23:20:14 -0400 From: John Cowan To: json@ietf.org Message-ID: <20130625032014.GF14060@mercury.ccil.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Subject: Re: [Json] Proposal: the minimal edit X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 25 Jun 2013 03:20:20 -0000 Paul Hoffman scripsit: > Add Section 1.2, "Changes from RFC 4627" > > This section lists all changes between this document and the text in > RFC 4627. > > - Applied errata #607 from RFC 4627 to correctly align the artwork > for the definition of "object". > > - Applied errata #3607 from RFC 4627 by removing the security > consideration that begins "A JSON text can be safely passed" > and the JavaScript code that went with that consideration. > > - Added Section 1.3, "Differences from the JSON Definition in ECMAScript". > > - Changed the [ECMA] and [UNICODE] references to be non-version-specific. Given these changes, and *only* these changes, then I do not believe that > - ECMAScript implementations can generate and consume code points > in JSON strings that are not Unicode characters. belongs in Section 1.3, for it is equally true of ECMA-JSON and RFC 4627 JSON. Both of them allow code points that are not Unicode characters, e.g. unassigned codepoints. So this point is true but not relevant. -- I Hope, Sir, that we are not John Cowan mutually Un-friended by this cowan@ccil.org Difference which hath happened http://www.ccil.org/~cowan betwixt us. --Thomas Fuller, Appeal of Injured Innocence (1659) From paul.hoffman@vpnc.org Mon Jun 24 20:31:52 2013 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 9E2B021F9121 for ; Mon, 24 Jun 2013 20:31:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.519 X-Spam-Level: X-Spam-Status: No, score=-102.519 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SdfbjAvkHb7k for ; Mon, 24 Jun 2013 20:31:52 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 15AEB21F9079 for ; Mon, 24 Jun 2013 20:31:52 -0700 (PDT) Received: from [10.20.30.90] (50-0-66-165.dsl.dynamic.sonic.net [50.0.66.165]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r5P3Vn1B098955 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 24 Jun 2013 20:31:49 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Paul Hoffman In-Reply-To: <20130625032014.GF14060@mercury.ccil.org> Date: Mon, 24 Jun 2013 20:31:48 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130625032014.GF14060@mercury.ccil.org> To: John Cowan X-Mailer: Apple Mail (2.1508) Cc: json@ietf.org Subject: Re: [Json] Proposal: the minimal edit X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 25 Jun 2013 03:31:52 -0000 On Jun 24, 2013, at 8:20 PM, John Cowan wrote: > Paul Hoffman scripsit: >=20 >> Add Section 1.2, "Changes from RFC 4627" >>=20 >> This section lists all changes between this document and the text = in >> RFC 4627. >>=20 >> - Applied errata #607 from RFC 4627 to correctly align the artwork >> for the definition of "object". >>=20 >> - Applied errata #3607 from RFC 4627 by removing the security >> consideration that begins "A JSON text can be safely passed" >> and the JavaScript code that went with that consideration. >>=20 >> - Added Section 1.3, "Differences from the JSON Definition in = ECMAScript".=20 >>=20 >> - Changed the [ECMA] and [UNICODE] references to be = non-version-specific. >=20 > Given these changes, and *only* these changes, then I do not believe = that >=20 >> - ECMAScript implementations can generate and consume code points >> in JSON strings that are not Unicode characters. >=20 > belongs in Section 1.3, for it is equally true of ECMA-JSON and RFC = 4627 > JSON. Both of them allow code points that are not Unicode characters, > e.g. unassigned codepoints. So this point is true but not relevant. Hrm. Either you are focused only on the grammar section and not the = whole document, or you missed the Introduction to RFC 4627, which say = unequivocally: A string is a sequence of zero or more Unicode characters [UNICODE]. That statement disagrees with ABNF in the grammar, so the RFC is = ambiguous. Some people in the WG believe that this sentence is right and = the ABNF is wrong; others believe the other. Does that help make the sentence about the differences more believable? --Paul Hoffman= From cowan@ccil.org Mon Jun 24 20:48:33 2013 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 DCBAF21F84B6 for ; Mon, 24 Jun 2013 20:48:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.466 X-Spam-Level: X-Spam-Status: No, score=-3.466 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8PPibyXvCb4N for ; Mon, 24 Jun 2013 20:48:28 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id B5E5121F9CE1 for ; Mon, 24 Jun 2013 20:48:28 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1UrKF1-0006BV-Az; Mon, 24 Jun 2013 23:48:27 -0400 Date: Mon, 24 Jun 2013 23:48:27 -0400 From: John Cowan To: Paul Hoffman Message-ID: <20130625034827.GG14060@mercury.ccil.org> References: <20130625032014.GF14060@mercury.ccil.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Cc: json@ietf.org Subject: Re: [Json] Proposal: the minimal edit X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 25 Jun 2013 03:48:34 -0000 Paul Hoffman scripsit: > Hrm. Either you are focused only on the grammar section and not the > whole document, or you missed the Introduction to RFC 4627, which > say unequivocally: > > A string is a sequence of zero or more Unicode characters [UNICODE]. It's actually quite equivocal: it neither states that any Unicode character may appear in a string, nor that everything that appears in a string is a Unicode character. But let that go for a moment. > That statement disagrees with ABNF in the grammar, so the RFC is > ambiguous. Some people in the WG believe that this sentence is right > and the ABNF is wrong; others believe the other. Since your proposal leaves the ambiguity intact, we don't know whether the meaning of the RFC as revised by your proposal is or is not the same as what ECMA-JSON prescribes. > Does that help make the sentence about the differences more believable? I don't disbelieve it; I don't think it belongs in a list of differences until we have decided whether or not there is any difference. -- "Well, I'm back." --Sam John Cowan From sayrer@gmail.com Mon Jun 24 20:53:30 2013 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 56C0B21E8084 for ; Mon, 24 Jun 2013 20:53:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.536 X-Spam-Level: X-Spam-Status: No, score=-2.536 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QhfIJp4Cuu-l for ; Mon, 24 Jun 2013 20:53:29 -0700 (PDT) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) by ietfa.amsl.com (Postfix) with ESMTP id 620E721E805E for ; Mon, 24 Jun 2013 20:53:29 -0700 (PDT) Received: by mail-wi0-f181.google.com with SMTP id hq4so296842wib.8 for ; Mon, 24 Jun 2013 20:53:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=i6Vv7H0KclcZl02ABFjPM8y6yVqNe6t418pMlY8FaEI=; b=YcCZ6GqRj93rwTifMlYhTO0BpACkxzcHGKDXq7vh46QN20tkkA1tUKZDyGabz510Kh g2cv/wbp2pH7E9LQZQWcAX3NOWJioH7nwXvn7eIEq4le0wxrxWOdJVXWDPu+6BkZeqsV 8N10q3OoOdmm4v7s7TyzeUE+pt/L2FansYMYUB3bcerFIR/VO4en5ZglSsP5FKyP3d72 VLu0ON/J2ccoU/OzIYulR1Jan553gdUx+7z2XpI4gtDqtj5RwCdgV2mwBWU5qZJT7SO3 5Lpgo33y4KyxolhcgMoa5XQ+OhuCfpBxKq1ZvGjgRKd72Gy27vTJghjCi87TIIG+RrBo LVpQ== MIME-Version: 1.0 X-Received: by 10.180.206.77 with SMTP id lm13mr7763454wic.18.1372132408514; Mon, 24 Jun 2013 20:53:28 -0700 (PDT) Received: by 10.194.44.138 with HTTP; Mon, 24 Jun 2013 20:53:28 -0700 (PDT) In-Reply-To: <20130625034827.GG14060@mercury.ccil.org> References: <20130625032014.GF14060@mercury.ccil.org> <20130625034827.GG14060@mercury.ccil.org> Date: Mon, 24 Jun 2013 20:53:28 -0700 Message-ID: From: R S To: John Cowan Content-Type: multipart/alternative; boundary=001a11c380aecb8ff604dff278df Cc: Paul Hoffman , "json@ietf.org" Subject: Re: [Json] Proposal: the minimal edit X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 25 Jun 2013 03:53:30 -0000 --001a11c380aecb8ff604dff278df Content-Type: text/plain; charset=ISO-8859-1 On Mon, Jun 24, 2013 at 8:48 PM, John Cowan wrote: > Paul Hoffman scripsit: > > > Hrm. Either you are focused only on the grammar section and not the > > whole document, or you missed the Introduction to RFC 4627, which > > say unequivocally: > > > > A string is a sequence of zero or more Unicode characters [UNICODE]. > > It's actually quite equivocal: it neither states that any Unicode character > may appear in a string, nor that everything that appears in a string is > a Unicode character. > I think that is a pretty strained interpretation. > > > That statement disagrees with ABNF in the grammar, so the RFC is > > ambiguous. Some people in the WG believe that this sentence is right > > and the ABNF is wrong; others believe the other. > > Since your proposal leaves the ambiguity intact, we don't know whether > the meaning of the RFC as revised by your proposal is or is not the same > as what ECMA-JSON prescribes. The RFC is ambiguous and ECMA-JSON is not. That's the difference, and we don't have to fix the RFC. - Rob --001a11c380aecb8ff604dff278df Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Mon, Jun 24, 2013 at 8:48 PM, John Cowan <cowan@m= ercury.ccil.org> wrote:
Paul Hoffman scripsit:

> Hrm. Either you are focused only on the grammar section and not the > whole document, or you missed the Introduction to RFC 4627, which
> say unequivocally:
>
> =A0 =A0A string is a sequence of zero or more Unicode characters [UNIC= ODE].

It's actually quite equivocal: it neither states that any Unicode= character
may appear in a string, nor that everything that appears in a string is
a Unicode character.=A0

I think t= hat is a pretty strained interpretation.

=A0
=

> That statement disagrees with ABNF in the grammar, so the RFC is
> ambiguous. Some people in the WG believe that this sentence is right > and the ABNF is wrong; others believe the other.

Since your proposal leaves the ambiguity intact, we don't know wh= ether
the meaning of the RFC as revised by your proposal is or is not the same as what ECMA-JSON prescribes.


The RFC is ambiguous and ECMA-JSON is not. That's the differenc= e, and we don't have to fix the RFC.

- Rob=A0
--001a11c380aecb8ff604dff278df-- From cabo@tzi.org Mon Jun 24 22:26:05 2013 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 403F421F9F53 for ; Mon, 24 Jun 2013 22:26:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.215 X-Spam-Level: X-Spam-Status: No, score=-106.215 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A3SkQNT+z+1r for ; Mon, 24 Jun 2013 22:25:59 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 9BB1B11E8108 for ; Mon, 24 Jun 2013 22:25:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r5P5Pu69015262; Tue, 25 Jun 2013 07:25:56 +0200 (CEST) Received: from [192.168.217.105] (p54893C8A.dip0.t-ipconnect.de [84.137.60.138]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id E2982331C; Tue, 25 Jun 2013 07:25:55 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: Date: Tue, 25 Jun 2013 07:25:55 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130625032014.GF14060@mercury.ccil.org> To: Paul Hoffman X-Mailer: Apple Mail (2.1508) Cc: John Cowan , json@ietf.org Subject: Re: [Json] Proposal: the minimal edit X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 25 Jun 2013 05:26:05 -0000 On Jun 25, 2013, at 05:31, Paul Hoffman wrote: > A string is a sequence of zero or more Unicode characters [UNICODE]. >=20 > That statement disagrees with ABNF in the grammar, so the RFC is = ambiguous. That statement *combines* with the ABNF. =20 The ABNF limits the representations, the first limits the strings = themselves. There is no ambiguity caused by having multiple restrictions in a = specification. Similarly, {"a": 1, "a": 2} isn't ambiguously valid JSON or not JSON by = being allowed by the ABNF. (Here, the other statement is a SHOULD, but that doesn't detract from my = point.) Of course, the statement about strings being sequences of Unicode = characters is in the introduction, so the level of normative detail it = imposes can be discussed, in particular in the light of the fact that = the specification isn't quite clear on Unicode terms in other places. = But the intent is very clear. Gr=FC=DFe, Carsten From tbray@textuality.com Mon Jun 24 22:45:54 2013 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 8F08921E812C for ; Mon, 24 Jun 2013 22:45:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.768 X-Spam-Level: X-Spam-Status: No, score=0.768 tagged_above=-999 required=5 tests=[AWL=-0.589, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y-wpztvNmU9E for ; Mon, 24 Jun 2013 22:45:50 -0700 (PDT) Received: from mail-ve0-x232.google.com (mail-ve0-x232.google.com [IPv6:2607:f8b0:400c:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id 4CB5221E804B for ; Mon, 24 Jun 2013 22:45:50 -0700 (PDT) Received: by mail-ve0-f178.google.com with SMTP id pb11so9761875veb.9 for ; Mon, 24 Jun 2013 22:45:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=WPHAluyqzOJFUkDrAAkI7yT8EjU+5nH4lfIOzPeSJBA=; b=B0y0PuapL7i3aDGWsPkVJ7heIahT8Hhw+rdYutjGmocxsDC7P5Hr/65uitoS5ZS3Vx mgh7d17MzGBrnU7M0QS2EuE5ZBrKl078je+/RnNN0jf9yCYYZBr6SqfMOh8XhysOhi60 RsLK1grbQjR/6g6ZJ04oswZnt32lvj1b0ZXb9WzpW0m3EoNHM35o+CN57ef9JqD3Y/W7 Bi3duYZ+t4MsG2vtdRIPwZ65oef/krLg4+0BoN+7ek+OAi+He3YEMy/x/x4KY7cHjKN9 dj05JObJHYD9eiPubN0Z1rd4/cmYj/wL2czwnfOjfCbNdsAaXMzPZASTM64PgbpYCGZq JcQg== MIME-Version: 1.0 X-Received: by 10.221.36.4 with SMTP id sy4mr4205172vcb.11.1372139148719; Mon, 24 Jun 2013 22:45:48 -0700 (PDT) Received: by 10.220.219.200 with HTTP; Mon, 24 Jun 2013 22:45:48 -0700 (PDT) X-Originating-IP: [24.84.235.32] In-Reply-To: References: <20130625032014.GF14060@mercury.ccil.org> Date: Mon, 24 Jun 2013 22:45:48 -0700 Message-ID: From: Tim Bray To: Carsten Bormann Content-Type: multipart/alternative; boundary=001a11339f388ad58004dff40a23 X-Gm-Message-State: ALoCoQmkgiNzTnL+gABwe2w6HHYmA7bwrdc/vo2FnqfTcr1yrPDvC3dubDXmDMVr2//GeL5u9qhs Cc: John Cowan , Paul Hoffman , "json@ietf.org" Subject: Re: [Json] Proposal: the minimal edit X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 25 Jun 2013 05:45:54 -0000 --001a11339f388ad58004dff40a23 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Jun 24, 2013 at 10:25 PM, Carsten Bormann wrote: > > A string is a sequence of zero or more Unicode characters [UNICODE]. > > > > That statement disagrees with ABNF in the grammar, so the RFC is > ambiguous. > > That statement *combines* with the ABNF. > The ABNF limits the representations, the first limits the strings > themselves. > I just can=E2=80=99t bring myself to see it that way. Any reasonable perso= n would read this statement in the introduction and conclude that a string is, you know, a sequence of Unicode characters. The fact that the ABNF later on contradicts this does not =E2=80=9Csupplement=E2=80=9D the introduction, it= =E2=80=99s just a spec-drafting goof. This is reflected in the empirical reality that in JSON's sweet spot, chiefly in the kind of network protocols the IETF cares about, JSON strings are de facto used to interchange sequences of Unicode characters, and reasonable developers would regard a failure to do so, even though blessed by the spec, as a bug. -T > > There is no ambiguity caused by having multiple restrictions in a > specification. > > Similarly, {"a": 1, "a": 2} isn't ambiguously valid JSON or not JSON by > being allowed by the ABNF. > (Here, the other statement is a SHOULD, but that doesn't detract from my > point.) > > Of course, the statement about strings being sequences of Unicode > characters is in the introduction, so the level of normative detail it > imposes can be discussed, in particular in the light of the fact that the > specification isn't quite clear on Unicode terms in other places. But th= e > intent is very clear. > > Gr=C3=BC=C3=9Fe, Carsten > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > --001a11339f388ad58004dff40a23 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Jun 24, 2013 at 10:25 PM, Carsten Bormann <cabo@tzi.or= g> wrote:
> A string is a sequence of zero or more Unicode chara= cters [UNICODE].
>
> That statement disagrees with ABNF in the grammar, so the RFC is ambig= uous.

That statement *combines* with the ABNF.
The ABNF limits the representations, the first limits the strings themselve= s.

I just can=E2=80=99t bring myself to= see it that way.=C2=A0 Any reasonable person would read this statement in = the introduction and conclude that a string is, you know, a sequence of Uni= code characters.=C2=A0 The fact that the ABNF later on contradicts this doe= s not =E2=80=9Csupplement=E2=80=9D the introduction, it=E2=80=99s just a sp= ec-drafting goof.=C2=A0 This is reflected in the empirical reality that in = JSON's sweet spot, chiefly in the kind of network protocols the IETF ca= res about, JSON strings are de facto used to interchange sequences of Unico= de characters, and reasonable developers would regard a failure to do so, e= ven though blessed by the spec, as a bug.

=C2=A0-T

=C2=A0

There is no ambiguity caused by having multiple restrictions in a specifica= tion.

Similarly, {"a": 1, "a": 2} isn't ambiguously valid= JSON or not JSON by being allowed by the ABNF.
(Here, the other statement is a SHOULD, but that doesn't detract from m= y point.)

Of course, the statement about strings being sequences of Unicode character= s is in the introduction, so the level of normative detail it imposes can b= e discussed, in particular in the light of the fact that the specification = isn't quite clear on Unicode terms in other places. =C2=A0But the inten= t is very clear.

Gr=C3=BC=C3=9Fe, Carsten

_______________________________________________
json mailing list
json@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/json

--001a11339f388ad58004dff40a23-- From cabo@tzi.org Mon Jun 24 23:07:22 2013 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 4915A21F9EE2 for ; Mon, 24 Jun 2013 23:07:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.216 X-Spam-Level: X-Spam-Status: No, score=-106.216 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jI+G8hO1jdoK for ; Mon, 24 Jun 2013 23:07:16 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 169FE21F9E96 for ; Mon, 24 Jun 2013 23:07:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r5P67DIZ026117; Tue, 25 Jun 2013 08:07:13 +0200 (CEST) Received: from [192.168.217.105] (p54893C8A.dip0.t-ipconnect.de [84.137.60.138]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 0A1B93339; Tue, 25 Jun 2013 08:07:12 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Content-Type: text/plain; charset=windows-1252 From: Carsten Bormann In-Reply-To: Date: Tue, 25 Jun 2013 08:07:12 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130625032014.GF14060@mercury.ccil.org> To: Tim Bray X-Mailer: Apple Mail (2.1508) Cc: John Cowan , Paul Hoffman , "json@ietf.org" Subject: Re: [Json] Proposal: the minimal edit X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 25 Jun 2013 06:07:22 -0000 On Jun 25, 2013, at 07:45, Tim Bray wrote: > I just can=92t bring myself to see it that way. Any reasonable person = would read this statement in the introduction and conclude that a string = is, you know, a sequence of Unicode characters. The fact that the ABNF = later on contradicts this does not =93supplement=94 the introduction, = it=92s just a spec-drafting goof. =20 I really have no idea where the "contradict" meme comes from. (Well, actually, I do, see below.) I'm much more interested in getting interoperability right than in language lawyering, but where we are arguing from the existing specs, we do have to read them right first. Not trying to express every constraint in the ABNF is reasonable spec = economy. =20 Why try to express clumsily in the ABNF what can already be said = referencing a well-defined concept? Try writing the ABNF for surrogate pair escapes and you'll see what I = mean. (Sure, it *can* be done. Would you want to?) The specific objective of the ABNF here was to explain what must be = escaped for *JSON* reasons. Re-encoding the Unicode spec in the ABNF apparently wasn't the = objective. I'm writing this mainly because I have had to make the same kind of = decision before: Encode all possible restrictions in the ABNF or keep it readable? Again, not everything allowed by the ABNF is a valid instance of the = format. I'm not aware of any usage of ABNF where that would be the case. You always have to read the rest of the specification, too. > This is reflected in the empirical reality that in JSON's sweet spot, = chiefly in the kind of network protocols the IETF cares about, JSON = strings are de facto used to interchange sequences of Unicode = characters, and reasonable developers would regard a failure to do so, = even though blessed by the spec, as a bug. That is an important reality. (It is hardly derived from a careful reading of RFC 4627, however.) Our problem in this WG really is that this is only part of the reality. There is another community that believes JSON is a format proprietary to = JavaScript, so whatever is common (even if bad) practice in the = JavaScript world needs to be within the JSON envelope. Of course, if = you believe that, you will grasp for straws like this "contradiction". That clash of communities is why we even have the discussion here. =20 Gr=FC=DFe, Carsten From sayrer@gmail.com Mon Jun 24 23:36:42 2013 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 BB32211E80D1 for ; Mon, 24 Jun 2013 23:36:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WZb6NQN+UWkG for ; Mon, 24 Jun 2013 23:36:42 -0700 (PDT) Received: from mail-wg0-x231.google.com (mail-wg0-x231.google.com [IPv6:2a00:1450:400c:c00::231]) by ietfa.amsl.com (Postfix) with ESMTP id 0C0B411E80CC for ; Mon, 24 Jun 2013 23:36:41 -0700 (PDT) Received: by mail-wg0-f49.google.com with SMTP id a12so8851581wgh.4 for ; Mon, 24 Jun 2013 23:36:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=9i/kwCEFZAfjmMVdHzn8rlFzOm0p6vTjQzASPXCDDwk=; b=egkVe8Ou09ZloFwqbudMIG9GAraukYieGcr+tTDw5wKOBjY6GdLl3L1jWld4qBtbcy zSDfQqR1MZesCWPqCrnbwUB7lj+Gket7LYUya7oEvE/57HrnTjIbB9rk//fHn01s2wKU eqxJuqN1eyONJ2Z1vxGc+a0564QDMeY78AuIx1dpFaF2/32JC0YCcsO7OSGvp43MuWDB T06tsO0be+H0D37+nYRqWnBsF7EI1e7rlzCo3m7mkm8pVcSUCKB97RWeIprGQikTf9ia gPtVXXn9iDmeqAwmo4+xKTWAqtqppFj9AyEVWB5QHYPM20nlp1t9eBkUHBJxF/iB1IPC FsKw== MIME-Version: 1.0 X-Received: by 10.180.76.103 with SMTP id j7mr8170815wiw.21.1372142201212; Mon, 24 Jun 2013 23:36:41 -0700 (PDT) Received: by 10.194.44.138 with HTTP; Mon, 24 Jun 2013 23:36:41 -0700 (PDT) In-Reply-To: References: <20130625032014.GF14060@mercury.ccil.org> Date: Mon, 24 Jun 2013 23:36:41 -0700 Message-ID: From: R S To: Carsten Bormann Content-Type: multipart/alternative; boundary=f46d043c7cc67c164c04dff4c0bc Cc: John Cowan , Tim Bray , Paul Hoffman , "json@ietf.org" Subject: Re: [Json] Proposal: the minimal edit X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 25 Jun 2013 06:36:42 -0000 --f46d043c7cc67c164c04dff4c0bc Content-Type: text/plain; charset=ISO-8859-1 On Mon, Jun 24, 2013 at 11:07 PM, Carsten Bormann wrote: > > There is another community that believes JSON is a format proprietary to > JavaScript, so whatever is common (even if bad) practice in the JavaScript > world needs to be within the JSON envelope. Of course, if you believe > that, you will grasp for straws like this "contradiction". > That clash of communities is why we even have the discussion here. First, I'll note that you seem to be saying something quite different from John and Norbert (I think). Second, I think the disagreement you've highlighted is real, although think it's phrased very helpfully. The crux of the matter is that the JavaScript implementations will not change, and they are material to the success of JSON and this Working Group, so they need to be documented. - Rob --f46d043c7cc67c164c04dff4c0bc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Mon, Jun 24, 2013 at 11:07 PM, Carsten Bormann <cabo@tzi.or= g> wrote:

There is another community that believes JSON is a format proprietary to Ja= vaScript, so whatever is common (even if bad) practice in the JavaScript wo= rld needs to be within the JSON envelope. =A0Of course, if you believe that= , you will grasp for straws like this "contradiction".
That clash of communities is why we even have the discussion here.

First, I'll note that you seem to be sayi= ng something quite different from John and Norbert (I think).

Second, I think the disagreement you've highlighte= d is real, although think it's phrased very helpfully. The crux of the = matter is that the JavaScript implementations will not change, and they are= material to the success of JSON and this Working Group, so they need to be= documented.

- Rob

--f46d043c7cc67c164c04dff4c0bc-- From duerst@it.aoyama.ac.jp Tue Jun 25 01:55:33 2013 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 8CF4021F9F04 for ; Tue, 25 Jun 2013 01:55:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.284 X-Spam-Level: X-Spam-Status: No, score=-103.284 tagged_above=-999 required=5 tests=[AWL=0.506, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k8-YCmBzc0VI for ; Tue, 25 Jun 2013 01:55:29 -0700 (PDT) Received: from scintmta02.scbb.aoyama.ac.jp (scintmta02.scbb.aoyama.ac.jp [133.2.253.34]) by ietfa.amsl.com (Postfix) with ESMTP id 1FB3921F9F0B for ; Tue, 25 Jun 2013 01:55:26 -0700 (PDT) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id r5P8tL0l020584; Tue, 25 Jun 2013 17:55:21 +0900 Received: from (unknown [133.2.206.134]) by scmse02.scbb.aoyama.ac.jp with smtp id 380f_7570_f77b02c2_dd74_11e2_a239_001e6722eec2; Tue, 25 Jun 2013 17:55:21 +0900 Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id 1A5E7BFC2B; Tue, 25 Jun 2013 17:53:54 +0900 (JST) Message-ID: <51C95AEE.2020908@it.aoyama.ac.jp> Date: Tue, 25 Jun 2013 17:55:10 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: Paul Hoffman References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "json@ietf.org WG" , R S Subject: Re: [Json] Proposal: the minimal edit X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 25 Jun 2013 08:55:33 -0000 I generally agree with Tim Bray on this. However, please change 'errata' to 'erratum' (two times) Regards, Martin. On 2013/06/25 6:28, Paul Hoffman wrote: > > > A few people on this thread have said they might support Rob's idea if they knew all the changes, and a few changes were thrown back and forth. I propose the following is a full set of what is needed. Please note the wording at the beginning of the proposed Section 1.3: this is about what ECMAScript actually says about JSON, not what that means to ECMAScript implementations. > > Thoughts? > > --Paul Hoffman > > Add Section 1.2, "Changes from RFC 4627" > > This section lists all changes between this document and the text in > RFC 4627. > > - Applied errata #607 from RFC 4627 to correctly align the artwork > for the definition of "object". > > - Applied errata #3607 from RFC 4627 by removing the security > consideration that begins "A JSON text can be safely passed" > and the JavaScript code that went with that consideration. > > - Added Section 1.3, "Differences from the JSON Definition in ECMAScript". > > - Changed the [ECMA] and [UNICODE] references to be non-version-specific. > > Add Section 1.3, "Differences from the JSON Definition in ECMAScript" > > The following lists the known major differences between this document and the definition of JSON > in Section 15.12 of [ECMA]. > > - ECMAScript implementations produce and consume primitive JSON values at the root level of JSON > documents. > > - ECMAScript implementations can generate and consume code points in JSON strings that are not > Unicode characters. > > - When there are duplicate names within an object, ECMAScript JSON parsers overwrite the value > corresponding to such names with the value that appears last in the serialization. > > In Section 6, remove "A JSON text can be safely passed" and the JavaScript code in the following > paragraph. > > In Section 9, change the title in the reference to [ECMA] to be be non-version-specific: > > [ECMA] European Computer Manufacturers Association, "ECMAScript > Language Specification", > ecma-st/ECMA-262.pdf>. > > In Section 9, change the reference to [UNICODE] to be be non-version-specific: > > [UNICODE] The Unicode Consortium, "The Unicode Standard", > . > > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > From derhoermi@gmx.net Tue Jun 25 02:44:58 2013 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 7FD0021F9F08 for ; Tue, 25 Jun 2013 02:44:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xlRaytDpxJyR for ; Tue, 25 Jun 2013 02:44:54 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) by ietfa.amsl.com (Postfix) with ESMTP id C3FAF21F960D for ; Tue, 25 Jun 2013 02:44:53 -0700 (PDT) Received: from mailout-de.gmx.net ([10.1.76.29]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0MZic4-1UZCSy3lRW-00LSTQ for ; Tue, 25 Jun 2013 11:44:50 +0200 Received: (qmail invoked by alias); 25 Jun 2013 09:44:50 -0000 Received: from p5B230AA5.dip0.t-ipconnect.de (EHLO netb.Speedport_W_700V) [91.35.10.165] by mail.gmx.net (mp029) with SMTP; 25 Jun 2013 11:44:50 +0200 X-Authenticated: #723575 X-Provags-ID: V01U2FsdGVkX18GO95uGeUGd8TqApbYkq6HCLx+R/qYlz58trVdaH is5Rx6gID1B/bA From: Bjoern Hoehrmann To: Paul Hoffman Date: Tue, 25 Jun 2013 11:44:48 +0200 Message-ID: References: <20130624233521.GF19899@mercury.ccil.org> <3D442E5F-F9ED-47DB-9E1D-29ACA8588717@vpnc.org> <20130625011904.GJ19899@mercury.ccil.org> <5FF84B9F-F637-48AC-921F-173F3370EF17@vpnc.org> <6DE2EFD8-4FE4-410E-AB0C-B0B34F313FEB@vpnc.org> <20130625023314.GD14060@mercury.ccil.org> In-Reply-To: X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 Cc: mamille2@cisco.com, John Cowan , "json@ietf.org WG" Subject: Re: [Json] Proposal: the minimal edit X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 25 Jun 2013 09:44:58 -0000 * Paul Hoffman wrote: >On Jun 24, 2013, at 7:33 PM, John Cowan wrote: >> Actually, I wouldn't say anything at this stage, now that I think >> about it. The time to write a list giving the differences between >> ECMA-JSON and RFC-JSON is after we know what it is that RFC-JSON says. >> Right now we don't. > >I apologize if I didn't make it clear, but the proposal that I made >earlier says *exactly* what is in what you call RFC-JSON. It is the >current draft, with only the changes that I listed. This is what Robert >proposed at the beginning of this thread. The Working Group has yet to decide whether it wants to, say, allow strings at the top level of application/json resources, so proposals for text detailing differences between "ECMA-JSON" and what this WG is going to define are premature. People who think strings should be allowed at the top level would not speak up in this thread, so the thread is not useful for finding consensus around substantive issues. -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ From cabo@tzi.org Tue Jun 25 03:19:30 2013 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 EC8DF21E8082 for ; Tue, 25 Jun 2013 03:19:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZRV+mCI-aG8f for ; Tue, 25 Jun 2013 03:19:25 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id D604621F9EF5 for ; Tue, 25 Jun 2013 03:19:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r5PAJLaK017127; Tue, 25 Jun 2013 12:19:21 +0200 (CEST) Received: from [10.0.1.4] (reingewinn.informatik.uni-bremen.de [134.102.218.123]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 318B035CA; Tue, 25 Jun 2013 12:19:21 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: Date: Tue, 25 Jun 2013 12:19:20 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130625032014.GF14060@mercury.ccil.org> To: R S X-Mailer: Apple Mail (2.1508) Cc: Tim Bray , John Cowan , Paul Hoffman , "json@ietf.org" Subject: Re: [Json] Proposal: the minimal edit X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 25 Jun 2013 10:19:31 -0000 On Jun 25, 2013, at 08:36, R S wrote: > The crux of the matter is that the JavaScript implementations will = not change, and they are material to the success of JSON and this = Working Group, so they need to be documented. I completely agree with the need for documenting the JSON usage that has = developed in that community. We seem to have painted ourselves into a corner a bit by distinguishing = the "standard" from a "best practices document", which is likely to = cause endless debate which community usage gets documented where. (The context of my message, however, was the interpretation that there = is an ambiguity in RFC 4627 with respect to its Unicode usage, and I was = trying to imagine how that interpretation might have been coming to = life.) Gr=FC=DFe, Carsten From cowan@ccil.org Tue Jun 25 05:48:30 2013 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 B75E221F9E18 for ; Tue, 25 Jun 2013 05:48:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.468 X-Spam-Level: X-Spam-Status: No, score=-3.468 tagged_above=-999 required=5 tests=[AWL=0.131, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f9Zplbc0PJ4V for ; Tue, 25 Jun 2013 05:48:26 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id 5D31821F9E7C for ; Tue, 25 Jun 2013 05:48:25 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1UrSfX-0000WT-MT; Tue, 25 Jun 2013 08:48:23 -0400 Date: Tue, 25 Jun 2013 08:48:23 -0400 From: John Cowan To: Carsten Bormann Message-ID: <20130625124823.GB26875@mercury.ccil.org> References: <20130625032014.GF14060@mercury.ccil.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Cc: Paul Hoffman , json@ietf.org Subject: Re: [Json] Proposal: the minimal edit X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 25 Jun 2013 12:48:30 -0000 Carsten Bormann scripsit: > That statement *combines* with the ABNF. > The ABNF limits the representations, the first limits the strings themselves. That would fly if the RFC didn't REQUIRE parsers to "accept all texts that conform to the JSON grammar". That means that ["X"] where X is an unpaired surrogate code point, is acceptable. -- What has four pairs of pants, lives John Cowan in Philadelphia, and it never rains http://www.ccil.org/~cowan but it pours? cowan@ccil.org --Rufus T. Firefly From cowan@ccil.org Tue Jun 25 05:50:03 2013 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 49C0521F9E96 for ; Tue, 25 Jun 2013 05:50:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.47 X-Spam-Level: X-Spam-Status: No, score=-3.47 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hIQBWFz-szfW for ; Tue, 25 Jun 2013 05:49:58 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id 2E32A21F96EB for ; Tue, 25 Jun 2013 05:49:58 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1UrSZH-0008AG-7t; Tue, 25 Jun 2013 08:41:55 -0400 Date: Tue, 25 Jun 2013 08:41:55 -0400 From: John Cowan To: Tim Bray Message-ID: <20130625124155.GA26875@mercury.ccil.org> References: <20130625032014.GF14060@mercury.ccil.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Cc: Carsten Bormann , Paul Hoffman , "json@ietf.org" Subject: Re: [Json] Proposal: the minimal edit X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 25 Jun 2013 12:50:03 -0000 Tim Bray scripsit: > I just can’t bring myself to see it that way. Any reasonable person would > read this statement in the introduction and conclude that a string is, you > know, a sequence of Unicode characters. The fact that the ABNF later on > contradicts this does not “supplement†the introduction, it’s just a > spec-drafting goof. Except that we know, from postings to this list and other lists, that the author's intent was to be able to exchange arbitrary code points. The goof, if any, was in the introduction, and consisted in the failure to define "Unicode character" in the ECMAScript rather than the Unicode sense. If read in connection with the ECMAScript 3 definition of "string value", all is clear: # 4.3.16 String Value # # A string value is a member of the type String and is a finite ordered # sequence of zero or more 16-bit unsigned integer values. # # NOTE # # Although each value usually represents a single 16-bit unit of UTF-16 # text, the language does not place any restrictions or requirements on # the values except that they be 16-bit unsigned integers. Now it's true that authorial intent cannot dictate the meaning of a spec, and it's also true that allowing the interchange of unescaped surrogate code points is bad, because there is no reliable way to encode them. Those are among the reasons why we are here, I hope. -- John Cowan Yakka foob mog. Grug pubbawup zink wattoom gazork. Chumble spuzz. --Calvin, giving Newton's First Law "in his own words" From cowan@ccil.org Tue Jun 25 05:51:17 2013 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 75EC521F9E27 for ; Tue, 25 Jun 2013 05:51:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.471 X-Spam-Level: X-Spam-Status: No, score=-3.471 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2-GSDrm9kCFy for ; Tue, 25 Jun 2013 05:51:13 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id 8101721F9E85 for ; Tue, 25 Jun 2013 05:51:13 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1UrSiF-0000iV-Rt; Tue, 25 Jun 2013 08:51:11 -0400 Date: Tue, 25 Jun 2013 08:51:11 -0400 From: John Cowan To: Carsten Bormann Message-ID: <20130625125111.GC26875@mercury.ccil.org> References: <20130625032014.GF14060@mercury.ccil.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Cc: Tim Bray , Paul Hoffman , "json@ietf.org" Subject: Re: [Json] Proposal: the minimal edit X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 25 Jun 2013 12:51:17 -0000 Carsten Bormann scripsit: > Try writing the ABNF for surrogate pair escapes and you'll see what I mean. > (Sure, it *can* be done. Would you want to?) Sure, why not? You just change unescaped = %x20-21 / %x23-5B / %x5D-10FFFF to unescaped = %x20-21 / %x23-5B / %x5D-D7FF / %xE000-10FFFF Trivial. -- Values of beeta will give rise to dom! John Cowan (5th/6th edition 'mv' said this if you tried http://www.ccil.org/~cowan to rename '.' or '..' entries; see cowan@ccil.org http://cm.bell-labs.com/cm/cs/who/dmr/odd.html) From cabo@tzi.org Tue Jun 25 05:57:58 2013 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 56EC421F8D90 for ; Tue, 25 Jun 2013 05:57:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EPSl0zKWCo8I for ; Tue, 25 Jun 2013 05:57:52 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id ECB5A21F9C10 for ; Tue, 25 Jun 2013 05:57:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r5PCvHxn024902; Tue, 25 Jun 2013 14:57:17 +0200 (CEST) Received: from eduroam-pool7-0058.wlan.uni-bremen.de (eduroam-pool7-0058.wlan.uni-bremen.de [134.102.112.58]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 9CC663796; Tue, 25 Jun 2013 14:57:17 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <20130625125111.GC26875@mercury.ccil.org> Date: Tue, 25 Jun 2013 14:57:17 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <83630ACB-939E-4461-94E9-62C41C9E7908@tzi.org> References: <20130625032014.GF14060@mercury.ccil.org> <20130625125111.GC26875@mercury.ccil.org> To: John Cowan X-Mailer: Apple Mail (2.1508) Cc: "json@ietf.org WG" Subject: Re: [Json] Proposal: the minimal edit X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 25 Jun 2013 12:57:58 -0000 On Jun 25, 2013, at 14:51, John Cowan wrote: > Carsten Bormann scripsit: >=20 >> Try writing the ABNF for surrogate pair escapes and you'll see what I = mean. >> (Sure, it *can* be done. Would you want to?) >=20 > Sure, why not? You just change >=20 > unescaped =3D %x20-21 / %x23-5B / %x5D-10FFFF >=20 > to >=20 > unescaped =3D %x20-21 / %x23-5B / %x5D-D7FF / %xE000-10FFFF You also have to fix the "\u" 4HEXDIG part (if you don't, it seems that = ill-formed Unicode is allowed in escape sequences and not in native = coding). This gets ugly quickly. Even uglier if you want to exclude the non-character code points as = well. Remember that this was written at a time when JSON was still vying for = its space. The appearance of complexity needed to be avoided. So why encode things in the ABNF that already are handled by Unicode? (Again, this is all about spec exegesis, not about reality.) Gr=FC=DFe, Carsten From cabo@tzi.org Tue Jun 25 05:58:03 2013 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 3771A21E809F for ; Tue, 25 Jun 2013 05:58:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MnQIQzgTr6CU for ; Tue, 25 Jun 2013 05:57:57 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 54D2121F9C23 for ; Tue, 25 Jun 2013 05:57:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r5PCvOLo025119; Tue, 25 Jun 2013 14:57:24 +0200 (CEST) Received: from eduroam-pool7-0058.wlan.uni-bremen.de (eduroam-pool7-0058.wlan.uni-bremen.de [134.102.112.58]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 9DBCB3797; Tue, 25 Jun 2013 14:57:24 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <20130625124823.GB26875@mercury.ccil.org> Date: Tue, 25 Jun 2013 14:57:24 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130625032014.GF14060@mercury.ccil.org> <20130625124823.GB26875@mercury.ccil.org> To: John Cowan X-Mailer: Apple Mail (2.1508) Cc: Paul Hoffman , json@ietf.org Subject: Re: [Json] Proposal: the minimal edit X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 25 Jun 2013 12:58:03 -0000 On Jun 25, 2013, at 14:48, John Cowan wrote: > That would fly if the RFC didn't REQUIRE parsers to "accept all texts > that conform to the JSON grammar". That means that >=20 > ["X"] >=20 > where X is an unpaired surrogate code point, is acceptable. The grammar is in terms of characters. You can't ship an unpaired surrogate code point in Unicode (neither in = UTF-8 nor in one of the UTF-16s and UTF-32s), so the grammar never gets = to see them. (Again, this is about spec language lawyering, not about reality.) Gr=FC=DFe, Carsten From cowan@ccil.org Tue Jun 25 08:40:03 2013 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 E344511E80EE for ; Tue, 25 Jun 2013 08:40:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.473 X-Spam-Level: X-Spam-Status: No, score=-3.473 tagged_above=-999 required=5 tests=[AWL=0.126, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bm6fMzGjVq54 for ; Tue, 25 Jun 2013 08:39:59 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id 95B5311E80F2 for ; Tue, 25 Jun 2013 08:39:58 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1UrV0z-0007ww-IL; Tue, 25 Jun 2013 11:18:44 -0400 Date: Tue, 25 Jun 2013 11:18:41 -0400 From: John Cowan To: Carsten Bormann Message-ID: <20130625151838.GD26875@mercury.ccil.org> References: <20130625032014.GF14060@mercury.ccil.org> <20130625125111.GC26875@mercury.ccil.org> <83630ACB-939E-4461-94E9-62C41C9E7908@tzi.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <83630ACB-939E-4461-94E9-62C41C9E7908@tzi.org> User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Cc: "json@ietf.org WG" Subject: Re: [Json] Proposal: the minimal edit X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 25 Jun 2013 15:40:04 -0000 Carsten Bormann scripsit: > You also have to fix the "\u" 4HEXDIG part (if you don't, it seems > that ill-formed Unicode is allowed in escape sequences and not in > native coding). I don't consider that a problem. -- John Cowan cowan@ccil.org http://www.ccil.org/~cowan Thor Heyerdahl recounts his attempt to prove Rudyard Kipling's theory that the mongoose first came to India on a raft from Polynesia. --blurb for Rikki-Kon-Tiki-Tavi From paul.hoffman@vpnc.org Wed Jun 26 08:47:28 2013 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 859C411E81C6 for ; Wed, 26 Jun 2013 08:47:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.949 X-Spam-Level: X-Spam-Status: No, score=-101.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5NNZhrl0YBsG for ; Wed, 26 Jun 2013 08:47:27 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 1618B11E811A for ; Wed, 26 Jun 2013 08:47:26 -0700 (PDT) Received: from [10.20.30.90] (50-0-66-165.dsl.dynamic.sonic.net [50.0.66.165]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r5QFlKV9072908 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 26 Jun 2013 08:47:22 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) From: Paul Hoffman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <6E1C1EF7-3971-4FD4-8BCE-349ED5B0B598@vpnc.org> Date: Wed, 26 Jun 2013 08:47:21 -0700 To: "json@ietf.org WG" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) Subject: [Json] Minimal edit proposal, second round X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 26 Jun 2013 15:47:28 -0000 The thread the last few days showed some confusion about what Rob's = proposal was. This new thread is an attempt to clarify so that we can = see if there is enough agreement to go down this path for the WG's first = document. This message is *not* to say "we will go that way instead of = the previous way", but instead to ask "does the WG want to go this way, = given more explicit information". First, the proposal is an alternative to the proposals so far in the WG, = not in addition to them. That is, the list of changes in the proposal = would be the *entire* set of changes; even the current document title = remains the same. If there is consensus to go this way, we drop all the = current consensus calls. We have made that clearer below. Second, it is quite clear that there is disagreement on what RFC 4627 = means with respect to the content of strings. Many people have = forcefully asserted what RFC 4627 meant, and yet many of them disagree. = Thus, we think it would be valuable to capture the fact that there is = disagreement in a factual manner. We have changed the proposed wording = for this below. Third, the WG's charter is clear that we don't get to start work on = additional documents until we finish 4627-bis. Having said that, there = seems to be near-universal agreement that an implementation guidance = document is needed. (I don't want to use the IETF-centric term "best = practices" because we don't have consensus on which practice is best.) = We can assume that the document will be produced, even if it isn't in = the charter and we have not agreed to the content of that document. Fourth, we have incorporated the editorial changes from the thread. The proposal below, then, is meant to be a way to determine if the WG = wants to go down the "minimal edit" route, or return to what we were = doing before, making non-minimal additions to the document by WG = consensus. Thoughts? --Matt Miller and Paul Hoffman Begin with http://tools.ietf.org/html/draft-ietf-json-rfc4627bis-02. Change Section 1.2, "Changes from RFC 4627", to read: This section lists all changes between this document and the text in RFC 4627. - Applied erratum #607 from RFC 4627 to correctly align the artwork for = the definition of "object". - Applied erratum #3607 from RFC 4627 by removing the security = consideration that begins "A JSON text can be safely passed" and the JavaScript code that went with = that consideration. - Added Section 1.3, "Differences from the JSON Definition in = ECMAScript". - Updated the [ECMA] reference, and changed the [UNICODE] references to = be non-version-specific. Add Section 1.3, "Differences Between This Document the JSON Definition = in ECMAScript" The following lists the known major differences between this document = and the definition of JSON in Section 15.12 of [ECMA]. - ECMAScript implementations produce and consume primitive JSON values = at the root level of JSON documents. - ECMAScript implementations can generate and consume all code points = in JSON strings, while there is disagreement about whether this document prohibits some specific = code points in JSON strings. - When there are duplicate names within an object, ECMAScript JSON = parsers overwrite the value corresponding to such names with the value that appears last in the = serialization. In Section 6, remove "A JSON text can be safely passed" and the = JavaScript code in the following paragraph. In Section 9, change the title in the reference to [ECMA] to be to the = latest version with JSON: [ECMA] Ecma International, "ECMAScript Language Specification, 5.1 = Edition / June 2011", = . In Section 9, change the reference to [UNICODE] to be be = non-version-specific: [UNICODE] The Unicode Consortium, "The Unicode Standard", = .= From sgbeal@googlemail.com Wed Jun 26 09:01:59 2013 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 1391221F91CE for ; Wed, 26 Jun 2013 09:01:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.685 X-Spam-Level: X-Spam-Status: No, score=-0.685 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MISSING_HEADERS=1.292, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xnx1oQF3DFHC for ; Wed, 26 Jun 2013 09:01:57 -0700 (PDT) Received: from mail-wg0-x232.google.com (mail-wg0-x232.google.com [IPv6:2a00:1450:400c:c00::232]) by ietfa.amsl.com (Postfix) with ESMTP id 1E42011E8104 for ; Wed, 26 Jun 2013 09:01:46 -0700 (PDT) Received: by mail-wg0-f50.google.com with SMTP id k14so10661951wgh.29 for ; Wed, 26 Jun 2013 09:01:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:cc :content-type; bh=Z2XgdEtf8BfChTIAOyg+YSN3wM83BOdt6wCCQ0AaaQE=; b=WEcyAm2u2SnaCgWrtv02X955TXabC6oFm9hxJPG0T8QAK9h5joLzjRFLW0JZD2sjd3 hUtsvJmi3JfgP/prx72ZZl4xB9wSySoPBF7dCkQJprPY5uniro2l/CBzW4vy7tld2pwJ 1GQ88s8oAVfxikRu1NKQmyd3RBpS9jMOnyWodXoaCSjEm9H6/eNLh7NPxAaWTiHX4EPI d5ySbntAIYPbfcbkBvpEAhs3hom3hBN+h8ZBmXkEqQ7Q2wuiHgRuPgh1EU1WisDKW2hM UT21R5OIV8cJnuXlKomn9WKUDd6aJ6jdBOXv7hQlHid9lXLI0uNYw2ilz8OvUHDew3/X fXdw== MIME-Version: 1.0 X-Received: by 10.180.211.233 with SMTP id nf9mr3135635wic.41.1372262505067; Wed, 26 Jun 2013 09:01:45 -0700 (PDT) Received: by 10.194.42.230 with HTTP; Wed, 26 Jun 2013 09:01:45 -0700 (PDT) In-Reply-To: <6E1C1EF7-3971-4FD4-8BCE-349ED5B0B598@vpnc.org> References: <6E1C1EF7-3971-4FD4-8BCE-349ED5B0B598@vpnc.org> Date: Wed, 26 Jun 2013 18:01:45 +0200 Message-ID: From: Stephan Beal Cc: "json@ietf.org WG" Content-Type: multipart/alternative; boundary=001a11c338d0273b8c04e010c340 Subject: Re: [Json] Minimal edit proposal, second round X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 26 Jun 2013 16:01:59 -0000 --001a11c338d0273b8c04e010c340 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Jun 26, 2013 at 5:47 PM, Paul Hoffman wrote: > Having said that, there seems to be near-universal agreement that an > implementation guidance document is needed. (I don't want to use the > IETF-centric term "best practices" because we don't have consensus on which > practice is best.) +1! Most excellently worded :). -- ----- stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal --001a11c338d0273b8c04e010c340 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Jun 26, 2013 at 5:47 PM, Paul Hoffman <paul.h= offman@vpnc.org> wrote:
Having said that, there seems to be near-universal agreeme= nt that an implementation guidance document is needed. (I don't want to= use the IETF-centric term "best practices" because we don't = have consensus on which practice is best.)

+1! Most excellently worded :).

--
----- stephan beal
http://wanderinghorse.net/home/stephan/<= div> http://gplus.to/sgbeal=
--001a11c338d0273b8c04e010c340-- From jsontest@yahoo.com Wed Jun 26 09:11:04 2013 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 20BA321F84F2 for ; Wed, 26 Jun 2013 09:11:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.83 X-Spam-Level: * X-Spam-Status: No, score=1.83 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, MIME_QP_LONG_LINE=1.396, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ouyDGRtbg465 for ; Wed, 26 Jun 2013 09:10:58 -0700 (PDT) Received: from nm1-vm1.bullet.mail.bf1.yahoo.com (nm1-vm1.bullet.mail.bf1.yahoo.com [98.139.213.163]) by ietfa.amsl.com (Postfix) with ESMTP id DF8E011E80DF for ; Wed, 26 Jun 2013 09:10:57 -0700 (PDT) Received: from [98.139.212.144] by nm1.bullet.mail.bf1.yahoo.com with NNFMP; 26 Jun 2013 16:10:56 -0000 Received: from [68.142.230.70] by tm1.bullet.mail.bf1.yahoo.com with NNFMP; 26 Jun 2013 16:10:56 -0000 Received: from [127.0.0.1] by smtp227.mail.bf1.yahoo.com with NNFMP; 26 Jun 2013 16:10:56 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1372263056; bh=WlW9HmE1Tvvnlb8WjGGobqS3Qz8kYjF7Oj27gYUHWd8=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:References:In-Reply-To:Mime-Version:Content-Type:Content-Transfer-Encoding:Message-Id:Cc:X-Mailer:From:Subject:Date:To; b=zsQWjcyMOlM5wBNekCrzjA0byaj/Hv7qPMcGJqhHThpXePxoEgHY3PayD7VOHHZpTaFf83R6eDFGBOFM2lGvWa7n+iz6KJy8BI4IxjhLmGAyH3+RW/9cBwCB4MCJpouS42ugc7ecWaBZCkeIXGLBWzr3Ey+huH2vYg8sOb71T1M= X-Yahoo-Newman-Id: 471557.48680.bm@smtp227.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: WJigMusVM1ktuF4kNvYVJP662Xt7mXSClpvSo9jv_puevOl IHmJ4KBtAJ7zUczx.6Eg0bBYulfhl823etV1Mpm.fe4jpxFLbiPal4fy_kP5 lJKz58Yg0xNhf.oS34LXsnJOALh8X4TnoOqZHs1EKL8ASbRU6eNlxiir6jeD vvqytIVwZS7SFq1Wl9kNu_nh9CaXjikxuA6kX1n_sqK8E87q_kWy6kTGdQkT WkjE6_VHcJusw.o1EhjnLKjWN7Bd3R5srDMGzi9UxWPylqIuNDedg1dZIxa6 CmFEAkwj1znno.fSDv9V6Rz4jPlAYhTv4EEBzKWA6sn2tjz5Ob5zKJnMkPrY fqMyQEK5AYfRVREiK2VpS2DVThqfePXzui9Mp3hqlS5Pw_OObX.qXpLrR7MP tED3Bzoi3dLZwu3jJc.oyScCHUgp4GcG7xfjoy4avnu.uwD5Ux.YbmllleWy 3gpC11kPGyed5HrtSteVOwNA.hVsCgyILn2lukOBgx8Io2Bn1MsqEOnNzDhL v5iY8DzCdCynDu5az5JNNGnrVGA-- X-Yahoo-SMTP: indQcmSswBC8IKsm6t4aCAPskK3T X-Rocket-Received: from [192.168.0.102] (jsontest@76.29.100.42 with ) by smtp227.mail.bf1.yahoo.com with SMTP; 26 Jun 2013 16:10:55 +0000 UTC References: <6E1C1EF7-3971-4FD4-8BCE-349ED5B0B598@vpnc.org> In-Reply-To: <6E1C1EF7-3971-4FD4-8BCE-349ED5B0B598@vpnc.org> Mime-Version: 1.0 (1.0) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <3922FD35-7BA4-4FA0-B15A-3D2CC4273361@yahoo.com> X-Mailer: iPod Mail (9B206) From: Vinny A Date: Wed, 26 Jun 2013 11:09:55 -0500 To: Paul Hoffman Cc: "json@ietf.org WG" Subject: Re: [Json] Minimal edit proposal, second round X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 26 Jun 2013 16:11:04 -0000 On Jun 26, 2013, at 10:47 AM, Paul Hoffman wrote: > . >=20 > The proposal below, then, is meant to be a way to determine if the WG want= s to go down the "minimal edit" route, or return to what we were doing befor= e, making non-minimal additions to the document by WG consensus. +1 to minimal edit. The proposal looks good as well. ----------------- Vinny www.jsontest.com From markus.lanthaler@gmx.net Wed Jun 26 09:26:09 2013 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 DAFFE21E80C0 for ; Wed, 26 Jun 2013 09:26:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.15 X-Spam-Level: X-Spam-Status: No, score=-1.15 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SYqBQqniJiYq for ; Wed, 26 Jun 2013 09:25:55 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) by ietfa.amsl.com (Postfix) with ESMTP id 685B121E80BB for ; Wed, 26 Jun 2013 09:25:53 -0700 (PDT) Received: from mailout-de.gmx.net ([10.1.76.12]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0MSoaR-1Uk0L40A57-00Roc1 for ; Wed, 26 Jun 2013 18:25:51 +0200 Received: (qmail invoked by alias); 26 Jun 2013 16:25:50 -0000 Received: from 84-115-182-43.dynamic.surfer.at (EHLO Vostro3500) [84.115.182.43] by mail.gmx.net (mp012) with SMTP; 26 Jun 2013 18:25:50 +0200 X-Authenticated: #419883 X-Provags-ID: V01U2FsdGVkX1+jIEEQxQejZBZM3QE86OXEShz8eUS0+KlP4ng5mY Mg5XQIpKnxlB/h From: "Markus Lanthaler" To: References: <6E1C1EF7-3971-4FD4-8BCE-349ED5B0B598@vpnc.org> In-Reply-To: <6E1C1EF7-3971-4FD4-8BCE-349ED5B0B598@vpnc.org> Date: Wed, 26 Jun 2013 18:25:50 +0200 Message-ID: <021c01ce7289$d2a5f2a0$77f1d7e0$@lanthaler@gmx.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac5yhHjn84y6iY8ZT1aEcOAOVH9BIwABIcaQ Content-Language: de X-Y-GMX-Trusted: 0 Subject: Re: [Json] Minimal edit proposal, second round X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 26 Jun 2013 16:26:09 -0000 On Wednesday, June 26, 2013 5:47 PM, Paul Hoffman wrote: > - ECMAScript implementations can generate and consume all code points > in JSON strings, while there is disagreement about whether this > document prohibits some specific code points in JSON strings. I'm wondering what the point is of updating the document if things like these are not clarified. Why are we not just reclassifying RFC 4627 from Informational to Standard and be done then? Apparently the RFC has been good enough to make JSON one of the most widely adopted data formats. -- Markus Lanthaler @markuslanthaler From cowan@ccil.org Wed Jun 26 09:29:51 2013 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 BA6D021E8087 for ; Wed, 26 Jun 2013 09:29:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2FqA7Ok6TtuA for ; Wed, 26 Jun 2013 09:29:47 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id CBD5521F9B2E for ; Wed, 26 Jun 2013 09:29:47 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1UrsbA-0006j0-Ev; Wed, 26 Jun 2013 12:29:36 -0400 Date: Wed, 26 Jun 2013 12:29:36 -0400 From: John Cowan To: Markus Lanthaler Message-ID: <20130626162936.GB13947@mercury.ccil.org> References: <6E1C1EF7-3971-4FD4-8BCE-349ED5B0B598@vpnc.org> <021c01ce7289$d2a5f2a0$77f1d7e0$@lanthaler@gmx.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <021c01ce7289$d2a5f2a0$77f1d7e0$@lanthaler@gmx.net> User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Cc: json@ietf.org Subject: Re: [Json] Minimal edit proposal, second round X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 26 Jun 2013 16:29:51 -0000 Markus Lanthaler scripsit: > I'm wondering what the point is of updating the document if things like > these are not clarified. Why are we not just reclassifying RFC 4627 from > Informational to Standard and be done then? Apparently the RFC has been good > enough to make JSON one of the most widely adopted data formats. +1 to that, and -1 to the proposal: it does not do enough to be worth doing. -- Values of beeta will give rise to dom! John Cowan (5th/6th edition 'mv' said this if you tried http://www.ccil.org/~cowan to rename '.' or '..' entries; see cowan@ccil.org http://cm.bell-labs.com/cm/cs/who/dmr/odd.html) From paul.hoffman@vpnc.org Wed Jun 26 09:36:33 2013 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 9176621F9E0D for ; Wed, 26 Jun 2013 09:36:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.166 X-Spam-Level: X-Spam-Status: No, score=-102.166 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IRFZh7QEeNLY for ; Wed, 26 Jun 2013 09:36:33 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 2799A21F8FC4 for ; Wed, 26 Jun 2013 09:36:07 -0700 (PDT) Received: from [10.20.30.90] (50-0-66-165.dsl.dynamic.sonic.net [50.0.66.165]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r5QGa1Zf074278 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 26 Jun 2013 09:36:02 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Paul Hoffman In-Reply-To: <021c01ce7289$d2a5f2a0$77f1d7e0$@lanthaler@gmx.net> Date: Wed, 26 Jun 2013 09:36:01 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <7A544ACB-39F3-4C85-B5D9-85F3AE429BCD@vpnc.org> References: <6E1C1EF7-3971-4FD4-8BCE-349ED5B0B598@vpnc.org> <021c01ce7289$d2a5f2a0$77f1d7e0$@lanthaler@gmx.net> To: Markus Lanthaler X-Mailer: Apple Mail (2.1508) Cc: json@ietf.org Subject: Re: [Json] Minimal edit proposal, second round X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 26 Jun 2013 16:36:33 -0000 On Jun 26, 2013, at 9:25 AM, Markus Lanthaler = wrote: > On Wednesday, June 26, 2013 5:47 PM, Paul Hoffman wrote: >> - ECMAScript implementations can generate and consume all code points >> in JSON strings, while there is disagreement about whether this >> document prohibits some specific code points in JSON strings. >=20 > I'm wondering what the point is of updating the document if things = like > these are not clarified. Why are we not just reclassifying RFC 4627 = from > Informational to Standard and be done then? Because the WG's charter = () requires us to do more: All differences between RFC 4627 or the current ECMAScript specification = will be documented in the new RFC. --Paul Hoffman= From cowan@ccil.org Wed Jun 26 09:41:27 2013 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 D03DC21F934B for ; Wed, 26 Jun 2013 09:41:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6SK--tQL3O0R for ; Wed, 26 Jun 2013 09:41:23 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id B93D321F92D3 for ; Wed, 26 Jun 2013 09:41:21 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1UrsmU-0007qL-Pq; Wed, 26 Jun 2013 12:41:18 -0400 Date: Wed, 26 Jun 2013 12:41:18 -0400 From: John Cowan To: Paul Hoffman Message-ID: <20130626164118.GC13947@mercury.ccil.org> References: <6E1C1EF7-3971-4FD4-8BCE-349ED5B0B598@vpnc.org> <021c01ce7289$d2a5f2a0$77f1d7e0$@lanthaler@gmx.net> <7A544ACB-39F3-4C85-B5D9-85F3AE429BCD@vpnc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7A544ACB-39F3-4C85-B5D9-85F3AE429BCD@vpnc.org> User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Cc: Markus Lanthaler , json@ietf.org Subject: Re: [Json] Minimal edit proposal, second round X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 26 Jun 2013 16:41:27 -0000 Paul Hoffman scripsit: > All differences between RFC 4627 or the current ECMAScript specification > will be documented in the new RFC. Presumably, however, we are not actually mandated to issue a new RFC; we could adjourn without doing anything. No? -- Kill Gorgun! Kill orc-folk! John Cowan No other words please Wild Men. cowan@ccil.org Drive away bad air and darkness http://www.ccil.org/~cowan with bright iron! --Ghan-buri-Ghan http://www.ccil.org/~cowan From cabo@tzi.org Wed Jun 26 09:42:45 2013 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 44B3911E80EC for ; Wed, 26 Jun 2013 09:42:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kwDfhFAPMEIj for ; Wed, 26 Jun 2013 09:42:39 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 2F0B321F93D4 for ; Wed, 26 Jun 2013 09:42:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r5QGga1I019700; Wed, 26 Jun 2013 18:42:36 +0200 (CEST) Received: from pptp-218-1.informatik.uni-bremen.de (pptp-218-1.informatik.uni-bremen.de [134.102.218.240]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 9A0CD3170; Wed, 26 Jun 2013 18:42:36 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <6E1C1EF7-3971-4FD4-8BCE-349ED5B0B598@vpnc.org> Date: Wed, 26 Jun 2013 18:42:35 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <8E346CF7-B2F4-4BC7-8993-5B0A86CF8C3E@tzi.org> References: <6E1C1EF7-3971-4FD4-8BCE-349ED5B0B598@vpnc.org> To: Paul Hoffman X-Mailer: Apple Mail (2.1508) Cc: "json@ietf.org WG" Subject: Re: [Json] Minimal edit proposal, second round X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 26 Jun 2013 16:42:45 -0000 On Jun 26, 2013, at 17:47, Paul Hoffman wrote: > there is disagreement about whether this document prohibits=20 I'm not sure that we should have a standards track document where we = can't figure out what it means. (Explicitly stating that then just adds insult to injury.) 1) The confusion needs to be captured. a) Then, if we really can't nail the specific items down, we at least = need to say which alternative interpretations there are. b) We probably need to give names to the various JSONs resulting, and=20 c) specify them in enough detail that there is no further seed for = divergence. 2) Simply always choosing the widest possible interpretation is exactly = the way soup is being made. In this context, condoning the widest possible interpretation is = equivalent to choosing it. *) 3) The discussion MUST NOT be based on what weird interpretations can be = assigned to existing words, but instead of what the interoperability = implications are. Gr=FC=DFe, Carsten *) Today, if someone sends me a document with duplicate keys, I'll say = "this has duplicate keys, can you send me valid JSON please?". Once the = standards track specification condones duplicate keys, that feature has = effectively become part of "JSON", and (outside tightly managed = environments) *all* receivers will have to adapt. That is the soup = process of protocol evolution at work. From derhoermi@gmx.net Wed Jun 26 10:00:03 2013 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 1C33E21E8122 for ; Wed, 26 Jun 2013 10:00:03 -0700 (PDT) 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=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JE715aF1dQGk for ; Wed, 26 Jun 2013 09:59:59 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by ietfa.amsl.com (Postfix) with ESMTP id 542E921E8131 for ; Wed, 26 Jun 2013 09:59:41 -0700 (PDT) Received: from mailout-de.gmx.net ([10.1.76.4]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0MSFoz-1Ug9rj1WrT-00TSnj for ; Wed, 26 Jun 2013 18:59:40 +0200 Received: (qmail invoked by alias); 26 Jun 2013 16:59:39 -0000 Received: from p54B4E304.dip0.t-ipconnect.de (EHLO netb.Speedport_W_700V) [84.180.227.4] by mail.gmx.net (mp004) with SMTP; 26 Jun 2013 18:59:39 +0200 X-Authenticated: #723575 X-Provags-ID: V01U2FsdGVkX18zKQwcVq4zyTPZ75DmJFzDXJhGbsZKS25mg7Crpn C2+zi7Gq1fJVCt From: Bjoern Hoehrmann To: Paul Hoffman Date: Wed, 26 Jun 2013 18:59:40 +0200 Message-ID: <1o4ms891gp7n3c28gl19a5djachnlucjeg@hive.bjoern.hoehrmann.de> References: <6E1C1EF7-3971-4FD4-8BCE-349ED5B0B598@vpnc.org> In-Reply-To: <6E1C1EF7-3971-4FD4-8BCE-349ED5B0B598@vpnc.org> X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 Cc: "json@ietf.org WG" Subject: Re: [Json] Minimal edit proposal, second round X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 26 Jun 2013 17:00:03 -0000 * Paul Hoffman wrote: >[...] I think the Working Group should attempt to standardize JSON in one document that obsoletes RFC 4627. That requires finding a consensus around issues like whether to allow strings at the top level and if Unicode signatures are permitted in application/json entities. It'd be quite unfortunate for the group to decide not to try to do so. I think the only problem so far was the choice of process that mainly lead to editorial discussions without providing much insight on the running code and rough consensus side of the substantive issues. I think it would be helpful, for instance, to conduct an off-list straw poll collecting data on where people stand on issues like if UTF-8 encoded application/json entities may start with `EF BB BF`, whether `["\uDFFF"]` is ("should be defined as valid") JSON and so on. Ideally with some data on what implementations and JSON forks do and corresponding rationale available beforehand. When we have that, we might find that there is no rough consensus on the issues, and might decide to do only a minimal bugfix revision, but we are not there yet. In http://www.ietf.org/mail-archive/web/json/current/msg00193.html I said pretty much the same during the chartering discussions. -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ From jhildebr@cisco.com Wed Jun 26 11:08:59 2013 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 8DFB711E81D3 for ; Wed, 26 Jun 2013 11:08:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nxtAzH4AZYLp for ; Wed, 26 Jun 2013 11:08:54 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 06EBE11E8117 for ; Wed, 26 Jun 2013 11:08:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=625; q=dns/txt; s=iport; t=1372270134; x=1373479734; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=XiIwk0xA2wWRNxhjDJ01aqU1meyQM1kFZJc5o5TD38Y=; b=MkomDVtcoz4+4PH+OsJL3fNSk4HlVF3WXoHIto7LkzL3FI9ektGO95ra lIv/sx9ry/C8SnDjYJbDprONE9pTKNZXo0GfFCYZFHmGD9fLGWSiSEBN+ F7xPgJclMYy1/BZpyXfCfnXwN3bIABoRv+yF6voIv+3pjtTAaSpDcBroL k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag0FANQty1GtJV2Y/2dsb2JhbABbgwl6gj+8PoEDFnSCJQEEOlEBCCIUQiUCBAESCIgGugyPGjiDAmEDqQqDEYIo X-IronPort-AV: E=Sophos;i="4.87,945,1363132800"; d="scan'208";a="227793506" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-8.cisco.com with ESMTP; 26 Jun 2013 18:08:52 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r5QI8pS0014765 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 26 Jun 2013 18:08:51 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.56]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.02.0318.004; Wed, 26 Jun 2013 13:08:51 -0500 From: "Joe Hildebrand (jhildebr)" To: Paul Hoffman , "json@ietf.org WG" Thread-Topic: [Json] Minimal edit proposal, second round Thread-Index: AQHOcoR/gzyOD4y2mkWcOm8qliOy+ZlIXCMA Date: Wed, 26 Jun 2013 18:08:50 +0000 Message-ID: In-Reply-To: <6E1C1EF7-3971-4FD4-8BCE-349ED5B0B598@vpnc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.5.130515 x-originating-ip: [10.21.73.207] Content-Type: text/plain; charset="us-ascii" Content-ID: <4401DCBDA2960041BA9DCE0218B1A769@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Json] Minimal edit proposal, second round X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 26 Jun 2013 18:08:59 -0000 On 6/26/13 11:47 AM, "Paul Hoffman" wrote: >First, the proposal is an alternative to the proposals so far in the WG, >not in addition to them. That is, the list of changes in the proposal >would be the *entire* set of changes; even the current document title >remains the same.=20 With that clarification, I'm full -1. Someone else will just have to fix the problems in 4627ter one day, and they're not going to have any easier of a time doing it that today. There's hard work ahead. We're the right people for the job. Let's stop trying to avoid our duty. --=20 Joe Hildebrand From cabo@tzi.org Wed Jun 26 11:11:51 2013 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 8D6FE11E81DB for ; Wed, 26 Jun 2013 11:11:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4hd8Q2td23yb for ; Wed, 26 Jun 2013 11:11:45 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 71F1721F9C4D for ; Wed, 26 Jun 2013 11:11:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r5QIBcsH027313 for ; Wed, 26 Jun 2013 20:11:38 +0200 (CEST) Received: from pptp-218-1.informatik.uni-bremen.de (pptp-218-1.informatik.uni-bremen.de [134.102.218.240]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 19F4731C9; Wed, 26 Jun 2013 20:11:38 +0200 (CEST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Carsten Bormann In-Reply-To: Date: Wed, 26 Jun 2013 20:11:37 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <19F69758-1F29-46C6-A76E-0101571FAA49@tzi.org> References: To: "json@ietf.org WG" X-Mailer: Apple Mail (2.1508) Subject: Re: [Json] Minimal edit proposal, second round X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 26 Jun 2013 18:11:51 -0000 On Jun 26, 2013, at 20:08, "Joe Hildebrand (jhildebr)" = wrote: > There's hard work ahead. We're the right people for the job. Let's = stop > trying to avoid our duty. This. Gr=FC=DFe, Carsten From tbray@textuality.com Wed Jun 26 11:15:55 2013 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 C116211E81DA for ; Wed, 26 Jun 2013 11:15:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.452 X-Spam-Level: X-Spam-Status: No, score=0.452 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_SORBS_DUL=0.877, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id biIeTKB+Up3l for ; Wed, 26 Jun 2013 11:15:51 -0700 (PDT) Received: from mail-ve0-x230.google.com (mail-ve0-x230.google.com [IPv6:2607:f8b0:400c:c01::230]) by ietfa.amsl.com (Postfix) with ESMTP id 930E711E81C7 for ; Wed, 26 Jun 2013 11:15:51 -0700 (PDT) Received: by mail-ve0-f176.google.com with SMTP id c13so11887746vea.35 for ; Wed, 26 Jun 2013 11:15:51 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=CE6NPvfH4gzCzgxPKRW+xeBOfclyrRNMWQyT/slU2mE=; b=V4WknZP4BxgHWZ4yGw3866Kf4dqBWZZLm7qHJtQS/0PN2hnn4sw7p9sr9/FzDQj8Dh Lw0yl76prfIOmawagrZyr+4yP3UhzFmcY4HaRV4w9YWGiLzTKDlO/isWmV+7QPYw+oOh Egvq0v5G8rKdh8fnAqd/4lTmehlzxd26nJ90ey+sYk8zwCxYlmVM0t5nrdVO+s+BpYX+ yg+NSZ0+2ncpbD3fDQ/0ECnfXYe4OBJ/M3IlY7XwjHelzd0lSBkQQHBYDixXtXj/sT54 hY0cOPsjYRPNJw0KYNv7ozZRKwjQypzQcxCRMnSubtEmKKwUP7YrLDIIq/KRSfjJeRj1 Y0RA== MIME-Version: 1.0 X-Received: by 10.220.67.137 with SMTP id r9mr2099355vci.69.1372270550863; Wed, 26 Jun 2013 11:15:50 -0700 (PDT) Received: by 10.220.219.200 with HTTP; Wed, 26 Jun 2013 11:15:50 -0700 (PDT) X-Originating-IP: [96.49.81.176] In-Reply-To: References: <6E1C1EF7-3971-4FD4-8BCE-349ED5B0B598@vpnc.org> Date: Wed, 26 Jun 2013 11:15:50 -0700 Message-ID: From: Tim Bray To: "Joe Hildebrand (jhildebr)" Content-Type: multipart/alternative; boundary=047d7b3a7db2b865e904e012a2e6 X-Gm-Message-State: ALoCoQmXWNID2Gt2DgjfPgjwJtxTQ9gFYmeBKXwKCoVsZB8O43pGYyHNKND62qRHjtgaOAyCaJES Cc: Paul Hoffman , "json@ietf.org WG" Subject: Re: [Json] Minimal edit proposal, second round X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 26 Jun 2013 18:15:55 -0000 --047d7b3a7db2b865e904e012a2e6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Yeah, but our charter clearly doesn=E2=80=99t let us fix JSON. What we nee= d is to do something like this, then re-charter to produce a doc that provides real guidance, so that, as someone in this thread pointed out, other Working Groups will have something to point to and won=E2=80=99t, as is currently h= appening in Jose, have to write explicit language forbidding dupes, etc, into their drafts. So I=E2=80=99m in favor of doing this minimal point-out-the-proble= ms work and moving on. -T On Wed, Jun 26, 2013 at 11:08 AM, Joe Hildebrand (jhildebr) < jhildebr@cisco.com> wrote: > On 6/26/13 11:47 AM, "Paul Hoffman" wrote: > > >First, the proposal is an alternative to the proposals so far in the WG, > >not in addition to them. That is, the list of changes in the proposal > >would be the *entire* set of changes; even the current document title > >remains the same. > > With that clarification, I'm full -1. Someone else will just have to fix > the problems in 4627ter one day, and they're not going to have any easier > of a time doing it that today. > > There's hard work ahead. We're the right people for the job. Let's stop > trying to avoid our duty. > > -- > Joe Hildebrand > > > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > --047d7b3a7db2b865e904e012a2e6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Yeah, but our charter clearly doesn=E2=80=99t let us fix J= SON.=C2=A0 What we need is to do something like this, then re-charter to pr= oduce a doc that provides real guidance, so that, as someone in this thread= pointed out, other Working Groups will have something to point to and won= =E2=80=99t, as is currently happening in Jose, have to write explicit langu= age forbidding dupes, etc, into their drafts.=C2=A0 So I=E2=80=99m in favor= of doing this minimal point-out-the-problems work and moving on. -T


On Wed,= Jun 26, 2013 at 11:08 AM, Joe Hildebrand (jhildebr) <= jhildebr@cisco.com<= /a>> wrote:
On 6/26/13 11:47 AM, "= ;Paul Hoffman" <paul.hoffm= an@vpnc.org> wrote:

>First, the proposal is an alternative to the proposals so far in the WG= ,
>not in addition to them. That is, the list of changes in the proposal >would be the *entire* set of changes; even the current document title >remains the same.

With that clarification, I'm full -1. =C2=A0Someone else will jus= t have to fix
the problems in 4627ter one day, and they're not going to have any easi= er
of a time doing it that today.

There's hard work ahead. =C2=A0We're the right people for the job. = =C2=A0Let's stop
trying to avoid our duty.

--
Joe Hildebrand



_______________________________________________
json mailing list
json@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/json

--047d7b3a7db2b865e904e012a2e6-- From cowan@ccil.org Wed Jun 26 11:23:20 2013 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 ADFD721F9EF5 for ; Wed, 26 Jun 2013 11:23:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FvNAMYbPlsxe for ; Wed, 26 Jun 2013 11:23:16 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id 25D8A21F9A38 for ; Wed, 26 Jun 2013 11:23:16 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1UruN0-0001Rz-3n; Wed, 26 Jun 2013 14:23:06 -0400 Date: Wed, 26 Jun 2013 14:23:06 -0400 From: John Cowan To: Tim Bray Message-ID: <20130626182305.GA3742@mercury.ccil.org> References: <6E1C1EF7-3971-4FD4-8BCE-349ED5B0B598@vpnc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Cc: Paul Hoffman , "Joe Hildebrand \(jhildebr\)" , "json@ietf.org WG" Subject: Re: [Json] Minimal edit proposal, second round X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 26 Jun 2013 18:23:20 -0000 Tim Bray scripsit: > Yeah, but our charter clearly doesn’t let us fix JSON. What we need is to > do something like this, then re-charter to produce a doc that provides real > guidance, so that, as someone in this thread pointed out, other Working > Groups will have something to point to and won’t, as is currently happening > in Jose, have to write explicit language forbidding dupes, etc, into their > drafts. So I’m in favor of doing this minimal point-out-the-problems work > and moving on. -T If we do that, we will have an ambiguous document on the standards track. The problem with implementation guidance is that it isn't normative: nobody can insist on compliance with it. If there's really no choice except to dissolve and recharter, or to pass this farce, +1 for dissolution. -- Using RELAX NG compact syntax to John Cowan develop schemas is one of the simple http://www.ccil.org/~cowan pleasures in life.... --Jeni Tennison From jhildebr@cisco.com Wed Jun 26 11:24:22 2013 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 7F49321F9F05 for ; Wed, 26 Jun 2013 11:24:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kgZsaTL4W-FG for ; Wed, 26 Jun 2013 11:24:17 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 3C02511E8125 for ; Wed, 26 Jun 2013 11:24:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1894; q=dns/txt; s=iport; t=1372271055; x=1373480655; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=sqDO8MEOz6sQzZxwaj6MHzYpEDH1KCuwIVnpSZKvDX8=; b=j5IOv5kN2kpPOcy5yr0W20GSY8RwxzX3OYksNjiozz1/ee84pLxALLmE c4ubiEtUV6F9UmIlO4Ut4tzBUqx3ai+5FHsjzEhXKRcoMeLItJdDsMGm8 v+9yEOThfNomnOi7IMdVqN9UiNazpnXD05B/7x1mOe0P9ir+hgBLZqMU0 U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAOowy1GtJXG+/2dsb2JhbABbgwkxSb59gQMWdIIjAQEBBAEBAWsLEgEIDgoKSwslAgQOBQgXh28MuXoEjxoxB4MCYQOIaqAggxGCKA X-IronPort-AV: E=Sophos;i="4.87,945,1363132800"; d="scan'208";a="227827464" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-3.cisco.com with ESMTP; 26 Jun 2013 18:24:15 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r5QIOEYn018854 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 26 Jun 2013 18:24:14 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.56]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.02.0318.004; Wed, 26 Jun 2013 13:24:14 -0500 From: "Joe Hildebrand (jhildebr)" To: Tim Bray Thread-Topic: [Json] Minimal edit proposal, second round Thread-Index: AQHOcoR/gzyOD4y2mkWcOm8qliOy+ZlIXCMAgABFBQD//79GAA== Date: Wed, 26 Jun 2013 18:24:13 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.5.130515 x-originating-ip: [10.21.73.207] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Paul Hoffman , "json@ietf.org WG" Subject: Re: [Json] Minimal edit proposal, second round X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 26 Jun 2013 18:24:22 -0000 If we have a path forward on JSON+ (or JSON- for that matter), then I guess I could be ok with this change as a step toward that. However, I won't be +1 on the minimal set of known-broken changes until I see the path for how we're going to get *that* doc completed. However, I'd almost rather declare defeat on the current charter and skip to writing the doc that I thought we were signing up for. On 6/26/13 2:15 PM, "Tim Bray" wrote: >Yeah, but our charter clearly doesn=B9t let us fix JSON. What we need is >to do something like this, then re-charter to produce a doc that provides >real guidance, so that, as someone in this thread pointed out, other >Working Groups will have something > to point to and won=B9t, as is currently happening in Jose, have to write >explicit language forbidding dupes, etc, into their drafts. So I=B9m in >favor of doing this minimal point-out-the-problems work and moving on. -T > > > >On Wed, Jun 26, 2013 at 11:08 AM, Joe Hildebrand (jhildebr) > wrote: > >On 6/26/13 11:47 AM, "Paul Hoffman" wrote: > >>First, the proposal is an alternative to the proposals so far in the WG, >>not in addition to them. That is, the list of changes in the proposal >>would be the *entire* set of changes; even the current document title >>remains the same. > > >With that clarification, I'm full -1. Someone else will just have to fix >the problems in 4627ter one day, and they're not going to have any easier >of a time doing it that today. > >There's hard work ahead. We're the right people for the job. Let's stop >trying to avoid our duty. > >-- >Joe Hildebrand > > > >_______________________________________________ >json mailing list >json@ietf.org >https://www.ietf.org/mailman/listinfo/json > > > > > > > > --=20 Joe Hildebrand From jhildebr@cisco.com Wed Jun 26 11:25:27 2013 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 12E5921F9F51 for ; Wed, 26 Jun 2013 11:25:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AtEg1FQdtTO5 for ; Wed, 26 Jun 2013 11:25:21 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 82DE421F9EF5 for ; Wed, 26 Jun 2013 11:25:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=446; q=dns/txt; s=iport; t=1372271121; x=1373480721; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=xmQTNNB0ofDhSuF8f2XbdKaZ9jrj3XTEZBNhEhQkSI4=; b=l45CRJRRXQDMi8KHIqNL9S0N5D47/EQa2YzmAjfv36PFYkERZVAxx8h1 OU2QjRPPn3+p5kNY3bMwvmgJbwMZVTU8E3SuuSeYQ9vw6tIk4+dnBguLX /AXjd3uHxEANKhGmnw3cfeq/1d7WLyM+UNBclPYhBgTG8GbPfv9AUXpk1 U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag4FAF8xy1GtJXG+/2dsb2JhbABbgwl6gj+8PoEDFnSCJQEEOj8SAQgiFEIlAgQBDQUIiAa6Co8aMQeDAmEDqQqDEYIo X-IronPort-AV: E=Sophos;i="4.87,945,1363132800"; d="scan'208";a="227801780" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-8.cisco.com with ESMTP; 26 Jun 2013 18:25:20 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r5QIPKhk020788 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 26 Jun 2013 18:25:20 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.56]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.02.0318.004; Wed, 26 Jun 2013 13:25:20 -0500 From: "Joe Hildebrand (jhildebr)" To: John Cowan , Tim Bray Thread-Topic: [Json] Minimal edit proposal, second round Thread-Index: AQHOcoR/gzyOD4y2mkWcOm8qliOy+ZlIXCMAgABFBQCAAAIIAP//vY0A Date: Wed, 26 Jun 2013 18:25:19 +0000 Message-ID: In-Reply-To: <20130626182305.GA3742@mercury.ccil.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.5.130515 x-originating-ip: [10.21.73.207] Content-Type: text/plain; charset="us-ascii" Content-ID: <2FE0E20CD9FDDF439F6CA1A9D279E9DE@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Paul Hoffman , "json@ietf.org WG" Subject: Re: [Json] Minimal edit proposal, second round X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 26 Jun 2013 18:25:27 -0000 On 6/26/13 2:23 PM, "John Cowan" wrote: >If we do that, we will have an ambiguous document on the standards track. >The problem with implementation guidance is that it isn't normative: >nobody can insist on compliance with it. If there's really no choice >except to dissolve and recharter, or to pass this farce, +1 for >dissolution. John said what I was trying to much more clearly. --=20 Joe Hildebrand From paul.hoffman@vpnc.org Wed Jun 26 11:45:26 2013 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 CE43A11E81E0 for ; Wed, 26 Jun 2013 11:45:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.274 X-Spam-Level: X-Spam-Status: No, score=-102.274 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qjgVSEUyeoGN for ; Wed, 26 Jun 2013 11:45:26 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 5B45511E81DC for ; Wed, 26 Jun 2013 11:45:26 -0700 (PDT) Received: from [10.20.30.90] (50-0-66-165.dsl.dynamic.sonic.net [50.0.66.165]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r5QIjOt4078616 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 26 Jun 2013 11:45:25 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Paul Hoffman In-Reply-To: <20130626182305.GA3742@mercury.ccil.org> Date: Wed, 26 Jun 2013 11:45:23 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <949037D0-B1EC-4114-BA9A-5A820119872B@vpnc.org> References: <6E1C1EF7-3971-4FD4-8BCE-349ED5B0B598@vpnc.org> <20130626182305.GA3742@mercury.ccil.org> To: John Cowan X-Mailer: Apple Mail (2.1508) Cc: "json@ietf.org WG" Subject: Re: [Json] Minimal edit proposal, second round X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 26 Jun 2013 18:45:26 -0000 On Jun 26, 2013, at 11:23 AM, John Cowan wrote: > If we do that, we will have an ambiguous document on the standards = track. We currently have an ambiguous document *that everyone has used for six = years* as the de facto standard. No one noticed this ambiguity (at least = in public) until *after* we started this WG. I claim that leaving the long-unnoticed ambiguity in and slightly = calling it out will do no harm to the people who use the standard. > The problem with implementation guidance is that it isn't normative: > nobody can insist on compliance with it. =20 If the implementation guidance is written carefully (and, given the high = interest in this topic in the past month, I bet it will be), someone can = insist on compliance to section 3.2.1's interpretation instead of = 3.2.2's interpretation. > If there's really no choice > except to dissolve and recharter, or to pass this farce, +1 for = dissolution. We don't have to dissolve in order to recharter. In fact, we are better = off if we don't. --Paul Hoffman= From stpeter@stpeter.im Wed Jun 26 11:57:26 2013 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 B7E3D21F9EC2 for ; Wed, 26 Jun 2013 11:57:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FQjJkVb+a4aY for ; Wed, 26 Jun 2013 11:57:21 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 82AB021F964C for ; Wed, 26 Jun 2013 11:57:21 -0700 (PDT) Received: from ergon.local (unknown [128.107.239.234]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 73C52412F9; Wed, 26 Jun 2013 12:57:42 -0600 (MDT) Message-ID: <51CB398F.8070603@stpeter.im> Date: Wed, 26 Jun 2013 12:57:19 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Paul Hoffman References: <6E1C1EF7-3971-4FD4-8BCE-349ED5B0B598@vpnc.org> <20130626182305.GA3742@mercury.ccil.org> <949037D0-B1EC-4114-BA9A-5A820119872B@vpnc.org> In-Reply-To: <949037D0-B1EC-4114-BA9A-5A820119872B@vpnc.org> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: John Cowan , "json@ietf.org WG" Subject: Re: [Json] Minimal edit proposal, second round X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 26 Jun 2013 18:57:26 -0000 On 6/26/13 12:45 PM, Paul Hoffman wrote: > > > On Jun 26, 2013, at 11:23 AM, John Cowan > wrote: > >> If we do that, we will have an ambiguous document on the standards >> track. > > We currently have an ambiguous document *that everyone has used for > six years* as the de facto standard. No one noticed this ambiguity > (at least in public) until *after* we started this WG. And further: the fact that the sky hasn't fallen yet indicates to me that developers are sensibly following the lead of the tremendous amount of running code out there, and not getting confused about some edge-case ambiguities in the formal spec. Rechartering seems like an extreme reaction here. Steady on. Peter -- Peter Saint-Andre https://stpeter.im/ From sayrer@gmail.com Wed Jun 26 13:00:54 2013 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 8C56611E8202 for ; Wed, 26 Jun 2013 13:00:54 -0700 (PDT) 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=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vLjpk6wx-BUk for ; Wed, 26 Jun 2013 13:00:52 -0700 (PDT) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) by ietfa.amsl.com (Postfix) with ESMTP id 82F4811E8203 for ; Wed, 26 Jun 2013 13:00:47 -0700 (PDT) Received: by mail-wi0-f176.google.com with SMTP id ey16so2392028wid.9 for ; Wed, 26 Jun 2013 13:00:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=UhMHODg/9zXSr5T5/gcybKddzIQC9ubBlbOt/uDjZKY=; b=QivJK+2Xdp4rsAhulNaiIBQkZ8rhQyCnjbUPXtp3RoiHdQfPhiGNjrmbKxIBye7FUd opgnpm8Go6DAqSKwcDXT2MWzZXLBjWmjzDelffiydTsrov6+bCR1ns9mO1KnFR2/hjuH u0CCKFre9QE+FoAVx81IR035tAkTwjx4clJ+j19mahe0THCjVPvmS4jXPA8v2k8CBqGu 7gMyi+djsS9SH7YXrWGtuk8UvZ5jFhkK1E14vwKdhopMcc7KuJe1yIAXTMcXv0LfnHBo mAfADONr9AbvtLKnm6m6e1ItDLvSVSlZOx20T8lyumHMJ/c5QbazOpiRUEpoRJwDDXDR spkQ== MIME-Version: 1.0 X-Received: by 10.180.187.136 with SMTP id fs8mr3746031wic.18.1372276846588; Wed, 26 Jun 2013 13:00:46 -0700 (PDT) Received: by 10.194.44.138 with HTTP; Wed, 26 Jun 2013 13:00:46 -0700 (PDT) In-Reply-To: <6E1C1EF7-3971-4FD4-8BCE-349ED5B0B598@vpnc.org> References: <6E1C1EF7-3971-4FD4-8BCE-349ED5B0B598@vpnc.org> Date: Wed, 26 Jun 2013 13:00:46 -0700 Message-ID: From: R S To: Paul Hoffman Content-Type: multipart/alternative; boundary=001a11c381ecf97a1104e014197f Cc: "json@ietf.org WG" Subject: Re: [Json] Minimal edit proposal, second round X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 26 Jun 2013 20:00:54 -0000 --001a11c381ecf97a1104e014197f Content-Type: text/plain; charset=ISO-8859-1 This looks good to me. +1. - Rob On Wed, Jun 26, 2013 at 8:47 AM, Paul Hoffman wrote: > > > The thread the last few days showed some confusion about what Rob's > proposal was. This new thread is an attempt to clarify so that we can see > if there is enough agreement to go down this path for the WG's first > document. This message is *not* to say "we will go that way instead of the > previous way", but instead to ask "does the WG want to go this way, given > more explicit information". > > First, the proposal is an alternative to the proposals so far in the WG, > not in addition to them. That is, the list of changes in the proposal would > be the *entire* set of changes; even the current document title remains the > same. If there is consensus to go this way, we drop all the current > consensus calls. We have made that clearer below. > > Second, it is quite clear that there is disagreement on what RFC 4627 > means with respect to the content of strings. Many people have forcefully > asserted what RFC 4627 meant, and yet many of them disagree. Thus, we think > it would be valuable to capture the fact that there is disagreement in a > factual manner. We have changed the proposed wording for this below. > > Third, the WG's charter is clear that we don't get to start work on > additional documents until we finish 4627-bis. Having said that, there > seems to be near-universal agreement that an implementation guidance > document is needed. (I don't want to use the IETF-centric term "best > practices" because we don't have consensus on which practice is best.) We > can assume that the document will be produced, even if it isn't in the > charter and we have not agreed to the content of that document. > > Fourth, we have incorporated the editorial changes from the thread. > > The proposal below, then, is meant to be a way to determine if the WG > wants to go down the "minimal edit" route, or return to what we were doing > before, making non-minimal additions to the document by WG consensus. > > Thoughts? > > --Matt Miller and Paul Hoffman > > > > Begin with http://tools.ietf.org/html/draft-ietf-json-rfc4627bis-02. > > Change Section 1.2, "Changes from RFC 4627", to read: > > This section lists all changes between this document and the text in > RFC 4627. > > - Applied erratum #607 from RFC 4627 to correctly align the artwork for > the definition of > "object". > > - Applied erratum #3607 from RFC 4627 by removing the security > consideration that begins "A JSON > text can be safely passed" and the JavaScript code that went with that > consideration. > > - Added Section 1.3, "Differences from the JSON Definition in ECMAScript". > > - Updated the [ECMA] reference, and changed the [UNICODE] references to be > non-version-specific. > > Add Section 1.3, "Differences Between This Document the JSON Definition in > ECMAScript" > > The following lists the known major differences between this document and > the definition of JSON > in Section 15.12 of [ECMA]. > > - ECMAScript implementations produce and consume primitive JSON values at > the root level of JSON > documents. > > - ECMAScript implementations can generate and consume all code points in > JSON strings, while there > is disagreement about whether this document prohibits some specific > code points in JSON strings. > > - When there are duplicate names within an object, ECMAScript JSON > parsers overwrite the value > corresponding to such names with the value that appears last in the > serialization. > > In Section 6, remove "A JSON text can be safely passed" and the JavaScript > code in the following > paragraph. > > In Section 9, change the title in the reference to [ECMA] to be to the > latest version with JSON: > > [ECMA] Ecma International, "ECMAScript Language Specification, 5.1 > Edition / June 2011", > < > http://www.ecma-international.org/publications/files/ecma-st/ECMA-262.pdf > >. > > In Section 9, change the reference to [UNICODE] to be be > non-version-specific: > > [UNICODE] The Unicode Consortium, "The Unicode Standard", < > http://www.unicode.org/versions/latest/>. > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > --001a11c381ecf97a1104e014197f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
This looks good to me. +1.

- Rob<= /div>


On= Wed, Jun 26, 2013 at 8:47 AM, Paul Hoffman <paul.hoffman@vpnc.org> wrote:
<chair hats on>

The thread the last few days showed some confusion about what Rob's pro= posal was. This new thread is an attempt to clarify so that we can see if t= here is enough agreement to go down this path for the WG's first docume= nt. This message is *not* to say "we will go that way instead of the p= revious way", but instead to ask "does the WG want to go this way= , given more explicit information".

First, the proposal is an alternative to the proposals so far in the WG, no= t in addition to them. That is, the list of changes in the proposal would b= e the *entire* set of changes; even the current document title remains the = same. If there is consensus to go this way, we drop all the current consens= us calls. We have made that clearer below.

Second, it is quite clear that there is disagreement on what RFC 4627 means= with respect to the content of strings. Many people have forcefully assert= ed what RFC 4627 meant, and yet many of them disagree. Thus, we think it wo= uld be valuable to capture the fact that there is disagreement in a factual= manner. We have changed the proposed wording for this below.

Third, the WG's charter is clear that we don't get to start work on= additional documents until we finish 4627-bis. Having said that, there see= ms to be near-universal agreement that an implementation guidance document = is needed. (I don't want to use the IETF-centric term "best practi= ces" because we don't have consensus on which practice is best.) W= e can assume that the document will be produced, even if it isn't in th= e charter and we have not agreed to the content of that document.

Fourth, we have incorporated the editorial changes from the thread.

The proposal below, then, is meant to be a way to determine if the WG wants= to go down the "minimal edit" route, or return to what we were d= oing before, making non-minimal additions to the document by WG consensus.<= br>
Thoughts?

--Matt Miller and Paul Hoffman



Begin with http://tools.ietf.org/html/draft-ietf-json-rfc4627bi= s-02.

Change Section 1.2, "Changes from RFC 4627", to read:

=A0This section lists all changes between this document and the text in
=A0RFC 4627.

=A0- Applied erratum #607 from RFC 4627 to correctly align the artwork for = the definition of
=A0 =A0"object".

=A0- Applied erratum #3607 from RFC 4627 by removing the security considera= tion that begins "A JSON
=A0 =A0text can be safely passed" and the JavaScript code that went wi= th that consideration.

=A0- Added Section 1.3, "Differences from the JSON Definition in ECMAS= cript".

=A0- Updated the [ECMA] reference, and changed the [UNICODE] references to = be
=A0 =A0non-version-specific.

Add Section 1.3, "Differences Between This Document the JSON Definitio= n in ECMAScript"

=A0The following lists the known major differences between this document an= d the definition of JSON
=A0in Section 15.12 of [ECMA].

=A0- ECMAScript implementations produce and consume primitive JSON values a= t the root level of JSON
=A0 =A0documents.

=A0- ECMAScript implementations can generate and consume all code points in= JSON strings, while there
=A0 =A0is disagreement about whether this document prohibits some specific = code points in JSON strings.

=A0- When there are duplicate names within an object, ECMAScript JSON parse= rs overwrite the value
=A0 =A0corresponding to such names with the value that appears last in the = serialization.

In Section 6, remove "A JSON text can be safely passed" and the J= avaScript code in the following
paragraph.

In Section 9, change the title in the reference to [ECMA] to be to the late= st version with JSON:

=A0[ECMA] =A0 =A0Ecma International, "ECMAScript Language Specificatio= n, 5.1 Edition / June 2011",
=A0 =A0 =A0 =A0 =A0 =A0<http://www.ecma-int= ernational.org/publications/files/ecma-st/ECMA-262.pdf>.

In Section 9, change the reference to [UNICODE] to be be non-version-specif= ic:

=A0[UNICODE] =A0The Unicode Consortium, "The Unicode Standard", &= lt;ht= tp://www.unicode.org/versions/latest/>.
_______________________________________________
json mailing list
json@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/json

--001a11c381ecf97a1104e014197f-- From nico@cryptonector.com Wed Jun 26 13:07:24 2013 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 C4D6B21F9F9F for ; Wed, 26 Jun 2013 13:07:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qJQUJvIeRHLy for ; Wed, 26 Jun 2013 13:07:19 -0700 (PDT) Received: from homiemail-a64.g.dreamhost.com (caiajhbdccah.dreamhost.com [208.97.132.207]) by ietfa.amsl.com (Postfix) with ESMTP id E026A21F9F76 for ; Wed, 26 Jun 2013 13:07:19 -0700 (PDT) Received: from homiemail-a64.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a64.g.dreamhost.com (Postfix) with ESMTP id 9E4CA438080 for ; Wed, 26 Jun 2013 13:07:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=Q4uz/IA/lXGIWLKEj+tC DTv5T3o=; b=DtNkWAwwhYsLwXm5uxEmGQzmpUY6p8S2w5U9PF/oTU8QvYG/eMjA cwI3r7SVVo3kuzjcujfrDkAzDYTWSzICDJyrwUW7beIwf1zpKnifhI3/ZXiGBLvF QmDx+QLJYtLMbXnt7I0FT+0p762XyABmNKB2e/eDUS8HpVHyJJGJtmI= Received: from mail-we0-f170.google.com (mail-we0-f170.google.com [74.125.82.170]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a64.g.dreamhost.com (Postfix) with ESMTPSA id 2DF23438072 for ; Wed, 26 Jun 2013 13:07:19 -0700 (PDT) Received: by mail-we0-f170.google.com with SMTP id w57so10793050wes.29 for ; Wed, 26 Jun 2013 13:07:16 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Tz/ce/1aTEhnOfkQtPEDQXIsSvyQJVoLK+w2SJ1xKec=; b=EUqpynbugQE27PzKIwYzC5z8DD1w53ScBZA5EvMKuzqO0wlRQga3UPeIJlkA2/TEod K+OJAnc37WcYWz6Hh1icAGlx++RczHcdTcRPPn+9UU3y2UfaeAAqx3ORxp6JMIptRnSE Pc0lfHlIBuCEQYY+LnomcZZ01DgauP1E85gXEMjefSCEwhOJ7TL14U4cG8oYSyzYI/Ha 3lyUyu/RaK+4kOWvItZEgfwNTo/uKHgNpguLE7xrzFSap9AtQl1E6jOHtnQJSqULvSnR XvMXYuYt0CjF0dMfxu+ANGuYcF6bjWUZnbLq4UxDvL4lXX/C4iE06eOG2MC2n3rOADo0 ejnw== MIME-Version: 1.0 X-Received: by 10.194.8.163 with SMTP id s3mr4017526wja.41.1372277236906; Wed, 26 Jun 2013 13:07:16 -0700 (PDT) Received: by 10.216.29.5 with HTTP; Wed, 26 Jun 2013 13:07:16 -0700 (PDT) Received: by 10.216.29.5 with HTTP; Wed, 26 Jun 2013 13:07:16 -0700 (PDT) In-Reply-To: References: <6E1C1EF7-3971-4FD4-8BCE-349ED5B0B598@vpnc.org> Date: Wed, 26 Jun 2013 15:07:16 -0500 Message-ID: From: Nico Williams To: Tim Bray Content-Type: multipart/alternative; boundary=047d7b5d253e3d441704e0143177 Cc: Paul Hoffman , "Joe Hildebrand \(jhildebr\)" , "json@ietf.org WG" Subject: Re: [Json] Minimal edit proposal, second round X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 26 Jun 2013 20:07:25 -0000 --047d7b5d253e3d441704e0143177 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Jun 26, 2013 2:15 PM, "Tim Bray" wrote: > > Yeah, but our charter clearly doesn=E2=80=99t let us fix JSON. What we n= eed is to do something like this, then re-charter to produce a doc that provides real guidance, so that, as someone in this thread pointed out, other Working Groups will have something to point to and won=E2=80=99t, as is cur= rently happening in Jose, have to write explicit language forbidding dupes, etc, into their drafts. So I=E2=80=99m in favor of doing this minimal point-out-the-problems work and moving on. -T We could also re-charter now (or conclude w/o producing any docs, as someone else pointed out). There's no dishonor in acknowledging that the current charter is unsatisfactory, if we so conclude. I'm for a minimal edit that describes the different interpretations of the old text that we have seen. We could also note that there is a subset of JSON that will (MUST) interop (no dup names, smallish integers, only Unicode character data and unassigned code points), though we can't rewrite that encoders restrict themselves to that subset. Then we can look at implementation guidance (e.g., parser options) and best practices. Nico -- --047d7b5d253e3d441704e0143177 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Jun 26, 2013 2:15 PM, "Tim Bray" <tbray@textuality.com> wrote:
>
> Yeah, but our charter clearly doesn=E2=80=99t let us fix JSON.=C2=A0 W= hat we need is to do something like this, then re-charter to produce a doc = that provides real guidance, so that, as someone in this thread pointed out= , other Working Groups will have something to point to and won=E2=80=99t, a= s is currently happening in Jose, have to write explicit language forbiddin= g dupes, etc, into their drafts.=C2=A0 So I=E2=80=99m in favor of doing thi= s minimal point-out-the-problems work and moving on. -T

We could also re-charter now (or conclude w/o producing any = docs, as someone else pointed out).=C2=A0 There's no dishonor in acknow= ledging that the current charter is unsatisfactory, if we so conclude.

I'm for a minimal edit that describes the different inte= rpretations of the old text that we have seen.=C2=A0 We could also note tha= t there is a subset of JSON that will (MUST) interop (no dup names, smallis= h integers, only Unicode character data and unassigned code points), though= we can't rewrite that encoders restrict themselves to that subset.=C2= =A0 Then we can look at implementation guidance (e.g., parser options) and = best practices.

Nico
--

--047d7b5d253e3d441704e0143177-- From cabo@tzi.org Wed Jun 26 13:19:09 2013 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 60D1611E81DD for ; Wed, 26 Jun 2013 13:19:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7S3rWLwZ0PmL for ; Wed, 26 Jun 2013 13:19:03 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 44E7F11E8144 for ; Wed, 26 Jun 2013 13:19:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r5QKIuYZ009526 for ; Wed, 26 Jun 2013 22:18:56 +0200 (CEST) Received: from pptp-218-1.informatik.uni-bremen.de (pptp-218-1.informatik.uni-bremen.de [134.102.218.240]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id AA6A0324D; Wed, 26 Jun 2013 22:18:55 +0200 (CEST) From: Carsten Bormann Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Wed, 26 Jun 2013 22:18:54 +0200 To: "json@ietf.org WG" Message-Id: <6E98097C-59A2-428A-BF31-E6A1F9114747@tzi.org> Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) Subject: [Json] Actual interoperability issues X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 26 Jun 2013 20:19:09 -0000 =46rom the 1093 JSON messages in my mailbox, I find discussion of the following issues that appear to be relevant for interoperability: Group 1: Overall format of JSON documents (This group is about the sequence of characters that make up the actual JSON document, i.e. native Unicode characters/code points, not escape sequences etc.) 1.1) Ill-formed Unicode in JSON documents (Unpaired surrogates in UTF-16, CESU-8 surrogates, etc.) 1.2) Use of non-characters (Unicode term) in a JSON document (Is that an actual interoperability issue? I haven't seen it.) 1.3) Use of non-yet-assigned characters in a JSON document (Is that an actual interoperability issue? I haven't seen it.) 1.4) Usage of LS/PS (U+2028/U+2029) in JSON documents (I.e., native LS/PS; escapes are not a problem. This hurts newer JavaScript implementations if they still want to eval things. Probably easy to solve: this just needs to be discouraged) 1.5) BOMs in JSON documents 1.6) usage of UTF-16 and UTF-32 based character encoding schemes (and which ones?) for JSON documents 1.7) non-BMP characters in JSON documents (I have heard about implementations that have trouble with this, maybe because of assuming CESU-8 instead of UTF-8, but have never been able to pin them down. May be a non-issue, more study required.) 1.8) Combining characters after markup (Another issue that was mentioned, but for which I'm not aware of an actual interoperability problem.) Group 2: Syntax, overall data model 2.1) Top-level data items beyond arrays and maps (JSON "objects") (and the potential interaction with 1.5/1.6; with streaming; with detection of truncation) Group 3: Interpretation of data in JSON documents 3.1) Ill-formed Unicode constructed from escape sequences in strings (This is about escape sequences that generate unpaired surrogates.) 3.2) Construction of non-characters (Unicode term) from escape sequences = in strings (Is that an actual interoperability issue? I haven't seen it.) 3.3) Construction of non-yet-assigned characters from escape sequences = in strings (Is that an actual interoperability issue? I haven't seen it.) 3.4) Non-unique ("duplicate") keys in maps (JSON "objects") 3.5) Equivalence of native and (variants of) escaped representations of characters in map keys (Is that an actual interoperability issue? I haven't seen it.) 3.6) Equivalence of canonical-equivalent (Unicode term) characters in map keys (Is that an actual interoperability issue? I haven't seen it.) 3.7) Assumptions on the semantics of ordering of entries in maps (also in conjunction with 3.4) 3.8) Assumptions about (range and) precision of numbers (E.g., the twitter ID issue) 3.9) Handling of NaNs in numbers (I'm not quite sure what the issue was, but it was mentioned) So much for the content of 1093 messages. (Most of these are almost trivial to resolve/clarify from what we already know, and should be, so each spec referencing JSON doesn't need to supply its own 18 answers to these questions.) Am I missing any issues? (For now, as long as the issue is about interoperability, I don't care about "standard" vs "implementation guide" issues; we can sort that one out later, including whether we want to address the issue at all.) Gr=FC=DFe, Carsten PS.: There also was a feature request, for a "profile" parameter of the media type. Any feature requests that I'm missing? From mamille2@cisco.com Wed Jun 26 15:18:42 2013 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 520B111E8111 for ; Wed, 26 Jun 2013 15:18:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dxD9IYf8sxm1 for ; Wed, 26 Jun 2013 15:18:36 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 8F83911E8135 for ; Wed, 26 Jun 2013 15:18:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8155; q=dns/txt; s=iport; t=1372285116; x=1373494716; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=KhJFriYXP1ULFEGFO42R2kb4v9qLjKxrFs+teuBUmuk=; b=YmImVtZl5exN9EypKc7czEBpe0ECUSi5np3AOvnQvp91ufyy1UOzk+oy yfx7FE6CVzvRk5rYmN0bvDiz6mpOK2dWauO+mY540WrKeyF7xw1jVmwoo EQKGasT7mZ63SgN3OXng+iZ/3nzZuILOGcez1wxmMdL/1H0Bg0BkdzCUf w=; X-Files: smime.p7s : 4136 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFAPxny1GtJXG+/2dsb2JhbABbgwl6vwSBBBZ0giMBAQEDAXkFCwIBCBgKJAIwJQIEDgUIBhGHaQa6DY8aMQeDAmEDkASBLZdZgxGCKA X-IronPort-AV: E=Sophos;i="4.87,947,1363132800"; d="p7s'?scan'208";a="227692702" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-1.cisco.com with ESMTP; 26 Jun 2013 22:18:35 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r5QMIZZb024941 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 26 Jun 2013 22:18:35 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.24]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.02.0318.004; Wed, 26 Jun 2013 17:18:35 -0500 From: "Matt Miller (mamille2)" To: Nico Williams Thread-Topic: [Json] Minimal edit proposal, second round Thread-Index: AQHOcoR/I3t3Vu8HoUGeTLRKnWH3U5lInzMAgAAB9QCAAB8iAIAAJK6A Date: Wed, 26 Jun 2013 22:18:34 +0000 Message-ID: References: <6E1C1EF7-3971-4FD4-8BCE-349ED5B0B598@vpnc.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.129.24.90] Content-Type: multipart/signed; boundary="Apple-Mail=_B48B841E-9AA3-438C-A110-55CDB87F5000"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Cc: Tim Bray , Paul Hoffman , "Joe Hildebrand \(jhildebr\)" , "json@ietf.org WG" Subject: Re: [Json] Minimal edit proposal, second round X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 26 Jun 2013 22:18:42 -0000 --Apple-Mail=_B48B841E-9AA3-438C-A110-55CDB87F5000 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Jun 26, 2013, at 2:07 PM, Nico Williams = wrote: > On Jun 26, 2013 2:15 PM, "Tim Bray" wrote: >>=20 >> Yeah, but our charter clearly doesn=92t let us fix JSON. What we = need is > to do something like this, then re-charter to produce a doc that = provides > real guidance, so that, as someone in this thread pointed out, other > Working Groups will have something to point to and won=92t, as is = currently > happening in Jose, have to write explicit language forbidding dupes, = etc, > into their drafts. So I=92m in favor of doing this minimal > point-out-the-problems work and moving on. -T >=20 > We could also re-charter now (or conclude w/o producing any docs, as > someone else pointed out). There's no dishonor in acknowledging that = the > current charter is unsatisfactory, if we so conclude. >=20 > I'm for a minimal edit that describes the different interpretations of = the > old text that we have seen. We could also note that there is a subset = of > JSON that will (MUST) interop (no dup names, smallish integers, only > Unicode character data and unassigned code points), though we can't = rewrite > that encoders restrict themselves to that subset. Then we can look at > implementation guidance (e.g., parser options) and best practices. >=20 > Nico /me doffs hat I think the minimal edit useful as a way to move forward: it notes the = original had warts, that "properly" (for varying definitions of = "properly") correcting those warts could cause worse conditions, but = that there are a plethora of implementations that coexist with very few = reported problems. I think the edits do bring to the surface = information that has been unspoken for a long time. I could easily live = with it, and leave the definitive "this is what JSON software ought to = do from this point forward" for a separate document. - m&m Matt Miller < mamille2@cisco.com > Cisco Systems, Inc. - m&m Matt Miller < mamille2@cisco.com > Cisco Systems, Inc. --Apple-Mail=_B48B841E-9AA3-438C-A110-55CDB87F5000 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMezCCBjQw ggQcoAMCAQICAR4wDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDE1NVoX DTE3MTAyNDIxMDE1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMcJg8zOLdgasSmkLhOrlr6KMoOMpohBllVHrdRvEg/q6r8jR+EK 75xCGhR8ToREoqe7zM9/UnC6TS2y9UKTpT1v7RSMzR0t6ndl0TWBuUr/UXBhPk+Kmy7bI4yW4urC +y7P3/1/X7U8ocb8VpH/Clt+4iq7nirMcNh6qJR+xjOhV+VHzQMALuGYn5KZmc1NbJQYclsGkDxD z2UbFqE2+6vIZoL+jb9x4Pa5gNf1TwSDkOkikZB1xtB4ZqtXThaABSONdfmv/Z1pua3FYxnCFmdr /+N2JLKutIxMYqQOJebr/f/h5t95m4JgrM3Y/w7YX9d7YAL9jvN4SydHsU6n65cCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRTcu2SnODaywFc fH6WNU7y1LhRgjAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBAAqDCH14qywG XLhjjF6uHLkjd02hcdh9hrw+VUsv+q1eeQWB21jWj3kJ96AUlPCoEGZ/ynJNScWy6QMVQjbbMXlt UfO4n4bGGdKo3awPWp61tjAFgraLJgDk+DsSvUD6EowjMTNx25GQgyYJ5RPIzKKR9tQW8gGK+2+R HxkUCTbYFnL6kl8Ch507rUdPPipJ9CgJFws3kDS3gOS5WFMxcjO5DwKfKSETEPrHh7p5shuuNktv sv6hxHTLhiMKX893gxdT3XLS9OKmCv87vkINQcNEcIIoFWbP9HORz9v3vQwR4e3ksLc2JZOAFK+s sS5XMEoznzpihEP0PLc4dCBYjbvSD7kxgDwZ+Aj8Q9PkbvE9sIPP7ON0fz095HdThKjiVJe6vofq +n6b1NBc8XdrQvBmunwxD5nvtTW4vtN6VY7mUCmxsCieuoBJ9OlqmsVWQvifIYf40dJPZkk9YgGT zWLpXDSfLSplbY2LL9C9U0ptvjcDjefLTvqSFc7tw1sEhF0n/qpA2r0GpvkLRDmcSwVyPvmjFBGq Up/pNy8ZuPGQmHwFi2/14+xeSUDG2bwnsYJQG2EdJCB6luQ57GEnTA/yKZSTKI8dDQa8Sd3zfXb1 9mOgSF0bBdXbuKhEpuP9wirslFe6fQ1t5j5R0xi72MZ8ikMu1RQZKCyDbMwazlHiMIIGPzCCBSeg AwIBAgIDBoRIMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcN MTMwNDMwMjE1NDQyWhcNMTQwNTAyMDUzOTA0WjBbMRkwFwYDVQQNExBiN2F6NndOY0t0R3JtMEpF MRswGQYDVQQDDBJtYW1pbGxlMkBjaXNjby5jb20xITAfBgkqhkiG9w0BCQEWEm1hbWlsbGUyQGNp c2NvLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJbKBMsG+9UFTx9uq/bhhXgu vJvO8z7cwKaqqwZhVf5z/kHFyCNijtmTOE+YXjA8mWR4aoBwB5SvGypI/cJUofJ+AlBTC4g+RMx/ K0Ab4/jQqTQz9CDzMOB+Wm+rt8ZJ7A8ZzOJmNDAsf/VvB8l2A1SQz1UsAixgH16NTr8SlblAXEKk 4hwpCudUiNjjQokqJ0H686UBKVorcZSgXaza8XMqGtJF/8mNhR9GQYi7Xht1ky+9LFOrto2daZto KJRwMeVusVdHUeKEQSu7jztw8HchH3KEb7Q+r5X+hhDZoddfKE8d5eyPuhiZdrzv7OlNZ0fSLdx7 3AE3nx9/R5YlXucCAwEAAaOCAtgwggLUMAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQW MBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQUxGd+/qrdVudHrIKkw5xOMY7eaLUwHwYD VR0jBBgwFoAUU3Ltkpzg2ssBXHx+ljVO8tS4UYIwHQYDVR0RBBYwFIESbWFtaWxsZTJAY2lzY28u Y29tMIIBTAYDVR0gBIIBQzCCAT8wggE7BgsrBgEEAYG1NwECAzCCASowLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0 Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBp c3N1ZWQgYWNjb3JkaW5nIHRvIHRoZSBDbGFzcyAxIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9m IHRoZSBTdGFydENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBw dXJwb3NlIGluIGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMDYG A1UdHwQvMC0wK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUxLWNybC5jcmwwgY4G CCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIv Y2xhc3MxL2NsaWVudC9jYTBCBggrBgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2Vy dHMvc3ViLmNsYXNzMS5jbGllbnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRz c2wuY29tLzANBgkqhkiG9w0BAQUFAAOCAQEAlDhXbGEI7lbqUcu5r2JHZaMsbRZda/99ZqODzWGX 0llou9jGccsAWDPPwRRe2+ROpXfH4cuJZElTcLDeZSp/qpXKhjYieFSX8+Ml9sKEj5UOSqQLyoLk PtrIJV12Jk3nuG2Jc0UeEnGwK/aqtzy7+bfEVI0ziyVM2gChHh0RH74KyiwYWknbOTRIkZcz/ulE DVFQp63uj6wfmDNvAUHBAdhKVqA1S/rfP1KcDZpf1NfvwXJibiqTRA6K1EOxTJOP41n/XdvHqHXL RWL2xrOUI9/URANr/ok3OrsuZEMFnAAGefS1bWS/hFtUGVkHGiKEBbyDW7da2ULXbuC7umrQnzGC A28wggNrAgEBMIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkG A1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwaESDAJBgUrDgMCGgUA oIIBrzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMzA2MjYyMjE4 MzRaMCMGCSqGSIb3DQEJBDEWBBQbjjOxPMACt4puGVWIJavjYtrPbzCBpQYJKwYBBAGCNxAEMYGX MIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3Mg MSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwaESDCBpwYLKoZIhvcNAQkQAgsxgZeg gZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1 cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAx IFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDBoRIMA0GCSqGSIb3DQEBAQUABIIBAC5h 1AaFUEtn3mxJ4QTyliGiR5fdQT8INfZuK/1Zg557tA8VawZetNYb+qzn3wJscLR56TTUQFWRVksQ HHcPf1Utf2j+Ydj1PJW5ANRF6+2em2sAwZLLwoYz0JPbom4G3IiZNRAeMpvNVSNZnXTU9CmKvQn1 NSVYbnRbcgKM0C92D7uYcIutRdc5i1fwlfLatRkDSJRLR4NhCA6BXTGFGmgQeRyiFyDKxpRqU4rk +zXjVjMeSYpha4+V6uj5s/M2Jld7M7MJY2XzvciTko5o6J3sY0U9S+HtWDSKh4BGLlKiSoKiH8un Q3OJklbcmpv3FigVvstDr5Z/ITatARhQLfEAAAAAAAA= --Apple-Mail=_B48B841E-9AA3-438C-A110-55CDB87F5000-- From cowan@ccil.org Wed Jun 26 17:30:07 2013 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 8085211E8179 for ; Wed, 26 Jun 2013 17:30:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HwaYqvnFFJgw for ; Wed, 26 Jun 2013 17:30:03 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id 11FA011E8178 for ; Wed, 26 Jun 2013 17:30:02 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1Us064-0005Bx-LZ; Wed, 26 Jun 2013 20:30:00 -0400 Date: Wed, 26 Jun 2013 20:30:00 -0400 From: John Cowan To: Paul Hoffman Message-ID: <20130627003000.GE3742@mercury.ccil.org> References: <6E1C1EF7-3971-4FD4-8BCE-349ED5B0B598@vpnc.org> <20130626182305.GA3742@mercury.ccil.org> <949037D0-B1EC-4114-BA9A-5A820119872B@vpnc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <949037D0-B1EC-4114-BA9A-5A820119872B@vpnc.org> User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Cc: "json@ietf.org WG" Subject: Re: [Json] Minimal edit proposal, second round X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 27 Jun 2013 00:30:07 -0000 Paul Hoffman scripsit: > We currently have an ambiguous document *that everyone has used for > six years* as the de facto standard. No one noticed this ambiguity > (at least in public) until *after* we started this WG. What do you call "public"? Mr. Crockford and I were discussing this for the second time more than two years ago on the JSON Yahoo list: see et seqq. > We don't have to dissolve in order to recharter. In fact, we are better > off if we don't. Ah, good. -- [W]hen I wrote it I was more than a little John Cowan febrile with foodpoisoning from an antique carrot cowan@ccil.org that I foolishly ate out of an illjudged faith http://ccil.org/~cowan in the benignancy of vegetables. --And Rosta From jsontest@yahoo.com Wed Jun 26 17:31:28 2013 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 70C6E21F8EFE for ; Wed, 26 Jun 2013 17:31:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.244 X-Spam-Level: * X-Spam-Status: No, score=1.244 tagged_above=-999 required=5 tests=[AWL=0.587, BAYES_20=-0.74, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 92jK+NYaHUoU for ; Wed, 26 Jun 2013 17:31:23 -0700 (PDT) Received: from nm50-vm6.bullet.mail.bf1.yahoo.com (nm50-vm6.bullet.mail.bf1.yahoo.com [216.109.115.237]) by ietfa.amsl.com (Postfix) with ESMTP id 2D95521F8DDD for ; Wed, 26 Jun 2013 17:31:23 -0700 (PDT) Received: from [98.139.212.151] by nm50.bullet.mail.bf1.yahoo.com with NNFMP; 27 Jun 2013 00:31:22 -0000 Received: from [68.142.230.69] by tm8.bullet.mail.bf1.yahoo.com with NNFMP; 27 Jun 2013 00:31:22 -0000 Received: from [127.0.0.1] by smtp226.mail.bf1.yahoo.com with NNFMP; 27 Jun 2013 00:31:22 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1372293082; bh=UksAjff6A5+DHTIfW8H1S/VaXFQEJfuOLlADfQ8BT4s=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:References:In-Reply-To:Mime-Version:Content-Type:Content-Transfer-Encoding:Message-Id:Cc:X-Mailer:From:Subject:Date:To; b=So0OanyNaS0Ophcjbw8TuQ6rmtE2Nm+UYSdJlpgbJH4g3zUdB+E0P58bz+JmGy8pjY1Oc7IVBThk8/GYleIWcYSVwXsGq2YntEHcdbJU++y/qIqHR9nEePxdFwYwhFh9WVfc24QIBUs/FOxXL2ev+s7NOv/wBkLmyWPG5p6czCI= X-Yahoo-Newman-Id: 156937.57457.bm@smtp226.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: ohHBUSsVM1lOQxywaKZRNwOL7811hYnRgxEFBW9y0zoWmg5 kcbzXMeSDgfrpoiFASucakWhkCxDwD.hdJTEW44gv1wh76ngLwuEAvMizHWd GO6Dj74hPEaFTgngEFNKx2Gp6AQ71D7p8mdJprg.j6ce7Uo1PebgPSTwJ70X nvSV99SgWhi4HsWZ5teqhv8oBcqSgGKegjoUSkvLVE165Lwsk0i3t142UD0B CsnrLs2s5ch5Vy28xsRYfj_LQ6PX4PeQF7j1QWcY44SLdSygr6wiNaFC5phR QfoVuswme9C_E7s1hlTvGQw6zWj4SO5ga0JeIaYDMMBoAFuKmnkcw7eh_KJ7 ki8iipnbFi5pVUbmdc8V3C608pglpAubd1vBDelS8O3Hfd6W0YQrk.mkcZmK ONuIRxIvWo.jP5vtdr95hqZ_0epfCR1ZzM4JOinOx9PWf6fDZ4.SZTVtG5id L7RImnXVxQS3TUu6tEyRK6829HYCZL3RCTbSMy06PnNhVzTXdjgCy0GMcSu6 j2gOLhL91H2HoEAAe1Vx6gKpAO5kJ4MVl26XtoIaIO2mzHbFxcoJlT41A6Hk IEBrWc3ad2Ju6hc91hQMeRCLlPKdfainrs3xmtyZKWnMEj6JJC0DJMmOig5Q DhMo- X-Yahoo-SMTP: indQcmSswBC8IKsm6t4aCAPskK3T X-Rocket-Received: from [192.168.0.102] (jsontest@76.29.100.42 with ) by smtp226.mail.bf1.yahoo.com with SMTP; 27 Jun 2013 00:31:22 +0000 UTC References: <6E98097C-59A2-428A-BF31-E6A1F9114747@tzi.org> In-Reply-To: <6E98097C-59A2-428A-BF31-E6A1F9114747@tzi.org> Mime-Version: 1.0 (1.0) Content-Type: multipart/alternative; boundary=Apple-Mail-EC7F0B7D-5F2F-4B6C-8805-35E70C160E8C Content-Transfer-Encoding: 7bit Message-Id: <50D04824-E228-4105-BBD6-38192998E3E9@yahoo.com> X-Mailer: iPod Mail (9B206) From: Vinny A Date: Wed, 26 Jun 2013 19:31:19 -0500 To: Carsten Bormann Cc: "json@ietf.org WG" Subject: Re: [Json] Actual interoperability issues X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 27 Jun 2013 00:31:28 -0000 --Apple-Mail-EC7F0B7D-5F2F-4B6C-8805-35E70C160E8C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jun 26, 2013, at 3:18 PM, Carsten Bormann wrote: > Am I missing any issues? >=20 > PS.: There also was a feature request, for a "profile" parameter of > the media type. Any feature requests that I'm missing? I saw a feature request for comments a few weeks ago, here's the email: =20= http://www.ietf.org/mail-archive/web/json/current/msg00605.html . Otherwis= e I'm +1 on your list. ----------------- Vinny www.jsontest.com --Apple-Mail-EC7F0B7D-5F2F-4B6C-8805-35E70C160E8C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Jun 26, 2013= , at 3:18 PM, Carsten Bormann <cabo@tzi.o= rg> wrote:
Am I missing any= issues?

<= /blockquote>
PS.: There also was a feature re= quest, for a "profile" parameter of
the media type.  Any feature requests that I'm missing?

I saw a feature request for comm= ents a few weeks ago, here's the email:   
<= span class=3D"Apple-style-span" style=3D"font-family: 'times new roman', 'ne= w york', times, serif; font-size: 16px; -webkit-tap-highlight-color: rgba(26= , 26, 26, 0.292969); -webkit-composition-fill-color: rgba(175, 192, 227, 0.2= 30469); -webkit-composition-frame-color: rgba(77, 128, 180, 0.230469); ">http://www.ietf.org/mail-archive/web/json/cu= rrent/msg00605.html   . Otherwise I'm +1 on your l= ist.

-----------------
Vinn= y
www.jsontest.com

= --Apple-Mail-EC7F0B7D-5F2F-4B6C-8805-35E70C160E8C-- From lear@cisco.com Wed Jun 26 23:17:58 2013 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 1C55821F9C4D for ; Wed, 26 Jun 2013 23:17:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.803 X-Spam-Level: X-Spam-Status: No, score=-109.803 tagged_above=-999 required=5 tests=[AWL=0.796, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yo7OlWhpFv3R for ; Wed, 26 Jun 2013 23:17:53 -0700 (PDT) Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com [144.254.224.147]) by ietfa.amsl.com (Postfix) with ESMTP id BABEA21F9C4B for ; Wed, 26 Jun 2013 23:17:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=763; q=dns/txt; s=iport; t=1372313872; x=1373523472; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=rfl+XYuKNLIAdX/cbEDi7HuTrX8JDDwQOk38xD/gS2E=; b=ZeKgjPpngZGc7KP09ic/Oex4WiQjPaPlHgbDxhVXz2SkxxPTDqDBlKn6 hh4B1CokfbXMljdbkg9dfxgr7uVRkYhtyETw5dept4OmVJ+qRctdubATu iUeOn7XqZxzCCBfCPVmIf3FLzCIQKFE6j1OP2idsapRtB/dMQxVNcMDU0 0=; X-IronPort-AV: E=Sophos;i="4.87,950,1363132800"; d="scan'208";a="15025064" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-4.cisco.com with ESMTP; 27 Jun 2013 06:17:51 +0000 Received: from mctiny.local ([10.61.160.226]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r5R6Hmeh018028 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 27 Jun 2013 06:17:49 GMT Message-ID: <51CBD90C.6020403@cisco.com> Date: Thu, 27 Jun 2013 08:17:48 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: "Matt Miller (mamille2)" References: <6E1C1EF7-3971-4FD4-8BCE-349ED5B0B598@vpnc.org> In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Nico Williams , Tim Bray , Paul Hoffman , "Joe Hildebrand \(jhildebr\)" , "json@ietf.org WG" Subject: Re: [Json] Minimal edit proposal, second round X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 27 Jun 2013 06:17:58 -0000 Matt, On 6/27/13 12:18 AM, Matt Miller (mamille2) wrote: > I think the minimal edit useful as a way to move forward: it notes the > original had warts, that "properly" (for varying definitions of > "properly") correcting those warts could cause worse conditions, but > that there are a plethora of implementations that coexist with very > few reported problems. I think the edits do bring to the surface > information that has been unspoken for a long time. I could easily > live with it, and leave the definitive "this is what JSON software > ought to do from this point forward" for a separate document. - I think you have to go one step further. You have to explain how to avoid the warts. We have normative language for that purpose. Eliot From James.H.Manger@team.telstra.com Thu Jun 27 19:34:49 2013 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 BBB8621F9B66 for ; Thu, 27 Jun 2013 19:34:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.901 X-Spam-Level: X-Spam-Status: No, score=-0.901 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id izS1UgslPlnD for ; Thu, 27 Jun 2013 19:34:45 -0700 (PDT) Received: from ipxcvo.tcif.telstra.com.au (ipxcvo.tcif.telstra.com.au [203.35.135.208]) by ietfa.amsl.com (Postfix) with ESMTP id 29FAE21F9B9E for ; Thu, 27 Jun 2013 19:34:41 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.87,955,1363093200"; d="scan'208";a="144156682" Received: from unknown (HELO ipcdvi.tcif.telstra.com.au) ([10.97.217.212]) by ipocvi.tcif.telstra.com.au with ESMTP; 28 Jun 2013 12:34:34 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,7119"; a="140618377" Received: from wsmsg3754.srv.dir.telstra.com ([172.49.40.198]) by ipcdvi.tcif.telstra.com.au with ESMTP; 28 Jun 2013 12:34:34 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3754.srv.dir.telstra.com ([172.49.40.198]) with mapi; Fri, 28 Jun 2013 12:34:33 +1000 From: "Manger, James H" To: Paul Hoffman , "json@ietf.org WG" Date: Fri, 28 Jun 2013 12:34:32 +1000 Thread-Topic: [Json] Minimal edit proposal, second round Thread-Index: Ac5yhHn+EM0p/952TnuwW34Tj9xnmQBIdiSQ Message-ID: <255B9BB34FB7D647A506DC292726F6E1151BEDE5ED@WSMSG3153V.srv.dir.telstra.com> References: <6E1C1EF7-3971-4FD4-8BCE-349ED5B0B598@vpnc.org> In-Reply-To: <6E1C1EF7-3971-4FD4-8BCE-349ED5B0B598@vpnc.org> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [Json] Minimal edit proposal, second round X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 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, 28 Jun 2013 02:34:49 -0000 LTENClRvbyBtaW5pbWFsIHRvIHByb3ZpZGUgYW55IHZhbHVlIChhbmQgY2VydGFpbmx5IG5vdCBl bm91Z2ggdmFsdWUgdG8gb3ZlcmNvbWUgdGhlIHBhaW4gb2YgaW50cm9kdWNpbmcgYSBzZWNvbmQg UkZDIG51bWJlciBmb3IgcmVmZXJyaW5nIHRvIEpTT04pLg0KDQpQLlMuIFN1cmVseSB3ZSBkb24n dCBuZWVkIHRvIGV4cGxpY2l0bHkgbWVudGlvbiB0aGF0IGFuIHVwZGF0ZSBmaXhlcyBlZGl0b3Jp YWwgZXJyYXRhICgjNjA3KS4NCg0KLS0NCkphbWVzIE1hbmdlcg0KDQo+IC0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQo+IEZyb206IGpzb24tYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmpzb24t Ym91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mDQo+IFBhdWwgSG9mZm1hbg0KPiBTZW50OiBU aHVyc2RheSwgMjcgSnVuZSAyMDEzIDE6NDcgQU0NCi4uLg0KPiANCj4gQmVnaW4gd2l0aCBodHRw Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWpzb24tcmZjNDYyN2Jpcy0wMi4NCj4g DQo+IENoYW5nZSBTZWN0aW9uIDEuMiwgIkNoYW5nZXMgZnJvbSBSRkMgNDYyNyIsIHRvIHJlYWQ6 DQo+IA0KPiAgVGhpcyBzZWN0aW9uIGxpc3RzIGFsbCBjaGFuZ2VzIGJldHdlZW4gdGhpcyBkb2N1 bWVudCBhbmQgdGhlIHRleHQgaW4NCj4gUkZDIDQ2MjcuDQo+IA0KPiAgLSBBcHBsaWVkIGVycmF0 dW0gIzYwNyBmcm9tIFJGQyA0NjI3IHRvIGNvcnJlY3RseSBhbGlnbiB0aGUgYXJ0d29yaw0KPiBm b3IgdGhlIGRlZmluaXRpb24gb2YNCj4gICAgIm9iamVjdCIuDQo+IA0KPiAgLSBBcHBsaWVkIGVy cmF0dW0gIzM2MDcgZnJvbSBSRkMgNDYyNyBieSByZW1vdmluZyB0aGUgc2VjdXJpdHkNCj4gY29u c2lkZXJhdGlvbiB0aGF0IGJlZ2lucyAiQSBKU09ODQo+ICAgIHRleHQgY2FuIGJlIHNhZmVseSBw YXNzZWQiIGFuZCB0aGUgSmF2YVNjcmlwdCBjb2RlIHRoYXQgd2VudCB3aXRoDQo+IHRoYXQgY29u c2lkZXJhdGlvbi4NCj4gDQo+ICAtIEFkZGVkIFNlY3Rpb24gMS4zLCAiRGlmZmVyZW5jZXMgZnJv bSB0aGUgSlNPTiBEZWZpbml0aW9uIGluDQo+IEVDTUFTY3JpcHQiLg0KPiANCj4gIC0gVXBkYXRl ZCB0aGUgW0VDTUFdIHJlZmVyZW5jZSwgYW5kIGNoYW5nZWQgdGhlIFtVTklDT0RFXSByZWZlcmVu Y2VzDQo+IHRvIGJlDQo+ICAgIG5vbi12ZXJzaW9uLXNwZWNpZmljLg0KPiANCj4gQWRkIFNlY3Rp b24gMS4zLCAiRGlmZmVyZW5jZXMgQmV0d2VlbiBUaGlzIERvY3VtZW50IHRoZSBKU09OIERlZmlu aXRpb24NCj4gaW4gRUNNQVNjcmlwdCINCj4gDQo+ICBUaGUgZm9sbG93aW5nIGxpc3RzIHRoZSBr bm93biBtYWpvciBkaWZmZXJlbmNlcyBiZXR3ZWVuIHRoaXMgZG9jdW1lbnQNCj4gYW5kIHRoZSBk ZWZpbml0aW9uIG9mIEpTT04gIGluIFNlY3Rpb24gMTUuMTIgb2YgW0VDTUFdLg0KPiANCj4gIC0g RUNNQVNjcmlwdCBpbXBsZW1lbnRhdGlvbnMgcHJvZHVjZSBhbmQgY29uc3VtZSBwcmltaXRpdmUg SlNPTiB2YWx1ZXMNCj4gYXQgdGhlIHJvb3QgbGV2ZWwgb2YgSlNPTg0KPiAgICBkb2N1bWVudHMu DQo+IA0KPiAgLSBFQ01BU2NyaXB0IGltcGxlbWVudGF0aW9ucyBjYW4gZ2VuZXJhdGUgYW5kIGNv bnN1bWUgYWxsIGNvZGUgcG9pbnRzDQo+IGluIEpTT04gc3RyaW5ncywgd2hpbGUgdGhlcmUNCj4g ICAgaXMgZGlzYWdyZWVtZW50IGFib3V0IHdoZXRoZXIgdGhpcyBkb2N1bWVudCBwcm9oaWJpdHMg c29tZSBzcGVjaWZpYw0KPiBjb2RlIHBvaW50cyBpbiBKU09OIHN0cmluZ3MuDQo+IA0KPiAgLSBX aGVuIHRoZXJlIGFyZSBkdXBsaWNhdGUgbmFtZXMgd2l0aGluIGFuIG9iamVjdCwgRUNNQVNjcmlw dCBKU09ODQo+IHBhcnNlcnMgb3ZlcndyaXRlIHRoZSB2YWx1ZQ0KPiAgICBjb3JyZXNwb25kaW5n IHRvIHN1Y2ggbmFtZXMgd2l0aCB0aGUgdmFsdWUgdGhhdCBhcHBlYXJzIGxhc3QgaW4gdGhlDQo+ IHNlcmlhbGl6YXRpb24uDQo+IA0KPiBJbiBTZWN0aW9uIDYsIHJlbW92ZSAiQSBKU09OIHRleHQg Y2FuIGJlIHNhZmVseSBwYXNzZWQiIGFuZCB0aGUNCj4gSmF2YVNjcmlwdCBjb2RlIGluIHRoZSBm b2xsb3dpbmcgcGFyYWdyYXBoLg0KPiANCj4gSW4gU2VjdGlvbiA5LCBjaGFuZ2UgdGhlIHRpdGxl IGluIHRoZSByZWZlcmVuY2UgdG8gW0VDTUFdIHRvIGJlIHRvIHRoZQ0KPiBsYXRlc3QgdmVyc2lv biB3aXRoIEpTT046DQo+IA0KPiAgW0VDTUFdICAgIEVjbWEgSW50ZXJuYXRpb25hbCwgIkVDTUFT Y3JpcHQgTGFuZ3VhZ2UgU3BlY2lmaWNhdGlvbiwgNS4xDQo+IEVkaXRpb24gLyBKdW5lIDIwMTEi LA0KPiAgICAgICAgICAgIDxodHRwOi8vd3d3LmVjbWEtaW50ZXJuYXRpb25hbC5vcmcvcHVibGlj YXRpb25zL2ZpbGVzL2VjbWEtDQo+IHN0L0VDTUEtMjYyLnBkZj4uDQo+IA0KPiBJbiBTZWN0aW9u IDksIGNoYW5nZSB0aGUgcmVmZXJlbmNlIHRvIFtVTklDT0RFXSB0byBiZSBiZSBub24tdmVyc2lv bi0NCj4gc3BlY2lmaWM6DQo+IA0KPiAgW1VOSUNPREVdICBUaGUgVW5pY29kZSBDb25zb3J0aXVt LCAiVGhlIFVuaWNvZGUgU3RhbmRhcmQiLA0KPiA8aHR0cDovL3d3dy51bmljb2RlLm9yZy92ZXJz aW9ucy9sYXRlc3QvPi4NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCj4ganNvbiBtYWlsaW5nIGxpc3QNCj4ganNvbkBpZXRmLm9yZw0KPiBodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2pzb24NCg==