Re: [Json] Kicking Off JSONbis

"Joe Hildebrand (jhildebr)" <jhildebr@cisco.com> Tue, 17 November 2015 09:06 UTC

Return-Path: <jhildebr@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 9433F1B2D01 for <json@ietfa.amsl.com>; Tue, 17 Nov 2015 01:06:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -13.187
X-Spam-Level:
X-Spam-Status: No, score=-13.187 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.585, 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 aculV2zkubjN for <json@ietfa.amsl.com>; Tue, 17 Nov 2015 01:06:52 -0800 (PST)
Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE0311B2D09 for <json@ietf.org>; Tue, 17 Nov 2015 01:06:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3794; q=dns/txt; s=iport; t=1447751212; x=1448960812; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Ln1PvzY7FgghC4PeU04s7zRcORSuS2m21p3UmJG2Mak=; b=NXO85MKpJ7kTr3cneEDAkuzZvPSffacHgrH63w31BR9qjlLtyiSHfXwX Af8x8V6JFCYq642ySYghxyCxGRcRWneybGdGBi6uMCXzJPXgbLd4VgWbq 7/LdjWIYqjeM95kcBnBqHMNP43tOChe0uSwSxp9gLBCKv/OVJmT2YWkAP o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CsDQDM7UpW/5tdJa1dgzt/AUIGwEqCX?= =?us-ascii?q?4MxAhyBLjsRAQEBAQEBAYEKhDUBAQQjEUUQAgEGAg4MAiYCAgIwFRACBA4FiC6?= =?us-ascii?q?NUJ01kEQBAQEBAQEBAQEBAQEBAQEBAQEBAQEYgQGFU4IQgWiBBoRZgxwvgRUBB?= =?us-ascii?q?JZJAY0pgVuHZZMEATcshARyhAOBBwEBAQ?=
X-IronPort-AV: E=Sophos;i="5.20,307,1444694400"; d="scan'208";a="208998039"
Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Nov 2015 09:06:33 +0000
Received: from XCH-RTP-002.cisco.com (xch-rtp-002.cisco.com [64.101.220.142]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id tAH96XJd003118 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 17 Nov 2015 09:06:33 GMT
Received: from xch-rtp-001.cisco.com (64.101.220.141) by XCH-RTP-002.cisco.com (64.101.220.142) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 17 Nov 2015 04:06:32 -0500
Received: from xch-rtp-001.cisco.com ([64.101.220.141]) by XCH-RTP-001.cisco.com ([64.101.220.141]) with mapi id 15.00.1104.000; Tue, 17 Nov 2015 04:06:32 -0500
From: "Joe Hildebrand (jhildebr)" <jhildebr@cisco.com>
To: Tim Bray <tbray@textuality.com>
Thread-Topic: [Json] Kicking Off JSONbis
Thread-Index: AQHRHw4KwbG58cqRTk2NlHPfs03MdJ6gVPiA
Date: Tue, 17 Nov 2015 09:06:32 +0000
Message-ID: <73F1E21E-3E3D-4EFB-A1B2-AF713EA30461@cisco.com>
References: <DB74C466-D542-42D6-95B0-690A564435A9@cisco.com> <CAC4RtVD3cKThDTr_eS-QCUhKqZkMS0y+nPS5HxCk3f1RQ7VyJQ@mail.gmail.com> <CAHBU6iv_w_O95Nq-bU1z2GOKgouuGrMbZP4Uwio25pPtFCc3UQ@mail.gmail.com> <CALaySJ+==5_mstrgHEd7bUGzSo85Er9VR_zEaJ+gh-O+zSpK=w@mail.gmail.com> <88A80A45-E673-4D0A-995B-3872874C23AE@cisco.com> <CALaySJJ01gEoHqZ4ehVHzv8mqD1CXKV3Ave3yQPrgrAGe4yckg@mail.gmail.com> <CAHBU6iuxBvn3ug9LwcK9gvrQDLr1uz=3NCrcrZaejF2iUwiLVA@mail.gmail.com> <CAChr6SzuxZrCJ+Gfc9LkKX88SetAOTp3GpxpxVF1CmmT3j5MoQ@mail.gmail.com> <56241BFE.5080609@tzi.org> <2DB105A8-AB80-4386-915D-D9AD1FBF77AD@cisco.com> <CAHBU6it7Na+5=Xhdq+cOh8o0eNq_iuanWX_hKdpggPabUGfYgQ@mail.gmail.com>
In-Reply-To: <CAHBU6it7Na+5=Xhdq+cOh8o0eNq_iuanWX_hKdpggPabUGfYgQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/0.0.0.151105
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.228.162.65]
Content-Type: text/plain; charset="utf-8"
Content-ID: <109C6B593085FC4FA9489161B9D56858@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/json/gCzUGZS5Ub0sbz8ZPMPFlGzkfUM>
Cc: "json@ietf.org" <json@ietf.org>
Subject: Re: [Json] Kicking Off JSONbis
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: Tue, 17 Nov 2015 09:06:54 -0000

On 11/14/15, 7:55 PM, "Tim Bray" <tbray@textuality.com> wrote:

>​I just re-read ECMA-404 (I recommend this, it doesn’t take long) and I couldn't find examples of such specific choices, could you be more specific?

They're not as much in 404 as they are in 262, which is referenced from 404.  For example, the double implementation for all numbers, leading to the 2^53-1 issue.  Also, some of the Unicode issues creep in through the same door.

>​Actually ECMA-404 says exactly nothing about what any software should do.​ (Maybe I missed it?)

I think it's implicit in 404's ties to 262.

>​I'm not sure about the premise.  It's not obvious to me that any changes are required in either 404 or 7159 for the foreseeable future.  404 explicitly says “Because it is so simple, it is not expected that
> the JSON grammar will ever change.”​

Nod.  This is a statement of political détente, that we hope is never actually used in practice.

>1. ​First, ECMA-404 absolutely does not describe any data model.  

Pick any other words than "data model".  Syntax?

>2. I don't like this sort of nudge-nudge, wink-wink language. If we want to provide this language, don't tell them to go search 404 for “interoperability challenges”. Rather, a simple statement along these
> lines would be appropriate.  “This document contains several recommendations for best practices to avoid interoperability problems.   ECMA-404 enforces none of these, thus implementations based on it might potentially emit JON texts which exhibit these problems.“

Perhaps we need to reference 262 explicitly as well, then.

>3. Having re-read 404 closely, I am pretty sure that there are not in fact any differences in the set of data objects which qualify as “JSON texts” aside from 404's greater permissiveness already noted. So
> I'm dubious of the need for any future work.

I hope we never need to do any future work.

>​No, it still falls massively short of the very explicit and clear definition of the term “normative reference”.  
>
>
>I’m sticking with my suggestion that if it is absolutely necessary to insert a normative reference, we need language acknowledging that, while this reference does not meet the usual criteria for that sort of
> reference, we are inserting one anyhow because [X].   I think Joe was starting to suggest a value for [X], but I'm pretty sure we can do better.  I'll write a note with some suggestions.

I'm completely ok with language to this effect.  And yes, the text I provided was meant entirely as a starting point, to be picked apart and replaced with something good.  Sometimes a strawman is nice to have so that *something* can be set on fire.

-- 
Joe Hildebrand