[Json] How to argue about I-JSON

Tim Bray <tbray@textuality.com> Mon, 28 April 2014 18:16 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 28A9A1A6F39 for <json@ietfa.amsl.com>; Mon, 28 Apr 2014 11:16:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.078
X-Spam-Status: No, score=-0.078 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id TsaBCJw4ermM for <json@ietfa.amsl.com>; Mon, 28 Apr 2014 11:16:50 -0700 (PDT)
Received: from mail-vc0-f175.google.com (mail-vc0-f175.google.com []) by ietfa.amsl.com (Postfix) with ESMTP id 951BC1A04F1 for <json@ietf.org>; Mon, 28 Apr 2014 11:16:50 -0700 (PDT)
Received: by mail-vc0-f175.google.com with SMTP id lh4so1829444vcb.34 for <json@ietf.org>; Mon, 28 Apr 2014 11:16:49 -0700 (PDT)
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=0kOcpJAM+tqJfvFBZiFAs5mtZe8giVgZ/x7I7wajGh4=; b=CqtGaiE0p1LqGpoEpDrJpy9QcR1NlSa9YXc0x4JI9ARSkLIzcdSLh8U5upXow5oArd wjc4FOAksi9SA3dRto353aHA2+xBYgwUdpCuKWjk1iP1alXPPxF2uo5S5h0TgBbDiuys XD63ohCHzovG4fLkl8c6IWiXwx7zpBoYBAQk4oEzJn2V5+SpHyvDuGfa7mSASqxuK4cp qxdKGtqfJQvZ7WgHHZcl8GTBCV5TSnVTzBW2hiqU1rt+7irfQe2XMXJxyuSZeTPUiDMJ RHP6Plrfm6/wTSW7KPmQE6yUxPmnEnkvRCoZVgs2BvguSO+eczaKPv+ceBElVZWmrI+g UdZQ==
X-Gm-Message-State: ALoCoQlhl7tIanaYe3tzphp5YK5nbLWUoSB0HlhCphi8Cds2HCTZvsNAL9whApAa9ffCM4TRR6oS
X-Received: by with SMTP id pm10mr312341vdb.55.1398709009656; Mon, 28 Apr 2014 11:16:49 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Mon, 28 Apr 2014 11:16:29 -0700 (PDT)
X-Originating-IP: []
From: Tim Bray <tbray@textuality.com>
Date: Mon, 28 Apr 2014 11:16:29 -0700
Message-ID: <CAHBU6iurWB29LujFibWBgcLMsH-n0Jkide_8gAR8fs_FEvoMRA@mail.gmail.com>
To: "json@ietf.org" <json@ietf.org>
Content-Type: multipart/alternative; boundary=bcaec5299f9baa445704f81e518e
Archived-At: http://mailarchive.ietf.org/arch/msg/json/9TK24BUnmQTT3ozKw4mRp3GW0sA
Subject: [Json] How to argue about I-JSON
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: Mon, 28 Apr 2014 18:16:52 -0000

This is an attempt to leap in front of the debate, use the take-aways from
the very useful London f2f, and make our time arguing about I-JSON
.  There are plenty of bikesheds out there, but I think the number of
useful arguments is limited and the issues in them pretty clear.

Argument 1 - Media types?

Should there be an I-JSON media type, or a application/*+i-json suffix?
 draft i-json-01 calls for it, but this is at best controversial.  My
suggestion is that people who still think this is a good idea
​need to speak up.  (I won’t.)

Argument 2 - Top-level

draft-i-json-01 says the top level is an object (but doesn’t say MUST,
eek).  I have heard arguments for allowing arrays too​; anyone who thinks
that is a good idea should speak up. (I won’t.)

Argument 3 - Unicode

draft-i-json-01 excludes the use of, and I quote, “Surrogates or
Noncharacters”.   Is that the right use of Unicode nomenclature?  This
really matters and I think it’s OK now, but first-class Unicode lawyering
is required here.

Argument 4 - Software behavior

Section 3 of draft-json-01 implies draconian error handling - when a
message is specified to be i-json but the receiver finds, for example, a
dupe key, it is required to halt and catch fire. There’s a chance that this
will be interpreted as “tbray poisons JSON with XML draconianism”. People
with alternate language should suggest it. (I probably won’t argue this one
either way.)

Argument 5 - Numbers

draft-i-json-01 says that you MUST not put in a string representing a
number with greater precision/magnitude than IEEE754 doubles can support.
I think this is a good idea but I'm a little nervous because I’ve never
written the code, if this is unreasonably hard at either the sending or
receiving end someone should  say so.

...... aaaaaaand, that’s all folks.   I’m optimistic that we can zero in on
this one quickly.