[Json] Response to Statement from Ecma International TC39

"Matt Miller (mamille2)" <mamille2@cisco.com> Thu, 05 December 2013 02:57 UTC

Return-Path: <mamille2@cisco.com>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F4FD1AE324 for <json@ietfa.amsl.com>; Wed, 4 Dec 2013 18:57:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.502
X-Spam-Level:
X-Spam-Status: No, score=-14.502 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id stiYr_4t7OSa for <json@ietfa.amsl.com>; Wed, 4 Dec 2013 18:57:10 -0800 (PST)
Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 16C721AE33F for <json@ietf.org>; Wed, 4 Dec 2013 18:57:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5758; q=dns/txt; s=iport; t=1386212227; x=1387421827; h=from:to:subject:date:message-id:mime-version; bh=aRpTCWGoLBsQKME0848y2cNPX1d0Do4cEyuoBWN3L8Y=; b=W1O8cCEoiQJLkIhBNbCQ0VSNDVUEpa+YHRU82z/lEuR/ElwTXqW75lRw 5cd8GvkefVGPOsZj78/L1sit3hJbXQuVBiN2IgyPYVH6sd1GjnnlrLynZ mxRVpACrl6kkjeZCKGx2jVf46UJkVCZ0bE3HWZZ3xE/NxmsO44WjN9UTS M=;
X-Files: signature.asc : 496
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhgFAFbqn1KtJXG9/2dsb2JhbABZgwc4U7gcgWkWdIIqAm4EGQGBACcEIYd0DaIrnzIEkiWBEwOQMYExhjKSE4Mpgio
X-IronPort-AV: E=Sophos; i="4.93,830,1378857600"; d="asc'?scan'208"; a="286476207"
Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-9.cisco.com with ESMTP; 05 Dec 2013 02:57:06 +0000
Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id rB52v69Q020175 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <json@ietf.org>; Thu, 5 Dec 2013 02:57:06 GMT
Received: from xmb-aln-x11.cisco.com ([169.254.6.57]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.03.0123.003; Wed, 4 Dec 2013 20:57:06 -0600
From: "Matt Miller (mamille2)" <mamille2@cisco.com>
To: JSON WG <json@ietf.org>
Thread-Topic: Response to Statement from Ecma International TC39
Thread-Index: AQHO8WWuWAIKhOsRzEO63MmngF6OdA==
Date: Thu, 5 Dec 2013 02:57:05 +0000
Message-ID: <C7707CE2-C43E-4171-AE96-9FAFDCE53317@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [10.21.79.221]
Content-Type: multipart/signed; boundary="Apple-Mail=_25B089E7-B5BF-49D1-A44C-E7984B240F94"; protocol="application/pgp-signature"; micalg=pgp-sha512
MIME-Version: 1.0
Subject: [Json] Response to Statement from Ecma International TC39
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: <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, 05 Dec 2013 02:57:12 -0000

Hello All,

The JSON Working Group has received a statement from Ecma International's Technical Committee 39 (TC39) regarding draft-ietf-json-rfc4627bis.  The statement can be found at < https://datatracker.ietf.org/documents/LIAISON/liaison-2013-11-25-ecma-tc39-json-ecma-tc39-comment-for-rfc-4727bis-attachment-1.pdf >.

In response, the Chairs and sponsoring Area Director propose to send the following on behalf of the JSON Working Group.  We wish to send the response on December 10.  If there are any serious factual errors in the following response, let us know before then.  Note that we are *not* asking the WG to re-open any of the consensus discussions, simply to see if we misstated anything factual.


Thank you,

-- Paul Hoffman and Matt Miller

-----BEGIN RESPONSE-----
Thank you for your statement of concern about draft-ietf-json-rfc4627bis. The chairs of the IETF's JSON Working Group were not aware of any serious concerns that TC39 had with the update process. Over the past many months, we repeatedly contacted ECMA and TC39 members about the JSON WG and draft-ietf-json-rfc4627bis, but never received any significant reply. We know that some TC39 members joined the JSON WG mailing list but did not voice any process concerns in the WG -- or privately to the WG Chairs -- before or during either of the Last Calls on the document.

In the future, it would probably be useful for Ecma and the IETF to have a formal liaison relationship. We have heard that there were preliminary discussions several months ago, but stopped short of a formal relationship before the JSON Working Group was formed. Formalizing the liaison relationship will help both SDOs communicate with each other and thus avoid late surprises.

As to your specific requests:

- In IETF Last Call, there was consensus to change the definition of "JSON text" in draft-ietf-json-rfc4627bis to match the one in ECMA-404. The latest draft reflects that change. At this point, we believe that there are no syntactic differences between the two specifications.

- The JSON WG decided to change the title of the document to better reflect its content. The current document is much more than a media type registration: it repeats the JSON syntax originally documented in RFC 4627, and has been stable for many years, it is a discussion of the JSON semantics important to freestanding encoders and parsers, it is a discussion of interoperability issues that have been encountered since RFC 4627 and ECMA-262 5th Edition were published, and it is a media type registration. Having a more accurate title on the document will help readers understand its contents and the difference between it and ECMA-404.

- After Ecma published ECMA-404, the JSON WG discussed whether to remove the ABNF version of the JSON syntax that was established in RFC 4627 from draft-ietf-json-rfc4627bis; it was decided not to do so. One reason is that ECMA-404 uses "racetrack pictures" to define the syntax, whereas IETF documents have traditionally used ABNF, and many developers have expressed a strong preference for the ABNF. This might be considered simply a matter of style, but it was deemed important by many WG members. We intend to keep the discussion and reference to ECMA-404 in draft-ietf-json-rfc4627bis, even if Ecma continues to choose not to reciprocate in ECMA-262 6th Edition, because developers reading draft-ietf-json-rfc4627bis might indeed prefer the racetrack pictures.

- A normative reference to ECMA-404 would be premature without a clear and well-understood document management process. Historically, when someone reading an RFC sees a normative reference to one version of another SDO's standards, they tend to think the reference will apply to future versions of that external standard as well. Given the closed process that resulted in ECMA-404, it seems quite possible that Ecma could later make changes to ECMA-404 that would have a negative effect on interoperability from the Internet perspective. When the IETF normatively refers to other standards, it almost exclusively does so to standards that were developed with processes that are open to discussion and contribution by anyone.

If the IETF believed that future development of ECMA-404 would involve a similar kind of open participation as seen with the development of draft-ietf-json-rfc4627bis, it could certainly revisit the topic of a normative reference in any subsequent update. Such a belief could be one of the positive products of a formal liaison relationship between the IETF and Ecma.
-----END RESPONSE-----