IETF Logo Mail Archive

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

Paul Hoffman <paul.hoffman@vpnc.org> Wed, 21 May 2014 16:05 UTC

Return-Path: <paul.hoffman@vpnc.org>
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 415961A086E for <json@ietfa.amsl.com>; Wed, 21 May 2014 09:05:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.347
X-Spam-Level:
X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] 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 QDATAyoJQj8c for <json@ietfa.amsl.com>; Wed, 21 May 2014 09:05:38 -0700 (PDT)
Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34F581A073F for <json@ietf.org>; Wed, 21 May 2014 09:05:30 -0700 (PDT)
Received: from [10.20.30.90] (50-1-51-90.dsl.dynamic.fusionbroadband.com [50.1.51.90]) (authenticated bits=0) by hoffman.proper.com (8.14.8/8.14.7) with ESMTP id s4LG5QWI039205 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 21 May 2014 09:05:27 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
X-Authentication-Warning: hoffman.proper.com: Host 50-1-51-90.dsl.dynamic.fusionbroadband.com [50.1.51.90] claimed to be [10.20.30.90]
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\))
From: Paul Hoffman <paul.hoffman@vpnc.org>
In-Reply-To: <CAK3OfOjxu-=RLZwcao+zVdvceqidFHXbQmSH2prkKoNqB=6bEw@mail.gmail.com>
Date: Wed, 21 May 2014 09:05:24 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <3CA1A8E2-341B-4E09-AC4F-30E427916F1B@vpnc.org>
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> <ABB2BA00-6A21-4710-A1F5-49D4FB469E8F@vpnc.org> <CAK3OfOig8y5KpYZ86KrMPxrJOYC_hLBew_nmyneHCC2mXX+tag@mail.gmail.com> <537BB89E.2040305@cisco.com> <CAHBU6ivpG_H=UFd1fAQednN3Q2vvJtw5DD150GnRjq+Ar3bbTA@mail.gmail.com> <B8099FF7-F3DF-408B-91A5-5F061AB981D4@vpnc.org> <CAK3OfOjxu-=RLZwcao+zVdvceqidFHXbQmSH2prkKoNqB=6bEw@mail.gmail.com>
To: Nico Williams <nico@cryptonector.com>
X-Mailer: Apple Mail (2.1878.2)
Archived-At: http://mailarchive.ietf.org/arch/msg/json/B3BPYRwvydjVM9bywaOgecJZBHw
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, 21 May 2014 16:05:39 -0000

On May 21, 2014, at 8:48 AM, Nico Williams <nico@cryptonector.com> wrote:

> On Tue, May 20, 2014 at 3:50 PM, Paul Hoffman <paul.hoffman@vpnc.org> wrote:
>> <no hat>
>> 
>> The goal of this document is to maximize interoperability. RFC 4627 and other specs had the rule that JSON texts had to be objects or arrays. Restricting JSON texts *in this profile* maximizes interoperability better than RFC 7159 did.
> 
> Is that so?

Yes. The goal is stated in the abstract and introduction.

>  Why?  

Because that's what the WG wanted.

> Because the earlier RFC also so restricted them?

Only partially. The more important part is that implementations followed the earlier RFC and fall over when they see something different. That's a lack of interop.

> But why should that matter now for a new profile of RFC7159?  

This is feeling circular. To interop with existing implementations, this profile needs to pay attention to what they do. If you don't care about interop, then (a) don't implement I-JSON and (b) propose N-JSON.

> Perhaps
> because interop with RFC4627 implementations is desired?  

Not perhaps: definitely.

> But every
> one of those I've looked at handles non-object/array values at the
> top-level... (granted, I've not looked at all of them).

There were reports that some fell over or processed the other top-level items wrong.

> Anyways, IIUC Tim's proposed restriction is about his preference is
> for an ignore-unknown/unexpected policy for extensibility reasons.

YUI.

--Paul Hoffman

v2.23.0 | Report a Bug | By Email