[Json] Normative reference reasoning and logistics

Tim Bray <tbray@textuality.com> Sat, 14 November 2015 19:11 UTC

Return-Path: <tbray@textuality.com>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 04FA21AD0AB for <json@ietfa.amsl.com>; Sat, 14 Nov 2015 11:11:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.277
X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] autolearn=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id dWeJcU7tirez for <json@ietfa.amsl.com>; Sat, 14 Nov 2015 11:11:08 -0800 (PST)
Received: from mail-ig0-x231.google.com (mail-ig0-x231.google.com [IPv6:2607:f8b0:4001:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73E3F1AD0AA for <json@ietf.org>; Sat, 14 Nov 2015 11:11:08 -0800 (PST)
Received: by igl9 with SMTP id 9so35470646igl.0 for <json@ietf.org>; Sat, 14 Nov 2015 11:11:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=textuality_com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to:content-type; bh=481BV0xGCYAwWKULn0Eup92ddToGeedLG12+FWCRrYg=; b=T4p4KrpoMY3QUVojOyFPtuBCZDUhwqLPs7fyYWHb4ZIlSedFiiITvCNbwKFJmkx6Fb GpfjxTpBFmuJ5+U3bhDm2qvVtZGJZRVqgSJ4mdqX0kYnPgD0HFKGeogrI2hNRWIGRNUs HPjG8yn3LTaAPTIul/Nreg+wUh83w4eJnOa7G4j3FzrCWS5hXtngxTKd7JAmY9zhNfFz spoRIzsY4CQwOWxQaq5+k0/LDfoyCTPmwVEdQ8ULxEkunslDtllQ84+F2W2Nab3QARhb P2wEIePqw/KDH6Z2z+pgA08rmuxGedxkQFsWf7fgXn8gPoi+Eaw9gAPxh/qanQs1fyKI ZyVw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=481BV0xGCYAwWKULn0Eup92ddToGeedLG12+FWCRrYg=; b=cHrv6p8xvrD4crazMxAuiAMI62x2tn5Az7HzhuXnS132lKgh9SI/iQ3Qvr+2LXuyXv 91w7JhDqbrvxIHZuhXT31YwVbdCq5NcG1RjA2aGkpbzP8FVSqv54lfrjDe7xwlBhpfBz sS+P2K6PeGfe8pdenuA4y9yL3GNvysnL76QCBcFwvCL8bPNLURmzzl80w2EXYl+ZpFY5 /IIbgPc8+QDcMTwAVwUp0bEvD2Dums4Sb2n14Tfw4iY+zjZsMDt/gicqsGAIoOszxB3w 2YNyFSkPqwcGvj3IhFQftJRBJTiAQneZlh1yvLfNxNSVpSkBTsn7kwCmAYKS+fBNwFOe U/5Q==
X-Gm-Message-State: ALoCoQlcCCoJPoEi1lAku2bCjUbx75VHFtJOJMwll6w4E3QFTvRaiajtQgaggKtN+5WHS67PTDI2
X-Received: by with SMTP id j18mr9516804igt.43.1447528266570; Sat, 14 Nov 2015 11:11:06 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Sat, 14 Nov 2015 11:10:47 -0800 (PST)
X-Originating-IP: []
From: Tim Bray <tbray@textuality.com>
Date: Sat, 14 Nov 2015 11:10:47 -0800
Message-ID: <CAHBU6iu0j492Mzbo2HriFtjm_o5516yCsQCX9PGHvqAxhU0Zjg@mail.gmail.com>
To: "json@ietf.org" <json@ietf.org>
Content-Type: multipart/alternative; boundary="047d7bdc053221bcd8052484f0e5"
Archived-At: <http://mailarchive.ietf.org/arch/msg/json/hiNXruCdXHSTRncTynpYa2VrLJM>
Subject: [Json] Normative reference reasoning and logistics
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
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: <https://mailarchive.ietf.org/arch/browse/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: Sat, 14 Nov 2015 19:11:10 -0000

Our charter says we are to consider inserting a normative reference to
ECMA-404 into an RFC7159bis.  There is a problem in that the definition of
“normative reference” is clear (I won't read it off yet again) and there's
no way ECMA-404 qualifies.

You could make a case that the reference is useful because 404 allows all
the things 7159 warns against, but implementors would be better served by a
simple assertion that “404 allows all the things 7159 warns against”.

In fact, I'm deeply unconvinced that consulting -404 is useful for anyone
in any circumstance, because it doesn't change the definition of what a
“JSON text” is from that found in 7159 and all its predecessors.

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: http://rfc7159.net/rfc7159#rfc.section.1.2 ):

“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

But I have a practical question. What exact effect to we expect this to
have?  Will ECMA-404 be updated in place with a reference to 7159bis (ECMA
specs can be updated in place, because -404 already has been, to remove a
silly typo).  Will there be an ECMA-404bis, and if so, should we work
carefully with ECMA to make sure that the two -bis specs mutually reference
each other?