[Json] Response to Statement from W3C TAG

"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 7FE191AE341 for <json@ietfa.amsl.com>; Wed, 4 Dec 2013 18:57:10 -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 jxhkFaIHGk_u for <json@ietfa.amsl.com>; Wed, 4 Dec 2013 18:57:08 -0800 (PST)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 9890A1AE324 for <json@ietf.org>; Wed, 4 Dec 2013 18:57:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4615; q=dns/txt; s=iport; t=1386212225; x=1387421825; h=from:to:subject:date:message-id:mime-version; bh=sIJqUmn0OMGfpKPBJFTJDO2Hq3WxLO2sBpxzFefa65c=; b=WkLxWs0VGvxy7x8lkK/eZtqWaLFYb0uYw7GyeLVEmSwNIET6r9aQEZ// tg6olV3IZwJ4XPaUDXIV2YFObq+8JfMvzxfR0fsnWOdS7zdbPCTlJEXV2 t290Kt5A3CLzUTDJDSMzMGJlAFJIscIjTEbRiyJU3uoWaQCAjztDPjG8m 0=;
X-Files: signature.asc : 496
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhgFAFbqn1KtJXG+/2dsb2JhbABZgwc4U7hqgRsWdIIschkBGmYXEAQcBYd0DaIrnzaOLQEBUYMlgRMDkDGBMYJPg2OSE4MpgXE5
X-IronPort-AV: E=Sophos; i="4.93,830,1378857600"; d="asc'?scan'208"; a="289462061"
Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-7.cisco.com with ESMTP; 05 Dec 2013 02:57:04 +0000
Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id rB52v4pV031798 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <json@ietf.org>; Thu, 5 Dec 2013 02:57:04 GMT
Received: from xmb-aln-x11.cisco.com ([169.254.6.57]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.03.0123.003; Wed, 4 Dec 2013 20:57:04 -0600
From: "Matt Miller (mamille2)" <mamille2@cisco.com>
To: JSON WG <json@ietf.org>
Thread-Topic: Response to Statement from W3C TAG
Thread-Index: AQHO8WWtG/WkDckWCEy7+BAN2GEcjQ==
Date: Thu, 05 Dec 2013 02:57:03 +0000
Message-ID: <799C8AFA-53C3-4698-A14A-96CB79981DE5@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=_7A07B49A-A617-4717-8EEE-F857FB1D6D6B"; protocol="application/pgp-signature"; micalg="pgp-sha512"
MIME-Version: 1.0
Subject: [Json] Response to Statement from W3C TAG
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:10 -0000

Hello All,

The JSON Working Group has received a statement from W3C Technical Architecture Group (TAG) regarding draft-ietf-json-rfc4627bis.  The statement can be found at < http://www.ietf.org/mail-archive/web/json/current/msg02083.html >.

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. We hope that this response from the chairs of the IETF's JSON Working Group allays those concerns.

The TAG expresses concerns about differences between ECMA-404 and draft-ietf-json-rfc4627bis. It says "the two specs vary slightly", which is no longer true of the syntax in the latest draft of draft-ietf-json-rfc4627bis. The TAG gives an example of its concern as being about what is allowed in a JSON text. That concern has already been met in the latest draft of draft-ietf-json-rfc4627bis: the two specifications now have no more syntax differences. During the IETF Last Call, it became clear that the consensus was that it was acceptable for the definition in draft-ietf-json-rfc4627bis be changed to match that of ECMA-404, namely that a JSON text can consist of any single JSON token (including the four-character string "42" and the two-digit number 42).

On the topic of JSON semantics, Ecma TC39 has said repeatedly that ECMA-404 is meant to only document the JSON syntax, with no description of the semantics of encoding or parsing. On the other hand, draft-ietf-json-rfc4627bis and RFC 4627 before it express both syntax and semantics. For a format such as JSON, interoperability in encoders and parsers can only be achieved with descriptions of both syntax and semantics.

The statement "we believe this could lead to interoperability issues" is of course true: ECMA chose to make JSON as described in the ECMAScript standard have different semantics than were expressed in RFC 4627. The JSON WG did not, and does not, object to ECMA choosing to have a non-interoperable semantics for JSON in its specifications: different SDOs are welcome to do so. A great deal of effort in the JSON WG process around draft-ietf-json-rfc4627bis has been to carefully describe differences between the new spec and ECMAScript.

Lastly, the TAG says "We suggest that the IETF JSON working group should re-enter discussions with ECMA TC39 in order to facilitate aligning RFC 4627bis with the current ECMA-404 specification." The syntax in the current IETF draft and the current version of ECMA-404 are believed to agree completely.

We also note that "discussions with ECMA TC39" never actually happened: the chairs of the IETF JSON WG attempted repeatedly to engage members of TC39, but were met almost completely with silence. Further, TC39 never engaged the IETF JSON Working Group for any input on ECMA-404. We understand that outside the JSON WG, the IETF (through the IAB) and Ecma had some early discussions on making a formal liaison relationship; if those discussions become fruitful in the future, the sort of non-discussion that happened in this work can be avoided.
-----END RESPONSE-----