[Json] comments on Ihttp://tools.ietf.org/html/draft-bray-i-json-01
Larry Masinter <masinter@adobe.com> Sun, 09 March 2014 04:50 UTC
Return-Path: <masinter@adobe.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 0ECDB1A01E2 for <json@ietfa.amsl.com>; Sat, 8 Mar 2014 20:50:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.831
X-Spam-Level:
X-Spam-Status: No, score=-1.831 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=0.77, SPF_HELO_PASS=-0.001] 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 mF4IdYM78uZo for <json@ietfa.amsl.com>; Sat, 8 Mar 2014 20:50:20 -0800 (PST)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0211.outbound.protection.outlook.com [207.46.163.211]) by ietfa.amsl.com (Postfix) with ESMTP id A09461A01BC for <json@ietf.org>; Sat, 8 Mar 2014 20:50:19 -0800 (PST)
Received: from BL2PR02MB307.namprd02.prod.outlook.com (10.141.91.21) by BL2PR02MB323.namprd02.prod.outlook.com (10.141.91.18) with Microsoft SMTP Server (TLS) id 15.0.893.10; Sun, 9 Mar 2014 04:50:06 +0000
Received: from BL2PR02MB307.namprd02.prod.outlook.com ([10.141.91.21]) by BL2PR02MB307.namprd02.prod.outlook.com ([10.141.91.21]) with mapi id 15.00.0893.001; Sun, 9 Mar 2014 04:50:06 +0000
From: Larry Masinter <masinter@adobe.com>
To: "json@ietf.org" <json@ietf.org>
Thread-Topic: comments on Ihttp://tools.ietf.org/html/draft-bray-i-json-01
Thread-Index: Ac87Ub0Jge6iJa+uS2GWj5EoJw92cw==
Date: Sun, 09 Mar 2014 04:50:05 +0000
Message-ID: <4c3a1d93ddbf4909ba8fac74253230b9@BL2PR02MB307.namprd02.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [204.239.250.1]
x-forefront-prvs: 0145758B1D
x-forefront-antispam-report: SFV:NSPM; SFS:(10019001)(6009001)(428001)(199002)(189002)(93136001)(93516002)(83072002)(65816001)(85852003)(66066001)(46102001)(80022001)(15202345003)(77982001)(59766001)(74316001)(79102001)(76176001)(54316002)(90146001)(220493001)(56816005)(74706001)(74366001)(47736001)(53806001)(54356001)(86362001)(81686001)(51856001)(76482001)(69226001)(76576001)(76796001)(76786001)(50986001)(33646001)(49866001)(83322001)(47976001)(19580395003)(80976001)(81342001)(4396001)(81542001)(63696002)(15975445006)(87936001)(81816001)(2656002)(92566001)(95666003)(74662001)(31966008)(47446002)(74502001)(94946001)(97336001)(85306002)(95416001)(87266001)(97186001)(94316002)(74876001)(21314002)(24736002); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2PR02MB323; H:BL2PR02MB307.namprd02.prod.outlook.com; CLIP:204.239.250.1; FPR:FC40C2D4.9F131710.31D5BF7F.46E5F9ED.20275; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None (: adobe.com does not designate permitted sender hosts)
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: adobe.com
Archived-At: http://mailarchive.ietf.org/arch/msg/json/lfsywbgEgd8WpHwcbyvTDBbZTMI
Subject: [Json] comments on Ihttp://tools.ietf.org/html/draft-bray-i-json-01
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: Sun, 09 Mar 2014 04:50:22 -0000
I have trouble with lots of the normative language in the I-JSON spec. If you're defining a profile, then go ahead and define the set of values that are allowed and define values that generators MUST NOT generate in order to be conforming, and the cases where parsers which are checking for conformance to the profile MUST check. So: numbers: > Implementations which generate I-JSON messages MUST NOT assume that > receiving implementations can process numeric values with greater > magnitude or precision than provided by those numbers. As written, it sounds like a constraint on the mental state of the author of the generating implementation. " MUST NOT assume that the order of object members" I think this is a constraint on receivers of JSON messages, that they MUST process all permutations equivalently. I-JSON has no length limits. Security applications probably need to agree on length limits. ---- Specifications whose messages are specified to be I-JSON messages SHOULD specify the use of a media type of the form "application/XXX+i-json", where XXX is specific to the specification. I argued against application/i-json in the meeting, but it's not in the draft. Is there anyone who still wants it? I see no value to application/XXXX+i-json over application/XXX+json since any application needs to define additional constraaints. For example, i-json has no length limits, while any practical implementation will have some, and security applications that want to insist on consistent behavior will need length limits. Larry -- http://larry.masinter.net
- [Json] comments on Ihttp://tools.ietf.org/html/dr… Larry Masinter