Re: [Json] Kicking Off JSONbis

"Joe Hildebrand (jhildebr)" <jhildebr@cisco.com> Sat, 31 October 2015 02:43 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 C86351B32F2 for <json@ietfa.amsl.com>; Fri, 30 Oct 2015 19:43:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level:
X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 KOm10J0nn3cy for <json@ietfa.amsl.com>; Fri, 30 Oct 2015 19:43:18 -0700 (PDT)
Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 396BF1B32F0 for <json@ietf.org>; Fri, 30 Oct 2015 19:43:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2974; q=dns/txt; s=iport; t=1446259398; x=1447468998; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=1eDvpP45GtzelBGKT5z0TTLGUyP4j0zsEvn0YLRH5/E=; b=WpP1MitvSZ13zq5AmvRKSI9hxWaC/h3uSbTMBVTO2b5pZnzsS/GmCxjr wDMX+2qjfJ1CbqCTvPnI2JHJINJBZ+Q9RrRAUoDIj8S2TByJlKPCPHCbH 5dr17A307iFiRDa2PE+OT7ktBz50dS4009X4yzqDtDNr9N3uF5YhJ4GZo U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0ALAgBHKjRW/5BdJa1egztTbwa/LQENgVohhXgCHIEbOBQBAQEBAQEBfwuENgEBBCMRPRgCAQgaAiYCAgIwFRACBBOIMA2yRpEfAQEBAQEBAQEBAQEBAQEBAQEBAQEVBIEihVWCEIJuhFyDHzGBFAWWQwGIDIUYgVmHY5J9AR8BAUKEBHIBhHaBBwEBAQ
X-IronPort-AV: E=Sophos;i="5.20,221,1444694400"; d="scan'208";a="203528844"
Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by alln-iport-5.cisco.com with ESMTP; 31 Oct 2015 02:43:17 +0000
Received: from XCH-RTP-003.cisco.com (xch-rtp-003.cisco.com [64.101.220.143]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id t9V2hHDk019920 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for <json@ietf.org>; Sat, 31 Oct 2015 02:43:17 GMT
Received: from xch-rtp-001.cisco.com (64.101.220.141) by XCH-RTP-003.cisco.com (64.101.220.143) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 30 Oct 2015 22:42:50 -0400
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; Fri, 30 Oct 2015 22:42:49 -0400
From: "Joe Hildebrand (jhildebr)" <jhildebr@cisco.com>
To: "json@ietf.org" <json@ietf.org>
Thread-Topic: [Json] Kicking Off JSONbis
Thread-Index: AQHQ+wFMLqPttJCICkCj26yPdE/GxJ5p3bGAgADqgACAAAV+gIAAvKQAgAAJCoCABnHOAIAAPJKAgAADbwCAE6qGAA==
Date: Sat, 31 Oct 2015 02:42:49 +0000
Message-ID: <2DB105A8-AB80-4386-915D-D9AD1FBF77AD@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>
In-Reply-To: <56241BFE.5080609@tzi.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/0.0.0.151008
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.24.245.171]
Content-Type: text/plain; charset="utf-8"
Content-ID: <8E35F446418CA241A7E8D67112DCDA76@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/json/lugEXScgwWnIcw3o-oy2Jg1p4RM>
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: Sat, 31 Oct 2015 02:43:19 -0000

(Sorry I didn't get to this until now)

On 10/18/15, 4:23 PM, "json on behalf of Carsten Bormann" <json-bounces@ietf.org on behalf of cabo@tzi.org> wrote:

>I'll leave explaining the conclusion to Tim, but here is the premise:
>
>https://www.ietf.org/iesg/statement/normative-informative.html
>
>In particular: "Normative references specify documents that must be read
>to understand or implement the technology in the new RFC, or whose
>technology must be present for the technology in the new RFC to work."

There's an argument to be made that if you want to interoperate with JSON implementations in browsers, you should probably read ECMA-404.  Several of the places where 7159 says "interoperable in the sense" have specific choices in ECMA-404.

Conversely, serious implementors of ECMA-404 really ought to read 7159bis in order to understand some of the edge cases of interoperability a little better.

The argument that we shouldn't bother with 7159 at all was discussed the last time through.  ECMA-404 only specifies what to do in an ECMAscript environment, and someone needed to specify interoperability for other environments, such as those that don't use UTF-16 code units or 64bit floats as their implementation substrate.

Whether one should bother with ECMA-404 is out of our control, and overcome by events.  Both documents exist, and we need to ensure that they stay in sync going forward.  We could add a statement to section 1.2 such as:


"This document intends to document the exact same data model as described in ECMA-404, which is the main document used by ECMAscript implementors.  Implementors that want to interoperate with ECMAscript implementations (such as web browsers) are advised to also read ECMA-404 to understand any potential interoperability challenges. Any differences in the model described in this document with that described in ECMA-404 are not intentional, and will require the IETF and ECMA to work together to resolve the difference."


That makes the normative reference understandable, and makes clear that the IETF and ECMA are partners in maintaining JSON going forward.

-- 
Joe Hildebrand