Subject: [Json] Topic #4: Software Behavior

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

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

If you have suggestions for better text -- or other comments/concerns
on this language -- please respond to this thread with your
suggestions or 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 15:38:20 -0500

> suggestions or reasoning.

As in my latest reply as to top-level value types, I think this is
best expressed as requiring an option in parser implementations.  IMO
it'd be very bad if I-JSON parsers were to exist that are not also
JSON parsers (at least as an option) and which might then crowd out
JSON.

Nico
--

---

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

Draft language would be helpful.

On Mon, Apr 28, 2014 at 1:38 PM, Nico Williams <[email-masked]>wrote:

> _______________________________________________
> json mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/json
>

---

From: Jacob Davies <[email-masked]>
Date: Mon, 28 Apr 2014 13:52:10 -0700

It seems to me that all the requirements of the I-JSON profile (which
I think is a good idea) are to be satisfied at the emitting end. The
reading end can be I-JSON compliant, but the whole point is that any
old JSON parser is very likely to be able to read I-JSON, isn't it?

With no separate media type and no in-band marker, how can an parser
possibly know it is looking at an I-JSON document? Therefore how can
the compulsory error-handling behavior be specified? Or is the idea
that an I-JSON parser is this strict about *all* JSON documents? In
which case, this is essentially an effort to get the common
understanding of "normal JSON" to be identical with I-JSON since
I-JSON parsers will reject some legal JSON documents (which is true of
any parser of course). Again I think that's probably a good idea as
far as numbers & duplicate keys & illegal escapes are concerned.

---

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

My mental model is that some working group, for example over in JOSE, says
“messages MUST be I-JSON” and then people who are implementing the code
that receives such messages tells the JSON library to go into i-json mode.

---

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

> a dupe key, it is required to halt and catch fire. There's a chance

The current text is fine. It correctly sets the expectations for emitters about receivers that require I-JSON. Weakening the text will simply make draconian parsers seem like the bad actors.

--Paul Hoffman

---

From: Stefan Drees <[email-masked]>
Date: Wed, 30 Apr 2014 08:05:01 +0200

Am 29.04.14 19:29, schrieb Paul Hoffman:
> The current text is fine. It correctly sets the expectations for
> emitters about receivers that require I-JSON. Weakening the text will
> simply make draconian parsers seem like the bad actors.

+1 from my side