[Json] Re: Old Errata

[Rob Sayre <[e-mail]>]

Yes, the general pattern with some of these rejections is that they do have
a point, but the reason they exist is because you did not need a parser for
JSON initially. It was just eval().

So, yeah, we're stuck with some of these idiosyncrasies.

thanks,
Rob


On Thu, May 28, 2026 at 11:22 AM Tim Bray <[e-mail]> wrote:

> On May 28, 2026 at 11:00:22 AM, Andy Newton <[e-mail]> wrote:
>
>> Hi all,
>>
>> Thanks for going through this...
>>
>> On 5/26/26 1:55 PM, Rob Sayre wrote:
>>
>> 7617 - reject
>>
>>
> I really disagree with all the parts of 7617
>
>
>    1. The first half of the erratum (-0 and +0) is irrelevant,
>    IEEE764-conforming software will Do The Right Thing.  The assertion in 8259
>    that you’ll be interoperable within certain limits is correct.
>    2. The second half of the erratum (JavaScript serializes -0 as “0”) is
>    bad-and-weird JS behavior, but we’re stuck with it, all the libraries and
>    experienced JS devs know about it, and 8259 needn't care.
>    3. The proposed improvement, calling out to “rational numbers”,
>    baffles me. This is about integers and only integers.
>    4. The idea that 8259 should say more about how JSON numbers “should
>    be interpreted” is guaranteed to be controversial and you’d probably need
>    to create a new WG to hash it out, and please just no.
>
>
> -Tim
>
>
> 7650 - not sure (conflicts with 7383)
>>
>>
>> Why wouldn't these be Hold For Document Update to be considered as
>> clarifications if/when RFC8259 is rev'ed?
>>
>> 7673 - reject
>>
>>
>> I need some clue with this one.
>>
>> -andy, ART AD
>>
>