Subject: [Json] I-JSON Outstanding AD Issues: Numbers

From: ⌘ Matt Miller <[email-masked]>
Date: Tue, 2 Dec 2014 11:01:25 -0700

Hello all,

In evaluating draft-ietf-json-i-json-03, our AD raised a number of
concerns.  While most have been addressed in -04, some of the issues
regarding numbers where left unclear.  One issue is the use of "MUST
NOT expect" (which is now "cannot expect" in -04) and "MUST NOT
assume" in Section 2.2. Numbers; our AD believes the current text is
not direct enough guidance for implementers.

The text in question is:

   Software which implements IEEE 754-2008 binary64 (double precision)
   numbers [IEEE754] is generally available and widely used.
   Implementations which generate I-JSON messages MUST NOT assume that
   receiving implementations can process numeric values with greater
   magnitude or precision than provided by those numbers.  I-JSON
   messages SHOULD NOT include numbers which express greater magnitude
   or precision than an IEEE 754 double precision number provides, for
   example 1E400 or 3.141592653589793238462643383279.

   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.

   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.

While there was much discussion, there is no clear consensus from the
previous round of discussion.  This issue still needs some resolution,
however.

To that end, the questions to the Working Group are:

1) Is the current text acceptable?

2) If the current text is *NOT* acceptable, is changing "MUST NOT
assume" and "MUST NOT expect" to "cannot assume" and "cannot expect"
(respectively) acceptable?

3) None of the above are acceptable, If what specific text would be?

Thank you,

- -- 
- - m&m

Matt Miller

---

From: Tim Bray <[email-masked]>
Date: Tue, 2 Dec 2014 22:21:10 -0800

On Tue, Dec 2, 2014 at 10:01 AM, ⌘ Matt Miller <[email-masked]> wrote:

> ​​
> ​​
> ​​

​Either “cannot” or “MUST NOT” is perfectly acceptable, and I think arguing
over this choice is not a productive use of our time.
​​

> ​​
​​

> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
> Comment: GPGTools - https://gpgtools.org
>
> iQEcBAEBCgAGBQJUff51AAoJEDWi+S0W7cO1Zb4H/RD01n6gdunhtU4m8t60vU62
> TuY93PJ0XgXWHu0UkE8Kc3+VTDsg2GxegKloLsXqNzbPt3OMa3DivBhTPADI88AK
> y1hMELlOOPk6Ie8GNMaDx52DIkiolApIZdDrPGUZTG95SvmqIc6sCr4BH7EDZptW
> 7to74d+rhKGK689lM9p8XZ6m5t9B9m4gKcyrIWv6UqnRGU2b1onFKf4izD/EJpah
> bXaac6qB79pDzsqFTLCALdMrtoYJtmoS1dP8V7a7FDaRoWkRF7iLHLTKN6ZKmuXN
> tXzU8uFela6OsImfl0X7E5PLzy+6c0DGO1EhOeGzmI9pYnL8XbLACwdTI8aXU98=
> =GJUY
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> json mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/json
>

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

---

From: ⌘ Matt Miller <[email-masked]>
Date: Thu, 18 Dec 2014 12:19:15 -0700

Hello all,

It has been a couple of weeks since the question on Numbers was posed.
 So far, the responses (including those from the original discussion)
appear to be in favor of substituting "MUST NOT assume"/"MUST NOT
expect" with "cannot assume"/"cannot expect".

Unless anyone has strong objections, the editor should submit a
revised I-D with the suggested change.

Thanks,

- -- 
- - m&m

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