Re: [Json] Differences between RFC 4627 or the current ECMAScript specification
Tony Hansen <tony@att.com> Tue, 01 October 2013 13:33 UTC
Return-Path: <tony@att.com>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADEA211E81D4 for <json@ietfa.amsl.com>; Tue, 1 Oct 2013 06:33:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.021
X-Spam-Level:
X-Spam-Status: No, score=-104.021 tagged_above=-999 required=5 tests=[AWL=-2.023, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_45=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 nbPBG+zJvgNk for <json@ietfa.amsl.com>; Tue, 1 Oct 2013 06:33:11 -0700 (PDT)
Received: from flpi497.enaf.ffdc.sbc.com (egssmtp02.att.com [144.160.128.166]) by ietfa.amsl.com (Postfix) with ESMTP id 5825111E81CC for <json@ietf.org>; Tue, 1 Oct 2013 06:32:28 -0700 (PDT)
Received: from dns.maillennium.att.com (maillennium.att.com [135.25.114.99]) by egssmtp02.att.com (8.14.5/8.14.5) with ESMTP id r91DWR4f007472 for <json@ietf.org>; Tue, 1 Oct 2013 06:32:28 -0700
Received: from [135.70.176.59] (vpn-135-70-176-59.vpn.mwst.att.com[135.70.176.59]) by maillennium.att.com (mailgw1) with ESMTP id <20131001133225gw1009k10le> (Authid: tony); Tue, 1 Oct 2013 13:32:27 +0000
X-Originating-IP: [135.70.176.59]
Message-ID: <524ACEEB.7020609@att.com>
Date: Tue, 01 Oct 2013 09:32:27 -0400
From: Tony Hansen <tony@att.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: JSON WG <json@ietf.org>
References: <BF7E36B9C495A6468E8EC573603ED9411EF1BB0B@xmb-aln-x11.cisco.com> <CAChr6SyznBktmOLpT-EiZ5Nm_0jZ16M0tOo4aZ_jhSDb=HHDqg@mail.gmail.com> <23C96FBA-3419-4C97-A075-462F7443013A@vpnc.org> <CAChr6SxCpvGaZSGUDs+6vR4A5xv3NfzpRSkwsE_7c8ep+EX=YA@mail.gmail.com> <0FA0EFFF-2109-4D78-8723-2ECD990C0F82@vpnc.org> <CAChr6SwxgG=P2CYSfHkviG8+2vz6yK1fZQNMCvyWXrM1NgzLZQ@mail.gmail.com> <7058DBBD-9DCE-4A5C-B11D-5FC41A839407@vpnc.org> <CAChr6SwR+04Dcwy=WSf-zVgQ_Nwj_Ke5_dppuqk=CLz8BmdMiA@mail.gmail.com> <5245A56D.4080205@att.com> <CAChr6SziP6b0Zk63tmnvrmKq+Fgw7Kgcg7Z+=tCpDSLUa8YMYg@mail.gmail.com> <524761DD.7080102@att.com> <CAChr6Sya2fdZnzNde_jkSoTnHYzS1r_Eu03KssMa_+mr9FgFeg@mail.gmail.com>
In-Reply-To: <CAChr6Sya2fdZnzNde_jkSoTnHYzS1r_Eu03KssMa_+mr9FgFeg@mail.gmail.com>
X-Enigmail-Version: 1.5.2
Content-Type: multipart/alternative; boundary="------------000505020804030805030605"
Subject: Re: [Json] Differences between RFC 4627 or the current ECMAScript specification
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 01 Oct 2013 13:33:16 -0000
Thank you Rob, I appreciate that additional bit of information. In that case, you were indeed required to remove your private extension in order to be compliant with the ECMAScript specification. My point remains though: this was a case of removing a private extension you had previously allowed in your parser; it was not something that was done because the JSON language itself was different. This may seem like it's splitting hairs to you, but knowing where we're both coming from is important so that we understand each other better. Tony Hansen On 10/1/2013 12:38 AM, R S wrote: > my implementation was used for ECMAScript JSON.parse. > > - Rob > > On Saturday, September 28, 2013, Tony Hansen wrote: > > On 9/27/2013 12:34 PM, R S wrote: >> On Fri, Sep 27, 2013 at 8:34 AM, Tony Hansen <tony@att.com >> <javascript:_e({}, 'cvml', 'tony@att.com');>> wrote: >> >> RFC 4627 does not allow trailing commas in objects. Nor does >> 4627-bis. >> >> >> RFC 4627 allows parsers to accept non-JSON if they wish, while >> ECMAScript does not allow this. > > Your claim was that you had to change your parser of JSON to no > longer allow trailing commas because of converting to parsing > ECMAScript. I disagree with that assessment. > > You had added your own non-standard extension to JSON (accepting > trailing commas) to your parser. Note that ECMA's restrictions on > parsers are only on implementations of ECMAScript. ECMA does NOT > say that *your* parser may not continue to accept trailing commas, > except in the specific case of your parser being used in an > implementation of ECMAScript's JSON.parse() function. That is, if > your function is not used in an implementation of JSON.parse(), > ECMA places no restrictions on it; it certainly is not restricted > in the same ways that ECMAScript's JSON.parse() is restricted. You > chose to remove that non-standard extension, but only because you > chose to *follow* the same restrictions as ECMAScript's JSON.parse(). > > Did the JSON spec say you could add your own extension to your > parser? Yes it did. However, if someone wrote JSON using a > trailing comma, they're going into non-interoperable territory. > > ECMA also extends 4627-JSON by accepting additional top-level > primitives. ECMA's JSON.parse() is still a 4627-JSON-compliant > parser because it properly interprets 4627-JSON. However, someone > writing JSON using ECMA's extensions will only safely be > interoperable with someone using ECMAScript's JSON.parse() or > another parser that's been similarly extended. But they aren't > interoperable with the many other JSON libraries that haven't been > similarly extended. > > Tony Hansen > > > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json
- [Json] Working Group Last Call of draft-ietf-json… Matt Miller (mamille2)
- Re: [Json] Working Group Last Call of draft-ietf-… R S
- Re: [Json] Working Group Last Call of draft-ietf-… Tim Bray
- [Json] Differences between RFC 4627 or the curren… Paul Hoffman
- [Json] "suffer fatal runtime exceptions" Paul Hoffman
- [Json] -0.0 Paul Hoffman
- Re: [Json] -0.0 R S
- Re: [Json] Differences between RFC 4627 or the cu… Tim Bray
- Re: [Json] -0.0 Tim Bray
- Re: [Json] "suffer fatal runtime exceptions" R S
- Re: [Json] Differences between RFC 4627 or the cu… Eliot Lear
- Re: [Json] "suffer fatal runtime exceptions" Tim Bray
- Re: [Json] -0.0 R S
- Re: [Json] -0.0 Tim Bray
- Re: [Json] -0.0 John Cowan
- Re: [Json] -0.0 John Cowan
- Re: [Json] -0.0 R S
- Re: [Json] Differences between RFC 4627 or the cu… R S
- Re: [Json] Working Group Last Call of draft-ietf-… Mark Nottingham
- Re: [Json] Working Group Last Call of draft-ietf-… Peter Saint-Andre
- Re: [Json] Working Group Last Call of draft-ietf-… Tim Bray
- Re: [Json] Differences between RFC 4627 or the cu… Paul Hoffman
- [Json] Authorship Paul Hoffman
- [Json] Obsoletes RFC 4627 Paul Hoffman
- [Json] Section 1.3, "Changes from RFC 4627" Paul Hoffman
- Re: [Json] Differences between RFC 4627 or the cu… R S
- Re: [Json] Authorship R S
- Re: [Json] Differences between RFC 4627 or the cu… Paul Hoffman
- Re: [Json] Differences between RFC 4627 or the cu… R S
- Re: [Json] Differences between RFC 4627 or the cu… John Cowan
- Re: [Json] Authorship Peter Saint-Andre
- Re: [Json] Authorship John Cowan
- Re: [Json] Obsoletes RFC 4627 Martin J. Dürst
- Re: [Json] Obsoletes RFC 4627 Tim Bray
- Re: [Json] Obsoletes RFC 4627 Eliot Lear
- Re: [Json] Authorship Eliot Lear
- Re: [Json] [authorship] (was: Working Group Last … Martin J. Dürst
- Re: [Json] -0.0 Martin J. Dürst
- Re: [Json] Section 1.3, "Changes from RFC 4627" Martin J. Dürst
- Re: [Json] Obsoletes RFC 4627 Martin J. Dürst
- Re: [Json] -0.0 Martin J. Dürst
- Re: [Json] -0.0 Carsten Bormann
- Re: [Json] -0.0 Bjoern Hoehrmann
- Re: [Json] Authorship Pete Resnick
- Re: [Json] Differences between RFC 4627 or the cu… Tony Hansen
- Re: [Json] ECMA-262 normative? Tim Bray
- Re: [Json] Differences between RFC 4627 or the cu… R S
- Re: [Json] Differences between RFC 4627 or the cu… Carsten Bormann
- Re: [Json] Authorship Bjoern Hoehrmann
- Re: [Json] -0.0 John Cowan
- Re: [Json] -0.0 Matt Miller (mamille2)
- Re: [Json] -0.0 R S
- Re: [Json] -0.0 R S
- Re: [Json] -0.0 R S
- Re: [Json] -0.0 John Cowan
- Re: [Json] -0.0 R S
- Re: [Json] -0.0 R S
- Re: [Json] -0.0 Carsten Bormann
- Re: [Json] -0.0 R S
- Re: [Json] -0.0 Carsten Bormann
- Re: [Json] -0.0 Tim Bray
- Re: [Json] -0.0 Peter Patel-Schneider
- Re: [Json] -0.0 John Cowan
- Re: [Json] -0.0 Paul Hoffman
- Re: [Json] -0.0 R S
- Re: [Json] -0.0 John Cowan
- Re: [Json] -0.0 Carsten Bormann
- [Json] Change Control (was: Re: Authorship) Martin J. Dürst
- [Json] Indentation (was: Re: Change Control) Martin J. Dürst
- Re: [Json] Indentation (was: Re: Change Control) Carsten Bormann
- Re: [Json] Indentation (was: Re: Change Control) Carsten Bormann
- Re: [Json] Change Control (was: Re: Authorship) Jorge Chamorro
- Re: [Json] Differences between RFC 4627 or the cu… Tony Hansen
- [Json] ECMA-262 normative? Carsten Bormann
- Re: [Json] ECMA-262 normative? John Cowan
- Re: [Json] ECMA-262 normative? Paul Hoffman
- Re: [Json] ECMA-262 normative? Eliot Lear
- [Json] Change control for the MIME media type Paul Hoffman
- Re: [Json] ECMA-262 normative? R S
- Re: [Json] Differences between RFC 4627 or the cu… R S
- Re: [Json] Differences between RFC 4627 or the cu… Tony Hansen
- Re: [Json] ECMA-262 normative? Tim Bray
- Re: [Json] ECMA-262 normative? Carsten Bormann
- Re: [Json] Differences between RFC 4627 or the cu… Tim Bray
- Re: [Json] Differences between RFC 4627 or the cu… R S
- Re: [Json] Differences between RFC 4627 or the cu… Bjoern Hoehrmann
- Re: [Json] Differences between RFC 4627 or the cu… Tim Bray
- Re: [Json] Differences between RFC 4627 or the cu… Tim Bray
- Re: [Json] Differences between RFC 4627 or the cu… Carsten Bormann
- Re: [Json] Differences between RFC 4627 or the cu… Paul Hoffman
- Re: [Json] Differences between RFC 4627 or the cu… Tony Hansen
- Re: [Json] Differences between RFC 4627 or the cu… R S
- Re: [Json] Differences between RFC 4627 or the cu… R S
- Re: [Json] section 1 paragraph 2 on what JSON can… Tony Hansen
- Re: [Json] Differences between RFC 4627 or the cu… Paul Hoffman
- Re: [Json] section 1 paragraph 2 on what JSON can… Carsten Bormann
- Re: [Json] Differences between RFC 4627 or the cu… Jorge Chamorro
- Re: [Json] section 1 paragraph 2 on what JSON can… Tim Bray
- Re: [Json] Differences between RFC 4627 or the cu… Tony Hansen
- Re: [Json] section 1 paragraph 2 on what JSON can… John Cowan
- Re: [Json] Differences between RFC 4627 or the cu… John Cowan
- Re: [Json] Differences between RFC 4627 or the cu… Tim Bray
- Re: [Json] section 1 paragraph 2 on what JSON can… Tony Hansen
- Re: [Json] Differences between RFC 4627 or the cu… Carsten Bormann
- Re: [Json] Differences between RFC 4627 or the cu… John Cowan
- Re: [Json] Differences between RFC 4627 or the cu… Jorge Chamorro
- Re: [Json] Differences between RFC 4627 or the cu… Jorge Chamorro
- Re: [Json] section 1 paragraph 2 on what JSON can… Paul Hoffman
- Re: [Json] Differences between RFC 4627 or the cu… Tim Bray
- Re: [Json] Differences between RFC 4627 or the cu… Martin J. Dürst
- Re: [Json] section 1 paragraph 2 on what JSON can… Manger, James H
- Re: [Json] Differences between RFC 4627 or the cu… R S
- Re: [Json] Differences between RFC 4627 or the cu… Martin J. Dürst
- Re: [Json] section 1 paragraph 2 on what JSON can… John Cowan
- Re: [Json] section 1 paragraph 2 on what JSON can… Manger, James H