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

Tim Bray <tbray@textuality.com> Mon, 28 April 2014 21:16 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 C9E3B1A07A2 for <json@ietfa.amsl.com>; Mon, 28 Apr 2014 14:16:59 -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 SAMBvdMGvRYF for <json@ietfa.amsl.com>; Mon, 28 Apr 2014 14:16:57 -0700 (PDT)
Received: from mail-vc0-f169.google.com (mail-vc0-f169.google.com [209.85.220.169]) by ietfa.amsl.com (Postfix) with ESMTP id AEDDE1A6FFC for <json@ietf.org>; Mon, 28 Apr 2014 14:16:57 -0700 (PDT)
Received: by mail-vc0-f169.google.com with SMTP id im17so9109195vcb.0 for <json@ietf.org>; Mon, 28 Apr 2014 14:16:56 -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=D4blf9XqnFR5IjxLTTS3hfTjI4hLeH7D4SE7/srdfd4=; b=LWfM2WZVMLRz761+x1+RvITEi1259tFLK846VORZYKkpSeKH5R+LShAza1kNn8doSK WW0RC9+bIvNK/+5Bm9f3ssEIXify9aX2IkBZRbTDi9rra117UVtLFmIwIxnCi6NlgU9I LA2NtdJnX5P/s/m3+8yA3mHOGiUmzTDddz3beBRMR72WnktmB8kWn0omsqXPb5R8nGEY n8ouqbP+kJUaKI9YlFV9SLQu2SDLWuuCuKTFYMvGZMH0bdigaGBhX6Y/8JeuvtMTymyR ggwYgd6BFZ4wZEzRjhPOspJYFhrwsaXnTpKPPdfygeC/ZksiU1K7wDecsnCWTcil5qYv wj4w==
X-Gm-Message-State: ALoCoQl28NacW1SJ1P+ssV+0jy+ZqSCotwgIuNXsrsRIdc4PXQvc5fNms22GznY0E6vRK5XXucHl
X-Received: by 10.58.34.67 with SMTP id x3mr2182116vei.37.1398719816670; Mon, 28 Apr 2014 14:16:56 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.220.98.73 with HTTP; Mon, 28 Apr 2014 14:16:36 -0700 (PDT)
X-Originating-IP: [96.49.81.176]
In-Reply-To: <CAO1wJ5SZrrDcj6DvQwdwYF+ivFiftmXuvdZd-SmuUiFEvdcr4g@mail.gmail.com>
References: <535EB119.4000908@cisco.com> <CAHBU6itycQmqzAuxWyrFZ_v=fHdenm2csyAqtUGGu+vteh6=yQ@mail.gmail.com> <CAK3OfOjeaMLKMgNgJE7Cbr-LW1R5HMWBp3MFZREsZUbeMwwHNA@mail.gmail.com> <CAO1wJ5SZrrDcj6DvQwdwYF+ivFiftmXuvdZd-SmuUiFEvdcr4g@mail.gmail.com>
From: Tim Bray <tbray@textuality.com>
Date: Mon, 28 Apr 2014 14:16:36 -0700
Message-ID: <CAHBU6itZx4zeZXKNHOu+NE52kfnnJ2fPZ6MmAc7OCvdvig_k3g@mail.gmail.com>
To: Jacob Davies <jacob@well.com>
Content-Type: multipart/alternative; boundary=089e013a0d72d030bf04f820d57e
Archived-At: http://mailarchive.ietf.org/arch/msg/json/c2l4W8_zIZWl_bgimKjqkHEh2DY
Cc: Nico Williams <nico@cryptonector.com>, Matt Miller <mamille2@cisco.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: Mon, 28 Apr 2014 21:17:00 -0000

RFC 7159 already says that for interoperability, top level objects should
be objects or arrays.  At the simplest level, if all I-JSON does is forbid
all the things that 7159 calls out as interoperability problems, that would
be good enough for me.  The notion that i-json would *weaken* 7159’s
requirements by allowing a top level object to consist of just true or
"true" seems outlandish to me.

...It’s dawning on me that a piece on MustIgnore and why it’s a big deal
might be useful...


On Mon, Apr 28, 2014 at 2:03 PM, Jacob Davies <jacob@well.com> wrote:

> Requiring an object at the top level breaks the symmetry of JSON,
> rules out many useful applications (or requires a clumsy envelope for
> them), and needlessly conflicts with actual practice. It is solving a
> problem I am not convinced anyone really runs into - using (say) a
> JSON string instead of a JSON object and then oops not being able to
> pass along some extra metadata later (and for some reason HTTP headers
> or some similar mechanism won't work). In fact one of the nice things
> about JSON is that if you change your mind and decide to send objects
> instead of strings in some application you can know that the transport
> will support them; you can even allow older senders to keep sending
> strings, and new ones to send objects, and have the receiver accept
> both. Requiring further future-proofing with top-level objects seems
> very invasive.
>
> On Mon, Apr 28, 2014 at 1:36 PM, Nico Williams <nico@cryptonector.com>
> wrote:
> > On Mon, Apr 28, 2014 at 3:20 PM, Tim Bray <tbray@textuality.com> wrote:
> >> Protocols with messages which are objects are better than other
> protocols,
> >> because they are architecturally friendly to MustIgnore policies.
> >>
> >> Allowing top-level JSON to be a primitive - true, null, 42 - is batshit
> >> crazy for anything the IETF might contemplate, and one of I-JSON’s main
> >> virtues is ruling that out.
> >
> > What if the service outputs JSON texts output by a jq program supplied
> > by the client and applied to server-side data?
> >
> >> I don’t think top-level arrays are actively harmful at the same level,
> but
> >> the MustIgnore is a pretty big value-add, forcing people to sort-of
> >> future-proof themselves even when they haven’t realized why that’s a
> good
> >> idea.
> >
> > Why can't schema changes be communicated out-of-band?  Apps request
> > JSON in a particular schema; servers report the schema when the schema
> > was not requested...
> >
> > I can see the value in recommending the use of top-level objects in
> > general, just not in requiring it.
> >
> > Still, I think if you want to say "so don't use I-JSON", I think
> > that's mostly fine.  The only problem that comes up is the possibility
> > that I-JSON would crowd out JSON to the point where non-I-JSON might
> > not be usable.  I think what I'd want to see there is that JSON
> > parsers should really just have an option as to this, rather than have
> > I-JSON parsers that are not also JSON parsers.
> >
> > Nico
> > --
> >
> > _______________________________________________
> > json mailing list
> > json@ietf.org
> > https://www.ietf.org/mailman/listinfo/json
>