[Json] Comments on the proposed charter

[Mark Nottingham <[e-mail]>]

I won't be at the JSON BoF. I may be able to participate remotely, but in either case, I thought it'd be helpful to clearly state my position on the current proposal for a charter <http://trac.tools.ietf.org/wg/appsawg/trac/wiki/JSON>:

> The JSON working group will have as its primary task the minor
> revision of RFC 4627 to bring it onto the Standards Track.  As noted
> above, RFC 4627 is a mature and widely cited specification.  The
> initial goal of this work is essentially a reclassification in place,
> with minimal changes.  The working group will review errata and update
> the document as needed to incorporate those, and will correct significant
> errors and inconsistencies, but will keep changes at this stage to a
> minimum.

This is necessary and good; just make sure to involve Crockford, because he has banked up some issues, I believe, and can help illuminate some of the subtleties around the current spec.


> During that work, the working group may collect change requests, and
> may choose to propose a more significant revision of the JSON specification
> if there is rough consensus to do so.  Proceeding with such a revision
> will require AD approval, for which the responsible AD may require a
> recharter to get community and IESG review of the proposal.

I am somewhat concerned about this. If "community" means a self-selecting group of standards nerds / corporate interests / fringe developers, I am violently against it. 

Yes, anyone can come to the table at the IETF, but I question whether the wider JSON community is even aware of this effort. Have we reached out to JSON implementers, for example? Have they joined the list? Do we have representation from the various Open Source frameworks that use JSON?

Let's not fork JSON, please.


> The working group's next priority is to address various proposals for
> JSON extensions and related standards.  The working group will consider
> the proposals and will select those for which there is rough consensus
> to proceed.
> 
> [More needed here.  This is the list of what we're currently aware of.  Do
> we want to leave it open?  Do we want the WG to select which ones to
> proceed with and get the approval of the AD?  Do we want an initial list,
> and have the WG re-charter to add others?]
> 
> Internet Drafts of current JSON-related work:
> - A Language for Rules Describing JSON Content: draft-newton-json-content-rules
> - A Convention for HTTP Access to JSON Resources: draft-pbryan-http-json-resource
> - Home Documents for HTTP APIs: draft-nottingham-json-home
> - JSON Reference: draft-pbryan-zyp-json-ref
> - JSON Predicate: draft-snell-json-test
> - JSON Meta Object: draft-sakimura-json-meta
> - JSON Merge-Patch: draft-snell-merge-patch
> - JSON Activity Streams: draft-snell-activity-streams-type
> - JSON Canonical Form: draft-staykov-hu-json-canonical-form
> - JSON format for iCalendar: draft-kewisch-et-al-icalendar-in-json
> - JSON format for vCard: draft-bhat-vcarddav-json

This is a horrifically, monumentally bad idea. 

Having a catch-all Working Group for anything that happens to use JSON is like having one for anything that happens to use ASCII or UTF-8. It's like shoving XML Schema, XLink, SOAP, Atom, DocBook and XHTML into the same Working Group. 

It's almost a guarantee that the only people who will persevere and follow the work will be those least qualified to do so; the time and attention of implementers and domain experts is valuable, and lumping these together is hard to view as anything but an exclusionary tactic. We already have one catch-all bucket with the APPSAWG, and I have serious concerns about it; let's not repeat the experience. I know that WGs have overhead, and it's hard to have one for each effort, but that's a GOOD thing; it makes sure we don't start work unnecessarily.

Many of the proposals discussed can (and should) go forward as individual, Information drafts, rather than being prematurely given the imprimatur of a standard. Only when there is broad interest and multiple implementations should we invoke the overhead of a WG.

A few things might make sense to do in such a WG, like JSON Schema (provided we have confidence that doing so is a good thing, and we get solid implementer involvement; e.g., I'd want to see a test suite and 3+ implementations tracking the work). Anything domain-specific or exploratory should be right out.


Regardless of all of that - if this work does go ahead, we need a VERY good chair. My suggestion would be someone with these sorts of skills:  
  https://www.youtube.com/watch?v=PWhnZI_GIgg

Cheers,


--
Mark Nottingham   http://www.mnot.net/