Re: Next Steps on JSON + Proposed TAG Resolution

On Oct 18, 2013 11:02 AM, "Tim Bray" <tbray@textuality.com> wrote:
>
> Based on my current understanding, I would argue, in the IETF context,
against making such a change. Here’s why:
>
> - I don’t see any benefit to the reader of any spec in sending them to
look somewhere else unless doing so conveys valuable new information, and
404 doesn’t.
>
> - There are now 4 places that specify the syntax of JSON: json.org,
RFC4627, EcmaScript 5.1, and now Ecma 404.  They all agree, as anyone can
see by observing the success of JSON in the wild. The syntax of JSON has in
fact been entirely stable for over a decade, it interoperates very well,
and there is no disagreement on the subject except about the
very-well-documented restriction introduced in RFC4627 on the top-level
constructs.  I see no evidence to support the assertion that any of these
are any more canonical than any of the others.
>
Doug probably controls json.org, it could pretty easily be updated to cite
and link to 404.

> - The claim that a mini-spec rushed out in late 2013 without any
consultation outside an Ecma committee is the single canonical definition
for a ubiquitous Internet data format that’s been stable for over a decade:
Counter-intuitive and lacks supporting evidence.
>
> - The notion that any particular standards group has a claim to
“ownership” of JSON: Offensive, because JSON belongs to its community of
users.
>
> - Of the many specifications of JSON, I don’t think Ecma 404 is the best.
First, railroad diagrams are less helpful to implementers than ABNF.
Second, obvious mistakes like the first paragraph of section 9 don’t
inspire confidence that it’s received an adequate level of peer  review.
Third, compared to EcmaScript 5.2 section 6, it lacks the careful attention
to detail about what it means by terms such as “character”,  instead
asserting (surprisingly) that a string is a sequence of “Unicode code
points” which strictly speaking would disqualify {"a":"\uDEAD"} since
U+DEAD isn’t a  code point; JSON as she are spoke allows “\uDEAD” and
trying to retroactively fix this is inappropriate.
>
> - There has been an IETF RFC for some number of years that defines the
term “JSON Text” and restricts its usage to arrays/objects. Implementors
have felt entitled to ship software based on that language and it’s hard to
justify either removing or ignoring it.
>
> - I hear arguments that unless everyone defers to one spec, it opens the
door to interoperability problems. I don’t believe them. JSON as it exists
has excellent interoperability and nobody is trying to change it.  The ways
to avoid the small number of corner-case interop problems are well
understood (and carefully documented in the 4627bis draft).
>
>
> On Thu, Oct 17, 2013 at 12:39 PM, Appelquist Daniel (UK) <
Daniel.Appelquist@telefonica.com> wrote:
>>
>> Hia folks --
>>
>> Thanks for being a part of today's call.
>>
>> Regarding our discussion today on JSON, which I though twas very fruitful
>> in terms of clarifying the positions involved: it sounds like if we want
>> to influence the work in IETF that is imminently going to IETF last call
>> that we need to move quickly. I suggest that we should do so on the basis
>> of a TAG resolution. In order to move quickly on this I would like to
>> suggest that we craft this resolution and approve it in email rather than
>> waiting for the next f2f.
>>
>> My straw man proposed resolution is based on my suggestion which I heard
>> Doug Crockford also state and which also seemed to be echoed by
Philippe's
>> comments. It would read as follows:
>>
>> --
>> The TAG resolves to request that the IETF JSON working group amend the
>> current working draft of their JSON spec (rfc4627bis) to include a
>> normative reference to the appropriate ECMA published specification
>> (ECMA-404), and to clearly state that ECMA-404 is the authoritative
>> specification with regard to JSON grammar.
>> --
>>
>> Any comments?  Do you think that as a group we can reach consensus on
this
>> or a similarly worded resolution? If so then I think this could form the
>> basis for our collective action, including individual contributions to
the
>> IETF working group, a more fully fleshed out TAG statement on the topic
>> (to be crafted in a similar manner to our other working group feedback)
>> and potentially a liaison communication from the W3C to IETF along these
>> lines.
>>
>> Make sense?  Comments?
>> Dan
>>
>