Re: [Json] I-JSON Tpic #2: Top-Level

Tim Bray <tbray@textuality.com> Wed, 30 April 2014 03:41 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 [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0026E1A09B3 for <json@ietfa.amsl.com>; Tue, 29 Apr 2014 20:41:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level:
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 QaNDGSLKxQTr for <json@ietfa.amsl.com>; Tue, 29 Apr 2014 20:41:00 -0700 (PDT)
Received: from mail-ve0-f175.google.com (mail-ve0-f175.google.com [209.85.128.175]) by ietfa.amsl.com (Postfix) with ESMTP id F2CC01A0849 for <json@ietf.org>; Tue, 29 Apr 2014 20:40:59 -0700 (PDT)
Received: by mail-ve0-f175.google.com with SMTP id oz11so1433354veb.6 for <json@ietf.org>; Tue, 29 Apr 2014 20:40:58 -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:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=q8HzHp9AU9ssNGjIMjEfGVGOgyQc9q4pIgKKqbgfXvU=; b=ehC1ii5tYjtLXJax4wvPWozYCqxSmQMt1M45aVbWxGv72qfecSNy/7v00ENDcWmzR3 deYv4vjtxPAA4wWwJr6p0+PB/GVsjKTfavtALx59+0/c8UXqKW2bXWh1a8RF8ILerio+ y7GedwUXZDdXm4i+Hy+QWFy2zhfpnFA6alo7slDM3unYrme2amOAGc/AFslY40WnGKp9 aDujHmRIUurv1bfdnVT8ecVwa9km0TB53G30e036cpzP2vO6Tsv77zbzhub3j6g4zMzp YBWjZvMC2oKFulin31ffi5GDTfe1jIIASQQj0CJPtouRrToOsx7H9ZVm2LFCurwptlrX mY/Q==
X-Gm-Message-State: ALoCoQm5n7ebftdAdNn480ii6ZzqfsIiGnvGwRNjVZYkLR971U6UmQ4wetyFy/WCpBxsKHv0Nlu0
X-Received: by 10.58.96.36 with SMTP id dp4mr1686915veb.21.1398829258412; Tue, 29 Apr 2014 20:40:58 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.220.98.73 with HTTP; Tue, 29 Apr 2014 20:40:38 -0700 (PDT)
X-Originating-IP: [24.84.235.32]
In-Reply-To: <255B9BB34FB7D647A506DC292726F6E1154581E82F@WSMSG3153V.srv.dir.telstra.com>
References: <535EB119.4000908@cisco.com> <CAHBU6itycQmqzAuxWyrFZ_v=fHdenm2csyAqtUGGu+vteh6=yQ@mail.gmail.com> <255B9BB34FB7D647A506DC292726F6E1154581E82F@WSMSG3153V.srv.dir.telstra.com>
From: Tim Bray <tbray@textuality.com>
Date: Tue, 29 Apr 2014 20:40:38 -0700
Message-ID: <CAHBU6iuqosV91W6CJyow_eaKdCNm_VOairJysuLS8mrWV+HM9g@mail.gmail.com>
To: "Manger, James" <James.H.Manger@team.telstra.com>
Content-Type: multipart/alternative; boundary="089e013a26e60caaac04f83a5150"
Archived-At: http://mailarchive.ietf.org/arch/msg/json/WSJtsgDzRV_3ax3TPB9yiz7ZFTg
Cc: IETF JSON WG <json@ietf.org>
Subject: Re: [Json] I-JSON Tpic #2: Top-Level
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: Wed, 30 Apr 2014 03:41:02 -0000

I’m sorry, but the central idea of I-JSON is to explicitly rule out all the
interoperability problems identified in RFC7159: How to produce
maximally-interoperable JSON.  7159 specifically says that for
interoperability a JSON Text should be an object or array, and the idea of
making I-JSON less constraining totally defeats its purpose.  This is just
not a reasonable direction to be going.

Yes, it’s perfectly clear to any language lawyer that in ECMAScript, 42 is
a first-class JSON text, nobody is disputing this.


On Tue, Apr 29, 2014 at 8:19 PM, Manger, James <
James.H.Manger@team.telstra.com> wrote:

> > Protocols with messages which are objects are better than other
> protocols, because they are architecturally friendly to MustIgnore
> policies.
>
> Perhaps we should say a MustIgnore policy applies to all objects in
> I-JSON; instead of merely making a MustIgnore policy possible via a
> somewhat tangential rule that the top-level must be an object.
>
> --
> James Manger
>