Subject: [Json] How to argue about I-JSON

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

This is an attempt to leap in front of the debate, use the take-aways from
the very useful London f2f, and make our time arguing about I-JSON
maximally
​productive
.  There are plenty of bikesheds out there, but I think the number of
useful arguments is limited and the issues in them pretty clear.

Argument 1 - Media types?

Should there be an I-JSON media type, or a application/*+i-json suffix?
 draft i-json-01 calls for it, but this is at best controversial.  My
suggestion is that people who still think this is a good idea
​need to speak up.  (I won’t.)

Argument 2 - Top-level

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​; anyone who thinks
that is a good idea should speak up. (I won’t.)

Argument 3 - Unicode

draft-i-json-01 excludes the use of, and I quote, “Surrogates or
Noncharacters”.   Is that the right use of Unicode nomenclature?  This
really matters and I think it’s OK now, but first-class Unicode lawyering
is required here.

Argument 4 - Software behavior

Section 3 of draft-json-01 implies draconian error handling - when a
message is specified to be i-json but the receiver finds, for example, a
dupe key, it is required to halt and catch fire. There’s a chance that this
will be interpreted as “tbray poisons JSON with XML draconianism”. People
with alternate language should suggest it. (I probably won’t argue this one
either way.)

Argument 5 - Numbers

draft-i-json-01 says that you MUST not put in a string representing a
number with greater precision/magnitude than IEEE754 doubles can support.
I think this is a good idea but I'm a little nervous because I’ve never
written the code, if this is unreasonably hard at either the sending or
receiving end someone should  say so.

...... aaaaaaand, that’s all folks.   I’m optimistic that we can zero in on
this one quickly.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 28 Apr 2014 14:53:14 -0400

On Mon, Apr 28, 2014 at 2:16 PM, Tim Bray <[email-masked]> wrote:
> the very useful London f2f, and make our time arguing about I-JSON maximally
> productive
> .  There are plenty of bikesheds out there, but I think the number of useful
> arguments is limited and the issues in them pretty clear.
>
> need to speak up.  (I won’t.)

No, if there is a different media type from JSON then I won't every use it.

> Argument 2 - Top-level
>
> 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; anyone who thinks that is a
> good idea should speak up. (I won’t.)

I can see applications where I want multiple top level objects but not
in Web Services protocols. I can't see a reason to exchange more than
one object per transaction slot.

The one case where I can see an argument for having multiples is log
files. And we had a long argument over that a while back, the
alternatives being

A:  [ {entry1} , {entry2}, {entry3} ]
B:  {entry1} , {entry2}, {entry3}
C:  {entry1}  {entry2} {entry3}

The arguments against being:

A: Cannot be written as an append-only operation. The last ] messes
everything up
B: No particular reason against
C: Isn't a proper JSON encoding

A is obviously a non-starter, so taking these arguments, the best choice is C.

The reason for this became obvious when I tried to actually use a log
file with a JSON structure. Because the thing about log files is that
you often want to jump into the middle of the log and look there.

The problem with option B is that there is no way to tell whether a
coma is a separator of two elements within one entry or two entries.
They both look the same. So there is no way to resynchronize.

The only relevance here is that if we don't need option A then I can't
see much purpose in having an array as a toplevel entry.

But what would make sense is to have a MIME type for a JSON log format
which consists of a sequence of JSON objects that are separated by a
(possibly null) sequence of whitespace entries.

> Argument 5 - Numbers
>
> draft-i-json-01 says that you MUST not put in a string representing a number
> with greater precision/magnitude than IEEE754 doubles can support.   I think
> this is a good idea but I'm a little nervous because I’ve never written the
> code, if this is unreasonably hard at either the sending or receiving end
> someone should  say so.

Seems pointless to me. if you care about precision then you don't want
to use decimal encoding for a binary float.

Probably a better restriction would be to say that reals cannot be
more than X characters long so that the encoder/decoder can know when
to abort.

-- 
Website: http://hallambaker.com/

---

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

> good idea should speak up. (I won’t.)

This is really for indicating schema information in-band.  But we
already rely on indicating format out of band (via MIME type).  I find
in-band schema signalling in JSON to be a bad idea, especially when we
can do it out-of-band anyways.

Question: can schema information be encoded as a parameter to the
application/json media type?

> Section 3 of draft-json-01 implies draconian error handling - when a message
> is specified to be i-json but the receiver finds, for example, a dupe key,
> it is required to halt and catch fire. There’s a chance that this will be
> interpreted as “tbray poisons JSON with XML draconianism”. People with
> alternate language should suggest it. (I probably won’t argue this one
> either way.)

A bigger problem is that this requirement involves changes to existing
parsers to meet it.

Nico
--

---

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

Before the discussions on each topic get too intertwined, the Chairs
would find it more useful to have a separate thread for each of the
topics below.  We ask that you hold off on further comments until the
relevant thread is sent -- which I'm in the process of doing now.

Thanks,

- -- 
- - m&m

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

On 4/28/14, 12:16 PM, Tim Bray wrote:
> This is an attempt to leap in front of the debate, use the
> take-aways from the very useful London f2f, and make our time
> arguing about I-JSON maximally ​productive .  There are plenty of
> bikesheds out there, but I think the number of useful arguments is
> limited and the issues in them pretty clear.
> 
> Should there be an I-JSON media type, or a application/*+i-json
> suffix? draft i-json-01 calls for it, but this is at best
> controversial.  My suggestion is that people who still think this
> is a good idea ​need to speak up.  (I won’t.)
> 
> Argument 2 - Top-level
> 
> 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​;
> anyone who thinks that is a good idea should speak up. (I won’t.)
> 
> Argument 3 - Unicode
> 
> Noncharacters”.   Is that the right use of Unicode nomenclature?
> This really matters and I think it’s OK now, but first-class
> Unicode lawyering is required here.
> 
> Section 3 of draft-json-01 implies draconian error handling - when
> a message is specified to be i-json but the receiver finds, for
> example, a dupe key, it is required to halt and catch fire. There’s
> a chance that this will be interpreted as “tbray poisons JSON with
> XML draconianism”. People with alternate language should suggest
> it. (I probably won’t argue this one either way.)
> 
> Argument 5 - Numbers
> 
> draft-i-json-01 says that you MUST not put in a string representing
> a number with greater precision/magnitude than IEEE754 doubles can 
> support.   I think this is a good idea but I'm a little nervous
> because I’ve never written the code, if this is unreasonably hard
> at either the sending or receiving end someone should  say so.
> 
> ...... aaaaaaand, that’s all folks.   I’m optimistic that we can
> zero in on this one quickly.
> 
> 
> _______________________________________________ json mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/json
>

---

From: John Cowan <[email-masked]>
Date: Mon, 28 Apr 2014 16:03:40 -0400

> ​need to speak up.  (I won’t.)

If you expect JSON and get I-JSON, all is well, so I see no point in
adding a media type or suffix to actual documents.  It would be marginally
useful to indicate that you expect I-JSON, but surely nobody would be
so foolish at this stage as to insist on I-JSON.  So let's not bother
with these formalities until there is a proven need for them (which may
be never).

> that is a good idea should speak up. (I won’t.)

As I understand it, the reason for this restriction was to support the
in-band I-JSON signature.  Since this is now dropped, there is no further
reason not to allow the sending of arbitrary JSON values.

> really matters and I think it’s OK now, but first-class Unicode lawyering

It should say "code points which represent unpaired surrogates or
noncharacters."  The statement "\uDEAD is always illegal" is incorrect;
it is entirely legal in the sequence "\uD800\uDEAD", which represents
U+102AD CARIAN LETTER T.  Rather it should say that "\uDEAD" is illegal
unless preceded by an escape between "\uD800" and "\uDBFF" inclusive.

> receiving end someone should  say so.

Most programming language standards don't require accurate and minimal
external representations of floats, Scheme being the exception.  I think
the existing wording is satisfactory.

-- 
John Cowan          http://www.ccil.org/~cowan        [email-masked]
[P]olice in many lands are now complaining that local arrestees are insisting
on having their Miranda rights read to them, just like perps in American TV
cop shows.  When it's explained to them that they are in a different country,
where those rights do not exist, they become outraged.  --Neal Stephenson