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

I don't think discussing the history of JSON really helps much at this
stage, decisions were made and it is impractical to change them.

Insisting that the spec preclude future changes is not a choice I would
have made but all that it means in practice is that if you want to revise
the JSON spec, you have to change the name. So instead of there being one
binary version anointed as a clear successor, there are a half dozen
competing specs. Ho hum.

My dog in that particular race is JSON-B which overcomes issues such as the
loss of binary precision round tripping floats etc. and avoids the need to
Base64 encode binary data. It is a proper superset of JSON however so all
legitimate JSON is legitimate JSON-B. What this means is that a
single decoder works for JSON, JSON-B, JSON-C and JSON-D.

https://www.ietf.org/archive/id/draft-hallambaker-jsonbcd-21.html

If the committee had come up with a specification that met my needs, I
would have followed it. They didn't and so I didn't.

On Tue, Jul 19, 2022 at 6:09 PM Rob Sayre <sayrer@gmail.com> wrote:

> 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 <sayrer@gmail.com> 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 <sayrer@gmail.com> 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
>>>
>> _______________________________________________
> Architecture-discuss mailing list
> Architecture-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/architecture-discuss
>