Re: [arch-d] draft-iab-protocol-maintenance / JSON feedback

[Rob Sayre <[e-mail]>]

I got asked about this in private, and found this page:

https://esdiscuss.org/topic/json-parser-grammar#content-6

This is a 2009 email from me to the editor of the ES spec. So, all of the
loose/strict negotiations were actually done in ECMA. This is the key text
in RFC 4627 that the ECMA group ignored: "A JSON parser MAY accept non-JSON
forms or extensions." We all agreed to not do it. That's only 4-5 clients,
but they were popular ones.

I agree that the later IETF documents diverge from the ECMA ones, but this
is because of a disagreement on how much the semantics of JS should
influence JSON, and not the subject of this IAB document. So, that's why
it's a bad example.

thanks,
Rob


On Mon, Jul 18, 2022 at 10:11 AM Rob Sayre <[e-mail]> wrote:

> Hi,
>
> After reading all of these comments, which each contain some correct
> statements, I still think the JSON example is a bad one.
>
> Some corrections, as someone who was in both ECMA, the IETF, and the
> pre-history:
>
> - there are no comments deliberately, as Crockford thought people would
> use them for extensions
> - the number precision issue was widely known (Crockford even designed a
> thoughtful number format called DEC64, he definitely knew)
> - the comma issue was raised by me, but rejected. it wasn't an oversight
> that the process missed
>
> I did manage to get one point across: the design of JSON.stringify makes
> it difficult to produce invalid JSON. The original API let implementations
> insert arbitrary text.
>
> The standardization process was basically: "OK, people like this, but we
> can't have them using eval()".
>
> I also raised the point that JSON necessarily implies ECMA262 semantics
> for hashmaps and other things, in the IETF process (again, rejected, but
> not an oversight).
>
> thanks,
> Rob
>
>
> On Sun, Jul 17, 2022 at 2:56 PM Rob Sayre <[e-mail]> wrote:
>
>> Hi,
>>
>> I'm sympathetic to concerns raised in the document, but I think the JSON
>> example is not a very good one.
>>
>> JSON was deliberately underspecified because it would work most of the
>> time* in languages where typical payloads could get by using an "eval()"
>> function, rather than requiring an implementation at all, JavaScript and
>> Python being the most common. RFC4627 was an after-the-fact production, the
>> problems were already there.
>>
>> So, the JSON case is actually showing that loose specification can drive
>> adoption (like HTML etc). I do not think that's the point you intended to
>> make.
>>
>> thanks,
>> Rob
>>
>> * the problems mentioned in the draft are real, but rare and often not
>> obvious
>>
>