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

From: Matt Miller <[email-masked]>
Date: Mon, 28 Apr 2014 13:50:49 -0600

"draft-i-json-01 says the top level is an object (but doesn’t say
MUST, eek).  I have heard arguments for allowing arrays too."

If you are in favor -- or not -- of restricting the top-level I-JSON
text to only be object (or array / object), please respond to this
thread with your reasoning.

- -- 
- - m&m

Matt Miller < [email-masked] >
Cisco Systems, Inc.

* "How to Argue about I-JSON" <
http://www.ietf.org/mail-archive/web/json/current/msg02775.html >

---

From: Nico Williams <[email-masked]>
Date: Mon, 28 Apr 2014 14:58:48 -0500

> thread with your reasoning.

I am opposed.  The rationale given is that fields can be added to
objects.  Sure, but schemas can be changed in other ways, especially
if there's out-of-band signalling as to schema.

Nico
--

---

From: Tim Bray <[email-masked]>
Date: Mon, 28 Apr 2014 13:20:31 -0700

​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.

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.

So I’d leave it object-only.

On Mon, Apr 28, 2014 at 12:50 PM, Matt Miller <[email-masked]> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
> Comment: GPGTools - https://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQEcBAEBCgAGBQJTXrEZAAoJEDWi+S0W7cO1bjAH/RxLeWEABXMoJEJrw92lYfkP
> bLgoS7TRoSxVdUY9K8SVMEJKHMrY2QrK/aNqhwlpWvIirM70xFUT7Sb40M+Msmm/
> qFZTFfVRdRsnqsd21dciZ6hA4eSDfkP81cIoMn4MiCx8EExZCj7yroWaTor8jNct
> 7BgVCWkom2ENVNOb6JEPFa7LD6hpm/9vx1FHctbDgreJuhsYxY9Uy17h/BjxxwPc
> NkNFbo+OX4Zw6f053cKWbITps/R+IAM57atzJ9PgGpMpN+POQJF/BihnB1qRdUsv
> y8QqQ1s8r47DauWQ0eX4BxgPXeGV+jBqXrtVAzyNq2B7KFkDukf9UVahUaJjwJU=
> =nAfX
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> json mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/json
>

---

From: Nico Williams <[email-masked]>
Date: Mon, 28 Apr 2014 15:36:26 -0500

On Mon, Apr 28, 2014 at 3:20 PM, Tim Bray <[email-masked]> wrote:
> Protocols with messages which are objects are better than other protocols,
> Allowing top-level JSON to be a primitive - true, null, 42 - is batshit

What if the service outputs JSON texts output by a jq program supplied
by the client and applied to server-side data?

> future-proof themselves even when they haven’t realized why that’s a good

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
--

---

From: Jacob Davies <[email-masked]>
Date: Mon, 28 Apr 2014 14:03:57 -0700

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.

---

From: Tim Bray <[email-masked]>
Date: Mon, 28 Apr 2014 14:16:36 -0700

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...

---

From: Matthew Morley <[email-masked]>
Date: Mon, 28 Apr 2014 17:28:29 -0400

> thread with your reasoning.

I am not in favor of restricting the top-level I-JSON text only to be an
object. This would make it stricter than RFC4627/ecma-262 and then stand to
muddy the waters of what the application/json media type currently states.
I don't believe it is a good idea to make this stricter, without a matching
media type, which I think makes this also a non-starter.

I am content to see it as array or object at the top level. Since this
seems to be the current level of accepted use by most people within the
JSON community due to RFC4627.

But, I would greatly prefer that any JSON value be allowed as the top level
item. The requirement that any JSON value be represented within a structure
creates an amount of unneeded indirection and overhead.

If my program intends to set a local value to be the response from another
source. It should not have to know that it must descend into the actual
result to obtain the sources intended value. If both sides agree to send
array/object structures, akin to golang's multiple return values, I
consider this a better practice. But it should not be a requirement, or an
imposed overhead.

Add to this, http://www.ecma-international.org/ecma-262/5.1/#sec-15.12.1.2seems
to define JSON text as any JSON value in contrast with RFC4627. My
reading/understanding of RFC4267/ecma-262 may be incorrect, but my feeling
that restrictions on the top level value should be lifted, not tightened.

-- 
Matthew P. C. Morley

---

From: Nico Williams <[email-masked]>
Date: Mon, 28 Apr 2014 16:28:41 -0500

On Mon, Apr 28, 2014 at 4:16 PM, Tim Bray <[email-masked]> wrote:
> 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

That was a hard-won but-grudging concession to reality.  All encoders
and parser I checked have long had an option to permit scalars at the
top-level; RFC7159 should have required that by default scalars be
accepted at the top-level given that such things are found in the
wild.

I don't really care to re-argue that -- grudging or not, the
concession was all that mattered.  But if we're going to argue about
what I-JSON should do about the top-level based on the fact that the
concession in RFC7159 was grudging, then I guess we'll have to
re-argue this!

But I'd rather focus on why one might want to mandate objects at the
top-level, what to do when one has an array (use text sequences?!),
and what to do when this isn't appropriate ("don't use I-JSON" being
fine, provided we don't end up squeezing out non-I JSON).

Nico
--

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 29 Apr 2014 08:10:01 +1000

On 29 Apr 2014, at 6:20 am, Tim Bray <[email-masked]> wrote:

> 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. 

Is the target audience for I-JSON just the IETF, or anyone who wants a more interoperable profile of JSON?

Regards,

