IETF Logo Mail Archive

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

Jacob Davies <jacob@well.com> Wed, 30 April 2014 18:45 UTC

Return-Path: <cromis@gmail.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 07DC81A885F for <json@ietfa.amsl.com>; Wed, 30 Apr 2014 11:45:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Level:
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no
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 rDlWjbq6WQHw for <json@ietfa.amsl.com>; Wed, 30 Apr 2014 11:45:21 -0700 (PDT)
Received: from mail-pa0-x22e.google.com (mail-pa0-x22e.google.com [IPv6:2607:f8b0:400e:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id BE1B41A094A for <json@ietf.org>; Wed, 30 Apr 2014 11:45:08 -0700 (PDT)
Received: by mail-pa0-f46.google.com with SMTP id kp14so2389433pab.19 for <json@ietf.org>; Wed, 30 Apr 2014 11:45:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:content-transfer-encoding; bh=F5QoCx4ijp4V5mDo3KEsE8SIskQ8a6Srh8QVpmmcs6E=; b=Iosp98SKZrUpspFi8sTo8nLF8oYVEqnkoovLBOPlSJOLP2l1KiIKlDAwI3YlzjYebG NzHvAAyAu72p6LYli8B9FF1tkKMC7KGwqRVkafiKnRcR0ha6bLJDqcp6+CMa0+xVEHY5 7k9TBiA3WrYDx3vq6mnNApiXau6hFF4AeWnV1WuDnwxE992iPo1pauE43Sq2CwZdWc/D quZUV1JQlFbxnAZQgLmAWSHbLrfF1lKJy78asINVhjGB+rnG91+fBPCMkObmL6yibGfL PqEiZkECyypo0Ux2fd1xyf2HUz5HJ/dM7HEMhTRl4LYsG5T8BKZT+KAkJ77EIDRCWL0k 8gdg==
X-Received: by 10.66.248.228 with SMTP id yp4mr11637568pac.94.1398883506048; Wed, 30 Apr 2014 11:45:06 -0700 (PDT)
MIME-Version: 1.0
Sender: cromis@gmail.com
Received: by 10.70.11.133 with HTTP; Wed, 30 Apr 2014 11:44:45 -0700 (PDT)
In-Reply-To: <CAHBU6iuqosV91W6CJyow_eaKdCNm_VOairJysuLS8mrWV+HM9g@mail.gmail.com>
References: <535EB119.4000908@cisco.com> <CAHBU6itycQmqzAuxWyrFZ_v=fHdenm2csyAqtUGGu+vteh6=yQ@mail.gmail.com> <255B9BB34FB7D647A506DC292726F6E1154581E82F@WSMSG3153V.srv.dir.telstra.com> <CAHBU6iuqosV91W6CJyow_eaKdCNm_VOairJysuLS8mrWV+HM9g@mail.gmail.com>
From: Jacob Davies <jacob@well.com>
Date: Wed, 30 Apr 2014 11:44:45 -0700
X-Google-Sender-Auth: UQ4QLb_H6SYZ61gJI7N4KUUZBBs
Message-ID: <CAO1wJ5R26qr=QpszOom=yW4-LbCb5meaE7wrqB2dDq3E=L3BUg@mail.gmail.com>
To: Tim Bray <tbray@textuality.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/json/WEM68NGZBkpDSN06nJOSSKfhxDU
Cc: "Manger, James" <James.H.Manger@team.telstra.com>, 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 18:45:22 -0000

On Tue, Apr 29, 2014 at 8:40 PM, Tim Bray <tbray@textuality.com> wrote:
> 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.

Well, a lot of people disagree here. I also think the interop advice
regarding top-level objects & arrays in 7159 was silly. It is not a
significant interoperability problem, and in fact requiring that an
"I-JSON profile" parser reject anything but objects and arrays would
make I-JSON the one with the interoperability problem given that
everyone else will happily be exchanging primitives at top-level. The
real interoperability problem with this rule in the original spec was
that everyone ignored it.

v2.23.0 | Report a Bug | By Email