Subject: [Json] Ted Lemon's No Objection on draft-ietf-json-i-json-05: (with COMMENT)

From: "Ted Lemon" <[email-masked]>
Date: Thu, 22 Jan 2015 06:39:03 -0800

Ted Lemon has entered the following ballot position for
draft-ietf-json-i-json-05: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-json-i-json/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

This is an editorial nit, which the RFC editor might catch, but they'd
have to know about the distinction between double precision floating
point and fixnums, so I figured I'd just mention it to be safe:

   In particular, an I-JSON sender cannot expect a receiver to treat an
   integer whose absolute value is greater than 9007199254740991 (i.e.,
   that is outside the range [-(2**53)+1, (2**53)-1]) as an exact value.

The "in particular" at the beginning of this sentence has no antecedent,
so it doesn't make sense to say it.   You should just delete "in
particular".   I wonder if there was some text prior to this that got
deleted in a previous revision...

   For applications which require the exact interchange of numbers with
   greater magnitude or precision (one example would be 64-bit
   integers), it is RECOMMENDED to encode them in JSON string values.
   This requires that the receiving program understand the intended
   semantic of the value.

What was the rationale for this?   I don't know of a lot of platforms
that don't support 64-bit integers, so this seems overly restrictive.  
I'm not raising this as a major issue because I am sure there _was_ a
rationale, but I'd like to hear it.

---

From: [email-masked]
Date: Thu, 22 Jan 2015 10:21:43 -0500

Ted Lemon scripsit:

> so it doesn't make sense to say it.

The antecedent is the previous paragraph:  the restriction on integers
is a direct consequence of the restriction to IEEE doubles.

> rationale, but I'd like to hear it.

In a word: JavaScript, because it has only IEEE doubles.

-- 
John Cowan          http://www.ccil.org/~cowan        [email-masked]
"Hacking is the true football."  --F.W. Campbell (1863) in response to a
successful attempt to ban shin-kicking from soccer.  Today, it's biting.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 22 Jan 2015 10:38:23 -0500

> In a word: JavaScript, because it has only IEEE doubles.

D'oh, right.   Javascript's data model is so absurd that its limitations tend of slip out of my recollection when I haven't been using it recently.   I suppose most readers of this document would not fail to see this connection, but it might be worth saying "In particular, since Javascript JSON readers only support floating point, ..."

But that's up to you--I'm fine either way.

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 22 Jan 2015 16:52:18 +0100

On 2015-01-22 16:38, Ted Lemon wrote:
> Javascript's data model is so absurd

Off-IESG comment:

The working group does have a vocal minority that doesn't think all JSON
considerations should be overridden by the quirks of JavaScript.

However, I-JSON specifically is meant to be inclusive, and thus
lowest-common denominator, so there is rough consensus on what it should be.

The collateral damage that is happening however is that I-JSON is
starting to influence other documents that it maybe shouldn't.
E.g. YANG for JSON -- is it really necessary to represent 64-bit YANG
counters as JSON strings instead of numbers?

Grüße, Carsten

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 22 Jan 2015 18:02:30 +0100

> On 22 Jan 2015, at 16:52, Carsten Bormann <[email-masked]> wrote:
> 

Right, and the result is that *all* receiving applications have to parse such string-encoded numbers separately even though their JSON parser is fully capable to do it for them straight away.

Lada

> 
> Grüße, Carsten
> 
> _______________________________________________
> json mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/json

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C

---

From: Tim Bray <[email-masked]>
Date: Thu, 22 Jan 2015 18:15:21 -0800

On Thu, Jan 22, 2015 at 7:21 AM, <[email-masked]> wrote:

> ​​
> ​​
> ​​
> ​​
> ​​

​Yay, grammar fight! I agree with John, but let’s leave it to the RFC
editor.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 22 Jan 2015 21:27:11 -0500

On Jan 22, 2015, at 9:15 PM, Tim Bray <[email-masked]> wrote:
> ​Yay, grammar fight! I agree with John, but let’s leave it to the RFC editor.

No, I didn't complain about it because of a grammar issue.  I complained about it because it didn't make sense.   It's great that John explained it to me, and it's fine with me if you really think everybody who reads this will understand why 64-bit integers are related to 54-bit floating point mantissae, but I am really skeptical that that's so.   It seems to me that part of your intended audience here are people who are _not_ Javascript programmers, and they will not understand how the two paragraphs are connected, because no-one who has not programmed in Javascript would ever imagine that a programming language would only support integers as inexact numbers.

So of course you are free to just leave it the way it is, but please be clear on what you are doing: you are not leaving a grammar error for the RFC editor to think about.

---

From: Tim Bray <[email-masked]>
Date: Sun, 25 Jan 2015 10:09:47 -0800

Fair enough.  There are a few minor edits built up now as a result of this
conversation. Matt, what’s the process, should I do another draft that’s
responsive to them?

On Thu, Jan 22, 2015 at 6:27 PM, Ted Lemon <[email-masked]> wrote:

> No, I didn't complain about it because of a grammar issue.  I complained
> about it because it didn't make sense.   It's great that John explained it
> to me, and it's fine with me if you really think everybody who reads this
> will understand why 64-bit integers are related to 54-bit floating point
> mantissae, but I am really skeptical that that's so.   It seems to me that
> part of your intended audience here are people who are _not_ Javascript
> programmers, and they will not understand how the two paragraphs are
> connected, because no-one who has not programmed in Javascript would ever
> imagine that a programming language would only support integers as inexact
> numbers.
>
> So of course you are free to just leave it the way it is, but please be
> clear on what you are doing: you are not leaving a grammar error for the
> RFC editor to think about.
>
>

-- 
- Tim Bray (If you’d like to send me a private message, see
https://keybase.io/timbray)

---

From: Matthew Miller <[email-masked]>
Date: Sun, 25 Jan 2015 11:15:37 -0700

Yes, go ahead and publish an update when you can.

Thanks,

- m&m
{mobile}