Re: [Json] Comments on proposed charter for JSON

Bjoern Hoehrmann <derhoermi@gmx.net> Fri, 01 March 2013 19:15 UTC

Return-Path: <derhoermi@gmx.net>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4722321F91A8 for <json@ietfa.amsl.com>; Fri, 1 Mar 2013 11:15:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.907
X-Spam-Level:
X-Spam-Status: No, score=-2.907 tagged_above=-999 required=5 tests=[AWL=-0.308, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SDWvVO1gNnRc for <json@ietfa.amsl.com>; Fri, 1 Mar 2013 11:15:19 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) by ietfa.amsl.com (Postfix) with ESMTP id ED4C521F8DCB for <json@ietf.org>; Fri, 1 Mar 2013 11:15:11 -0800 (PST)
Received: from mailout-de.gmx.net ([10.1.76.12]) by mrigmx.server.lan (mrigmx002) with ESMTP (Nemesis) id 0Lkmp0-1Ulf7T0KoO-00aUIW for <json@ietf.org>; Fri, 01 Mar 2013 20:15:11 +0100
Received: (qmail invoked by alias); 01 Mar 2013 19:15:10 -0000
Received: from p5B233C70.dip.t-dialin.net (EHLO netb.Speedport_W_700V) [91.35.60.112] by mail.gmx.net (mp012) with SMTP; 01 Mar 2013 20:15:10 +0100
X-Authenticated: #723575
X-Provags-ID: V01U2FsdGVkX1+jhXQUtXGjLUBviKm9FT3I0RRyUP0mZyAXhXn/OP bRb4MHC4VC1KFt
From: Bjoern Hoehrmann <derhoermi@gmx.net>
To: "Joe Hildebrand (jhildebr)" <jhildebr@cisco.com>
Date: Fri, 01 Mar 2013 20:15:11 +0100
Message-ID: <hms1j89m6oorgjv7j5d6cnm9bkvmadk94s@hive.bjoern.hoehrmann.de>
References: <4F511CA8-1FC1-46AF-BC22-C64F2C63C052@vpnc.org> <A723FC6ECC552A4D8C8249D9E07425A70F8AF2FE@xmb-rcd-x10.cisco.com>
In-Reply-To: <A723FC6ECC552A4D8C8249D9E07425A70F8AF2FE@xmb-rcd-x10.cisco.com>
X-Mailer: Forte Agent 3.3/32.846
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Y-GMX-Trusted: 0
Cc: Barry Leiba <barryleiba@computer.org>, Paul Hoffman <paul.hoffman@vpnc.org>, "json@ietf.org" <json@ietf.org>
Subject: Re: [Json] Comments on proposed charter for JSON
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Discussion related to JavaScript Object Notation \(JSON\)." <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: Fri, 01 Mar 2013 19:15:20 -0000

* Joe Hildebrand (jhildebr) wrote:
>(individual)
>I'm fine with the text as it currently sits.
>
>(chair)
>Does the current text give anyone heartburn?  I'll start another thread
>mid-next week to make sure.

The way I look at this, there is a very small subset that works reliably
(only UTF-8, no Unicode signature, all keys are unique, the top level is
either array or object, and probably some other restrictions) but beyond
that JSON is a highly fragmented and in need of standardisation, and the
current proposal does not really convey that state of affairs and does
really say what the Working Group would be expected to do about it.

To illustrate, http://www.w3.org/TR/2012/WD-XMLHttpRequest-20121206/ has
a JSON loading feature that treats all JSON documents as UTF-8 encoded,
even RFC 4627-compliant UTF-16-encoded ones, requires to ignore the
UTF-8 BOM which normally breaks RFC 4627-compliant decoders, it allows
strings and other things at the top-level that cannot be used in RFC
4627-compliant JSON, it requires to recover from UTF-8 errors in a
certain way, ...

If I want to implement a JSON decoder that behaves like XMLHttpRequest,
then RFC 4627 cannot be used as a reference in any notable way, and if
the Working Group makes all the changes needed to do exactly what the 
XMLHttpRequest feature does, then that's not "minimal" and does "break
compatibility" and goes well beyond simply putting JSON on the standards
track, as far as I am concerned. And if it doesn't do this and XHR isn't
changed (and XMLHttpRequest is just an example, all sorts of libraries
and other things have similar inconsistencies) then we'll have W3C-JSON
and IETF-JSON and more, outside the common subset noted above.
-- 
Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/