Subject: Re: [Json] Revised I-JSON

From: Carsten Bormann <[email-masked]>
Date: Tue, 5 Nov 2013 13:02:19 -0800

>  "MUST be the first member of the object"
> 
> The spec cannot say a "urn:ietf:i-json" member must be first.

Exactly.

(And choosing a member name that starts with “u” almost ensures it will be near the end with some implementations.)

> Section 2.2. Encoding and Characters
> 
>  "SHOULD NOT include code points which identify
>   Control characters (Unicode section 2.4)"
> 
> I hope newline U+000A is acceptable in I-JSON, at least as "\n". Newline is a control character so it clashes with this spec sentence. Similarly with tab; presumably carriage return; probably form feed.

Which newline is the canonical newline?  That would need to be decided.
Alternatively, we could decide I-JSON strings just don’t do newlines.
But either should be *very* explicit.

I agree with I-JSON to rule out tabs and form feeds.

Finally, ceterum censeo:

1e60 is not exactly representable in binary64.
Neither is 1.1.
The problem is not the lack of an exact representation, but reliance
on exact representation where that is not possible.

Grüße, Carsten

---

From: Nico Williams <[email-masked]>
Date: Tue, 5 Nov 2013 16:17:18 -0600

On Fri, Oct 25, 2013 at 03:20:01PM -0700, Tim Bray wrote:
> I revised the I-JSON draft, too late for the Vancouver cutoff.

Oh noes!

> I tried to make it line up as exactly as possible with the 4627bis draft,
> and say little more than “all of those interop problems called out in 4627
> draft, you MUST NOT do those things.”

 - I don't think the self-ID thing is a good idea, and for objects the
   self-id name can't be required to come first (as others have noted).
   If this could work for objects surely it could work for arrays too.
   But I find self-IDs to be intrusive -- I'd have to write code to look
   for them and remove them if present, and possibly alter parser/app
   behavior.

 - "Objects in I-JSON messages MUST NOT have members with duplicate
   names."

   Did you mean that encoders must not emit dups?  And what should
   parsers do if faced with dups?  If nothing is said about what
   encoders and parsers must do then it seems like not a change from
   plain JSON.

 - re numbers: but should parsers be required to handle the full IEEE754
   64-bit double range and precision?  I think so, for I-JSON anyways,
   else this isn't an improvement over plain JSON.

 - Control characters... me too as to why not...

 - In general I-JSON should forbid encoders from producing that which
   you think is bad, and should require some specific parser behavior
   w.r.t. bad inputs.  "MUST NOT trust" is hardly specific enough.

 - Many use-cases can't have a way to signal complaints to a sender that
   their JSON isn't I-JSON.

Nico
--

---

From: John Cowan <[email-masked]>
Date: Tue, 5 Nov 2013 17:37:41 -0500

>    encoders and parsers must do then it seems like not a change from

Not at all.  Plain JSON just says you may lose if you try this.
MUST NOT means that all bets are off as far as conformance
is concerned.  It licenses the receiver to blow up if it
receives such pseudo-I-JSON, or for that matter to blow up
*the sender*.  See <http://catb.org/jargon/html/E/EOU.html> and
<http://catb.org/jargon/html/N/nasal-demons.html>.

-- 
A rabbi whose congregation doesn't want         John Cowan
to drive him out of town isn't a rabbi,         http://www.ccil.org/~cowan
and a rabbi who lets them do it                 [email-masked]
isn't a man.    --Jewish saying