--
Mark Nottingham   http://www.mnot.net/

---

From: Tim Bray <[email-masked]>
Date: Mon, 28 Apr 2014 15:13:21 -0700

My main i-json motivation is application-level protocols, specifically
JOSE-style stuff.  So the IETF would be sort of the canonical user. -T

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 29 Apr 2014 10:27:27 -0700

> MUST, eek).  I have heard arguments for allowing arrays too."

There is no need for any top-level restriction. The restriction doesn't help any capable receiver.

--Paul Hoffman

---

From: "Manger, James" <[email-masked]>
Date: Wed, 30 Apr 2014 13:01:43 +1000

> There is no need for any top-level restriction. The restriction doesn't help any capable receiver.

I agree.

"Almost always use objects for top-level messages" is good advice for designers of new protocols and messages.
"Only accept objects" is horrible advice for developers of JSON parsers and library functions.

JSON has primitives so an "object-only" rule can only work if there is a crystal clear divide between those subsets of a JSON data structure that might be "exchanged" and those subsets that are too low-level to ever need to be "exchanged". There is no such divide.

--
James Manger

---

From: "Manger, James" <[email-masked]>
Date: Wed, 30 Apr 2014 13:19:22 +1000

> 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

---

From: Tim Bray <[email-masked]>
Date: Tue, 29 Apr 2014 20:40:38 -0700

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 <
[email-masked]> 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
>

---

From: "Manger, James" <[email-masked]>
Date: Wed, 30 Apr 2014 15:17:09 +1000

Only allowing objects and arrays at the top level was a cause of interop problems.
It was a bad feature, an unnecessary restriction, that we should not perpetuate. RFC7159 and ECMA-404 have taken a great leap to remove it so I don’t want I-JSON to try to resurrect it.

I would be happy to use a JSON function that: required UTF-8; failed on surrogates; failed on duplicates; ignored element order; failed on integers beyond 2^53; failed on floats with more than 22 digits; failed on invalid JSON (eg trailing commas, comments etc).
I would NOT be happy to use a JSON function that: failed when the top-level isn’t an object.
I want to be happy to use a JSON function if it says it supports I-JSON.

--
James Manger

From: Tim Bray [mailto:[email-masked]]
Sent: Wednesday, 30 April 2014 1:41 PM
To: Manger, James
Cc: IETF JSON WG
Subject: Re: [Json] I-JSON Tpic #2: Top-Level

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.

--
James Manger

---

From: Stefan Drees <[email-masked]>
Date: Wed, 30 Apr 2014 07:53:42 +0200

Yes, please. In OData we investigate suggesting adhering to such a 
constrained JSON (OData JSON Texts are in format JSON always wrapped as 
values of a {"d": VALUE} element. It is nice to be able, to just 
reference I-JSON draft. If we remove that essential constraint, to me it 
would look quite useless or should I say nostalgic :-?

"Stefan"
Am 30.04.14 05:40, schrieb Tim Bray:
> 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
> 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
> <[email-masked]
> <mailto:[email-masked]>> wrote:
>

---

From: Jacob Davies <[email-masked]>
Date: Wed, 30 Apr 2014 11:44:45 -0700

> 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.

---

From: Nico Williams <[email-masked]>
Date: Wed, 30 Apr 2014 14:03:07 -0500

> not a reasonable direction to be going.

Applications that use JSON -or any other encoding system for
structured data- need to agree on schema to begin with.

Yes, it's true that a human can eyeball a JSON text, or a dump of
ASN.1 BER/DER/CER encoded data, or..., and get a pretty good idea of
the meaning of various artifacts.  But by and large it's applications
that consume these things, not humans.  And applications, not being
humans, need to agree on schemata.

Usually schema signalling is done out of band, and you have dropped
your earlier proposal to do I-JSON signalling in-band.  Why do we need
to do anything else at all regarding this?  (That's not rhetorical.  I
want to understand just why we should do what you propose.)

Extensibility of schemata is a separable issue; we should separate it.
 I agree that uses of JSON should generally have a default implied
extensibility rule, a-la modern ASN.1 -- i.e., ignore unknown names in
objects -- all objects most likely.  But that has nothing to do with
the top-level being an object, which is why it's separable.

Nico
--

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 30 Apr 2014 16:42:07 -0700

<no hat>

On Apr 29, 2014, at 8:40 PM, Tim Bray <[email-masked]> 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.  

This is a good point, and one that I forgot when I said "this isn't needed". There are probably some parsers out there that expect the original JSON restriction; given that, repeating the restriction here seems fine.

--Paul Hoffman

---

From: Nico Williams <[email-masked]>
Date: Wed, 30 Apr 2014 19:40:07 -0500

> This is a good point, and one that I forgot when I said "this isn't needed". There are probably some parsers out there that expect the original JSON restriction; given that, repeating the restricti…

Conceding that for the time being, the restriction to repeat was that
JSON texts must be objects or arrays at the top-level, NOT just
objects.

Now, as to whether we should repeat that restriction, given that every
parser I know of at least has an option to permit non-object/array
types at the top-level, I find the interop argument wanting.  If I
know some application uses I-JSON, and if I know I-JSON permits any
type at the top-level (supposing it were to), why would I have any
trouble implementing that with existing parsers?

I haven't carried out an exhausting analysis of existing parsers, and
since I can't -no one can-, I might concede that point even if no one
confirms the existence of any JSON parsers that don't have an option
to permit any type at the top-level.  For now I'm just not buying the
interop argument.

Nico
--