Re: Next Steps on JSON + Proposed TAG Resolution

On Fri, Oct 18, 2013 at 8:07 AM, Brian Kardell <bkardell@gmail.com> wrote:

> Doug probably controls json.org, it could pretty easily be updated to
> cite and link to 404.
>

Confession: Of all the different JSON descriptions, json.org is by far my
favorite.  It’s a brilliant little technical tutorial and I think partially
responsible for JSON’s immense success. -T


> > - 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
> >>
> >
>