[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 []) 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-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 ([]) by localhost (ietfa.amsl.com []) (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 []) 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 ( by BL2PR02MB323.namprd02.prod.outlook.com ( 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 ([]) by BL2PR02MB307.namprd02.prod.outlook.com ([]) 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, 9 Mar 2014 04:50:05 +0000
Message-ID: <4c3a1d93ddbf4909ba8fac74253230b9@BL2PR02MB307.namprd02.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
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:; 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.