Subject: [Json] Comments on the proposed charter

From: Mark Nottingham <[email-masked]>
Date: Wed, 20 Feb 2013 12:54:00 +1100

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/

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 19 Feb 2013 18:57:07 -0700

A big +1 to everything Mark said!

On 2/19/13 6:54 PM, Mark Nottingham wrote:
> 
> 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>:
> 
>> 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?
> 
>> 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
> 
> 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
>

---

From: Francis Galiegue <[email-masked]>
Date: Wed, 20 Feb 2013 03:11:59 +0100

On Wed, Feb 20, 2013 at 2:54 AM, Mark Nottingham <[email-masked]> wrote:
[...]
> 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 a…

On the other hand, a working group focussing on JSON alone and only
JSON may fail to see the big picture of how JSON is actually _used_.
As far as I see it, this working group does not aim at standardizing
all of these, but it also needs to know how JSON is used in real life
situations. And as such, it needs to be aware of whatever idea has
been submitted as an I-D, or for that matter any other idea involving
JSON and not the IETF (JSON-RPC comes to mind, but so does SMD,
GeoJSON etc).

So, I disagree: this is not a bad idea. Awareness is needed. The most
clever people in the world, discussing a format, if clueless about
what happens "out there", have no value in steering a format.

-- 
Francis Galiegue, [email-masked]
Try out your JSON Schemas: http://json-schema-validator.herokuapp.com

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 20 Feb 2013 13:12:57 +1100

There are ways to be aware of how JSON will be used without taking responsibility for defining those uses.

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 19 Feb 2013 18:22:39 -0800

> There are ways to be aware of how JSON will be used without taking responsibility for defining those uses.

<repeatedly mashing the Like button>

--Paul Hoffman

---

From: "Matt Miller (mamille2)" <[email-masked]>
Date: Wed, 20 Feb 2013 02:28:57 +0000

> There are ways to be aware of how JSON will be used without taking responsibility for defining those uses.

THIS

- m&m

Matt Miller < [email-masked] >
Cisco Systems, Inc.

> _______________________________________________
> json mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/json

---

From: Francis Galiegue <[email-masked]>
Date: Wed, 20 Feb 2013 03:47:42 +0100

> There are ways to be aware of how JSON will be used without taking responsibility for defining those uses.

And that is what I said exactly. Your initial wording let the
impression that this working group SHOULD NOT care about the existing,
concrete uses of JSON.

And this is where I disagree. They SHOULD care. Not steer, but care.

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 19 Feb 2013 19:58:14 -0700

On 2/19/13 7:47 PM, Francis Galiegue wrote:
>> There are ways to be aware of how JSON will be used without
>> taking responsibility for defining those uses.
>> 
> 
> impression that this working group SHOULD NOT care about the
> existing, concrete uses of JSON.
> 

It's not about caring, it's about the working group's contract with
the IESG and the IETF community at large. It's true that the
individuals working on base specs in the JSON WG (if formed) will
probably care about various uses of JSON. It does not follow that it's
best to work on applications of JSON in the same venue as the base specs.

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/

---

From: Francis Galiegue <[email-masked]>
Date: Wed, 20 Feb 2013 04:04:21 +0100

On Wed, Feb 20, 2013 at 3:58 AM, Peter Saint-Andre <[email-masked]> wrote:
[...]
> best to work on applications of JSON in the same venue as the base specs.

Yes, I agree with that too. My argument is that working on the base
specifications without an awareness of how these existing base
specifications are used is shortsighted.

I may have misinterpreted what Mark said, but this is the impression I
had when reading that part of his first answer.

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 19 Feb 2013 20:12:28 -0700

On 2/19/13 8:04 PM, Francis Galiegue wrote:
> On Wed, Feb 20, 2013 at 3:58 AM, Peter Saint-Andre
> <[email-masked]> wrote: [...]
>>> 
>> It's not about caring, it's about the working group's contract
>> with the IESG and the IETF community at large. It's true that
>> the individuals working on base specs in the JSON WG (if formed)
>> will probably care about various uses of JSON. It does not follow
>> that it's best to work on applications of JSON in the same venue
>> as the base specs.
>> 
> 
> Yes, I agree with that too. My argument is that working on the
> base specifications without an awareness of how these existing
> base specifications are used is shortsighted.
> 
> I may have misinterpreted what Mark said, but this is the
> impression I had when reading that part of his first answer.

Francis, in case you are new to the IETF, please be aware that IETF
Working Groups are not formed lightly and tend to be quite tightly
scoped so that they are able to sustain the energy and focus necessary
to complete their work in a reasonable amount of time. I don't think
anyone would disagree with the sentiment that it makes sense to define
the base specs with the uses of JSON in mind. However, individuals who
are active in the working group can maintain that awareness without
adding a lot of additional deliverables to the working group's charter.

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/

---

From: Francis Galiegue <[email-masked]>
Date: Wed, 20 Feb 2013 04:25:03 +0100

On Wed, Feb 20, 2013 at 4:12 AM, Peter Saint-Andre <[email-masked]> wrote:
[...]
> adding a lot of additional deliverables to the working group's charter.

I am indeed new, and as such may have overreacted. I am fully aware
that a working group has to restrict itself to a tight scope, it is
only natural that it must do so.

As such, I may have overreacted and apologize for the noise.

Please forgive me,

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 19 Feb 2013 20:30:58 -0700

On 2/19/13 8:25 PM, Francis Galiegue wrote:
> On Wed, Feb 20, 2013 at 4:12 AM, Peter Saint-Andre
>> Francis, in case you are new to the IETF, please be aware that
>> IETF Working Groups are not formed lightly and tend to be quite
>> tightly scoped so that they are able to sustain the energy and
>> focus necessary to complete their work in a reasonable amount of
>> time. I don't think anyone would disagree with the sentiment that
>> it makes sense to define the base specs with the uses of JSON in
>> mind. However, individuals who are active in the working group
>> can maintain that awareness without adding a lot of additional
>> deliverables to the working group's charter.
>> 
> 
> I am indeed new, and as such may have overreacted. I am fully
> aware that a working group has to restrict itself to a tight scope,
> it is only natural that it must do so.
> 

There is no need to apologize or ask for forgiveness. The IETF is a
strange alternate universe and it takes a while to adjust to your new
surroundings. You're doing fine! ;-)

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/

---

From: SM <[email-masked]>
Date: Thu, 28 Feb 2013 17:00:13 -0800

>frameworks that use JSON?

I agree with what Mark wrote.  This ends up creating social issues 
which affect other work.

Regards,
-sm