Re: [Json] Normative reference reasoning and logistics

"Joe Hildebrand (jhildebr)" <> Mon, 02 May 2016 16:17 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CCDBC12B069 for <>; Mon, 2 May 2016 09:17:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -15.517
X-Spam-Status: No, score=-15.517 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id dNY_fJOMMgZI for <>; Mon, 2 May 2016 09:17:46 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id CF14212B006 for <>; Mon, 2 May 2016 09:17:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=4862; q=dns/txt; s=iport; t=1462205865; x=1463415465; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=O36p11os3M2H5eJ2TbOTfPG9Xdgc7/7IQ0BBTi6elQk=; b=G1wBkE3mvaXEGerqLV4Vm7/1Or3tKV7Z6iMpniVJMoegkyCcditpgfD8 QwFX3PuEuLhxCMmzA7fK6BAkMqImx+KLC+KLheu197FyLgBv7yHNDh3MO v6J2AA0EO/BeWaMsXNzQRPi4nFBpmsaizf1fgRVnyCKKAI6qGDTi6+4ZD Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DCAgChfCdX/5BdJa1dgzhTdwYGuXABD?= =?us-ascii?q?YF2FwuFbgIcgRQ4FAEBAQEBAQFlJ4RBAQEBBAEBASAROgsQAgEIEQQBAQECAiM?= =?us-ascii?q?DAgICJQsUAQgIAgQBDQWIFQMSCQWqEIt8HYQ+AQEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBFXyFJYF2glaERBAjgkYrgisFmBQBhXuCd4UlgWdOjFyGJIkMAR4BAUKCBRu?= =?us-ascii?q?BS2wBAYgGfwEBAQ?=
X-IronPort-AV: E=Sophos;i="5.24,568,1454976000"; d="scan'208";a="267959850"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 02 May 2016 16:17:44 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id u42GHiaS018536 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 2 May 2016 16:17:44 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 2 May 2016 12:17:43 -0400
Received: from ([]) by ([]) with mapi id 15.00.1104.009; Mon, 2 May 2016 12:17:43 -0400
From: "Joe Hildebrand (jhildebr)" <>
To: "Manger, James" <>, Tim Bray <>
Thread-Topic: [Json] Normative reference reasoning and logistics
Thread-Index: AQHRlAaTE88EUYV2AkmALftkB7sIZp+flv6AgAVcVACAACd6AIAAt/GA
Date: Mon, 2 May 2016 16:17:43 +0000
Message-ID: <>
References: <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/f.15.1.160411
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-ID: <>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <>
Cc: "" <>
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: Mon, 02 May 2016 16:17:48 -0000

If we did this, then we would have to talk the IESG into applying an STD number to RFC 7159 with known errata, or give up on JSON becoming a full Internet Standard.  In my opinion, it's worth changing the RFC number again.

Joe Hildebrand

On 5/1/16, 5:19 PM, "Manger, James" <> wrote:

>Sounds more harmful than helpful to again change the RFC number that defines JSON — rfc4627, rfc7158, rfc7159, rfcXXXX — for what is
> supposed to be a simple and stable format.
>Stick the text in as an errata marked “held for document update”; or stick it in its own RFC that updates rfc7159 (bit weird?); or
> in a liaison note to ECMA.
>James Manger
>From: json []
>On Behalf Of Tim Bray
>Sent: Monday, 2 May 2016 6:58 AM
>To: Joe Hildebrand (jhildebr) <>
>Subject: Re: [Json] Normative reference reasoning and logistics
>Never seen anything quite like this in an RFC, but it doesn’t feel crazy or damaging.  
>I share the opinion expressed by others here that ECMA-404 is largely ignored and of marginal relevance, but I gather there’s a perceived benefit in establishing that ECMA & IETF are in sync on this subject.
>On Thu, Apr 28, 2016 at 10:06 AM, 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.
>Joe Hildebrand
>json mailing list
>- Tim Bray (If you’d like to send me a private message, see 
> <>)