Re: [Json] Differences between RFC 4627 or the current ECMAScript specification

Eliot Lear <lear@cisco.com> Thu, 26 September 2013 18:52 UTC

Return-Path: <lear@cisco.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 E4F8A21E80AB for <json@ietfa.amsl.com>; Thu, 26 Sep 2013 11:52:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.506
X-Spam-Level:
X-Spam-Status: No, score=-110.506 tagged_above=-999 required=5 tests=[AWL=0.093, 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 ibwdEidJpwkB for <json@ietfa.amsl.com>; Thu, 26 Sep 2013 11:52:09 -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 9E1F221E8094 for <json@ietf.org>; Thu, 26 Sep 2013 11:52:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1634; q=dns/txt; s=iport; t=1380221528; x=1381431128; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=wM7JfkK1W4Ievkjx2ab72GMcpabmgqBuxEu3SuouUAk=; b=dXPQTgkSpLbKF3eU8E27wZvg9aD//cVBlmxCbQ+WAK4GY2WngfIW0mqF DI9iNM54/S9bzX30m3S+O6dn3TSQg7cx5MpulnNhtFj+xdK4Ltzk2ADrL mroat5dH4fouxT/7LDM4TKSrmVUXYVuulBVPyVSU7WLB5eGQBDL39Znaa 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AiIFADGBRFKQ/khN/2dsb2JhbABbgweEM70qCoEgFnSCJQEBAQQjVQEQCxgCAgUWCwICCQMCAQIBKxoGDQEHAQGIAqokkkKBKY4oB4JogTYDl32ReIMmOg
X-IronPort-AV: E=Sophos;i="4.90,987,1371081600"; d="scan'208";a="18308028"
Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-4.cisco.com with ESMTP; 26 Sep 2013 18:52:07 +0000
Received: from mctiny.local ([10.61.168.117]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r8QIq5kJ026697 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 26 Sep 2013 18:52:05 GMT
Message-ID: <52448254.5090209@cisco.com>
Date: Thu, 26 Sep 2013 20:52:04 +0200
From: Eliot Lear <lear@cisco.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: Paul Hoffman <paul.hoffman@vpnc.org>
References: <BF7E36B9C495A6468E8EC573603ED9411EF1BB0B@xmb-aln-x11.cisco.com> <CAChr6SyznBktmOLpT-EiZ5Nm_0jZ16M0tOo4aZ_jhSDb=HHDqg@mail.gmail.com> <23C96FBA-3419-4C97-A075-462F7443013A@vpnc.org>
In-Reply-To: <23C96FBA-3419-4C97-A075-462F7443013A@vpnc.org>
X-Enigmail-Version: 1.5.2
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Cc: JSON WG <json@ietf.org>
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: Thu, 26 Sep 2013 18:52:15 -0000

Paul,

On 9/26/13 8:36 PM, Paul Hoffman wrote:
> <no hat>

I've got an IAB hat, and it involves this, but I am but a member of the
IAB, and the below is my advice.
>
> Based on what we have learned in the last six months, it might be better for this RFC *not* to do what the charter says.

This is a matter for Pete.  He hinted at something about this in a
previous message, but...
>
> - TC39 is actively revising ECMAScript and it is not clear whether the -bis draft of their version will be out first.
>
> - Some of what ECMAscript says about JSON is intertwingled with the definition of ECMAscript, such as "exactly how to interpret numbers"
>
> I'm no longer sure that a long-lasting RFC interpreting parts of another SDO's spec is a good idea.
>
>

What I would suggest is that at the very least we understand the
differences, so that we know what we're getting into.  My understanding
is that what is proposed in the latest draft is in line with what
they've produced, although we provide interoperability guidance that is
somewhat more constraining.  Some eyes here would be good.

If we agree on all of this, there is the question on whether or not the
document should simply normatively reference ECMA.  But I would only do
this if we are agreed that the normative specifications are intended to
be identical, and then I would think it a good idea (even though I'm
entirely non-plussed by the approach taken by ECMA members), simply to
avoid unintended differences.

If, however, the working group has diverged intentionally, I would
suggest that those differences be called out.

Eliot