Re: [Json] Normative reference reasoning and logistics

Anders Rundgren <> Sun, 01 May 2016 12:15 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1C9B412B03C for <>; Sun, 1 May 2016 05:15:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id mOPwHPs2mfaK for <>; Sun, 1 May 2016 05:15:00 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id ECCF2128874 for <>; Sun, 1 May 2016 05:14:59 -0700 (PDT)
Received: by with SMTP id e201so77421614wme.0 for <>; Sun, 01 May 2016 05:14:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=MjWa3hIS4FMxyPDUxi97BmksrF+x54W5IaMXwB8i2z0=; b=LcyRCsG5j3kyMnFeHKoq/SfTk/7Z3TuZXP/UBmJrMiFf0EiikgiKbX2iWPMydUCIZP myf1gK/d6zd+LLnXxWN9IZEzpJsRDbBMBpGey8ux82uCQ4lViF0w1xNPoHDknnYVDr+b uyNJIhKSnITfAVpRoC0qAht4m1Z+I+AuujKtFet61LhqvJeTAVJm74sAzEHsTbRH6L17 7qzYp9qp/udr9pzY5D2eFmiUK6jExo4fuzWuGXblJqdXuJgo2ISBSGocOCEzvWHPbu+q Y5RhB7yggOyPa4ibwF4a8r8QlgsB3RaESlt3rqUmPeekVc3HlRvcfd2f0sthh5bU440g sB6A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=MjWa3hIS4FMxyPDUxi97BmksrF+x54W5IaMXwB8i2z0=; b=lsKXkx2hZVwqB7VTSgunwEtWTrHnVBD/LKNf/DIpQlJQHGHNfjl4/9FXeQVojXn/sF uzPbO0bhULn0Y4M3auyBcjw/kTASRhuSroFqYRI/un4ccZCLUsNPBaMzN/06JrNjXGO8 ReISIignszodsGhVzdmMmKO2cjEevFrLUlhSV+Tz1Xt1Gx5ACvFjOkZzwmYs1XrrHh1y 0ma3PCxv6tUt+D7CdXMwgSXXwGFUARVBsRvsEL+Wq1oSngXzHolk7dJvpUgeoJbgfsgU P6pyKCYbDgKbl6G7AsoiODhS5k2l8kyCrgAKh473plYItsS2mMzHyuY7iRiNpMeGSbfM rRIA==
X-Gm-Message-State: AOPr4FVI9wvK9/FiFQkaIslTNLAj16fH9M11VgcuC02mJ7iHQo1BczdBxLsbBJsReTBqlQ==
X-Received: by with SMTP id u2mr31139010wjy.61.1462104898538; Sun, 01 May 2016 05:14:58 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id e16sm13114369wmc.3.2016. (version=TLSv1/SSLv3 cipher=OTHER); Sun, 01 May 2016 05:14:57 -0700 (PDT)
To: Stefan Hagen <>, "" <>
References: <> <> <> <>
From: Anders Rundgren <>
Message-ID: <>
Date: Sun, 1 May 2016 14:14:44 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <>
Cc: "Joe Hildebrand \(jhildebr\)" <>
Subject: Re: [Json] Normative reference reasoning and logistics
X-Mailman-Version: 2.1.17
Precedence: 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, 01 May 2016 12:15:02 -0000

IMO, ES6's JSON serialization scheme will likely be way more significant than ECMA-404
(which I believe very few application developers have bothered looking into).


On 2016-05-01 10:59, Stefan Hagen wrote:
> On 2016-APR-28 at 19:06 in some TZ Joe Hildebrand (jhildebr) wrote:
>> Going back to an earlier point in the thread:
>> On 11/14/15, 11:10 AM, "Tim Bray" <> wrote:
>>> So, is there a *real* reason why a normative reference might be useful? I think there might be, and it's purely rhetorical (in the formal sense, designed to support an argument): To make it clear to the world
>>> that all JSON is the same JSON no matter where it's specified.  So I think it would be plausible to add the following to the second paragraph of section 1.2 of 7159 (for convenience:
>>> ):
>>> “The reference to ECMA-404 in the previous sentence is normative, not with the usual meaning that implementors need to consult it in order to understand this document, but to emphasize that there are no inconsistencies in the definition of the term “JSON text” in any of its specifications. Note, however, that ECMA-404 allows several practices which this specification recommends avoiding in the interests of maximal interoperability.”
>> I like this text a lot.  Adding a few more points would be useful, I believe:
>> - The intent is that the grammar is the same between the two documents, although different descriptions are used.  If there a difference is found between them, ECMA and the IETF will work together to update both documents.
>> - If an error is found with either document, the other should be examined to see if it has a similar error, and fixed if possible.
>> - If either document is changed in the future, ECMA and the IETF will work together to ensure that the two documents stay aligned through the change.
>> There is liaison work to do to ensure that ECMA-404bis has similar language, but I wouldn't have any problem with us publishing a 7159bis draft that included language like this before ECMA is fully onboard.
> I like the proposed text with the ammendment from Joe.
> This includes the need for ensuring liaison work and the possibility to
> first include this text and second initiate the ongoing liaison work.
> Best,
> Stefan.