On 08/12/2013, at 16:26, Carsten Bormann wrote:
> 
> * Way forward
> 
> As always, only the chairs can speak for the JSON WG, and even they
> need to confirm any needed consensus in the WG beforehand.  But I
> think I can say that we are still only guessing what TC39 is trying to
> achieve with the sudden creation of ECMA-404.  I think we need to have
> a frank discussion about the objectives of further work on JSON.  The
> JSON WG has a charter that defines its objectives, which is focusing
> on stability and interoperability.  I'd like to understand TC39's
> objectives with respect to JSON, so we can find out whether there is
> common ground or not.


Here's the message from the very same inventor of JSON telling exactly what's ECMA-404 "trying to achieve". Hope it helps:


Begin forwarded message:

> From: Douglas Crockford <douglas at crockford.com>
> Date: 13 de junio de 2013 17:50:33 GMT+02:00
> To: "json at ietf.org" <json at ietf.org>
> Subject: [Json] Two Documents
> content-type: text/plain; charset="us-ascii"; Format="flowed"
> 
> The confusion and controversy around this work is due to a mistake that I
> made in RFC 4627. The purpose of the RFC, which is clearly indicated
> in the title, was to establish a MIME type. I also gave a description of
> the JSON Data Interchange Format. My mistake was in conflating the two,
> putting details about the MIME type into the description of the format. My
> intention was to add clarity. That obviously was not the result.
> 
> JSON is just a format. It describes a syntax of brackets and commas that
> is useful in many contexts, profiles, and applications. JSON is agnostic
> about all of that stuff. JSON shouldn't even care about character encoding.
> Its only dependence on Unicode in the hex numbers used in the \u notation.
> JSON can be encoded in ASCII or EBCDIC or even Hollerith codes. JSON can
> be used in contexts where there is no character encoding at all, such as
> paper documents and marble monuments.
> 
> There are uses of JSON however in which such choices matter, and where
> behavior needs to be attached to or derived from the syntax. That is
> important stuff, and it belongs in different documents. Such documents
> will place necessary restrictions on JSON's potential. No such document
> can fit all applications, which causes much of the controversy we've seen
> here. One size cannot fit all. JSON the format is universal. But real
> applications require reasonable restrictions.
> 
> So we should be working on at least two documents, which is something we have
> discussed earlier. The first is The JSON Data Interchange Format, which is
> a simple grammar. The second is a best practices document, which recommends
> specific conventions of usage.
> 
> _______________________________________________
> json mailing list
> json at ietf.org
> https://www.ietf.org/mailman/listinfo/json

On 08/12/2013, at 16:26, Carsten Bormann wrote:
> # Way forward
> 
> As always, only the chairs can speak for the JSON WG, and even they
> need to confirm any needed consensus in the WG beforehand.  But I
> think I can say that we are still only guessing what TC39 is trying to
> achieve with the sudden creation of ECMA-404.  I think we need to have
> a frank discussion about the objectives of further work on JSON.  The
> JSON WG has a charter that defines its objectives, which is focusing
> on stability and interoperability.  I'd like to understand TC39's
> objectives with respect to JSON, so we can find out whether there is
> common ground or not.


Here's the message from the very same inventor of JSON telling exactly what's ECMA-404 "trying to achieve". Hope it helps:

Begin forwarded message:

> From: Douglas Crockford <douglas at crockford.com>
>
> Date: 13 de junio de 2013 17:50:33 GMT+02:00
>
> To: "json at ietf.org" <json at ietf.org>
>
> Subject: [Json] Two Documents
> 
> The confusion and controversy around this work is due to a mistake that I
> made in RFC 4627. The purpose of the RFC, which is clearly indicated
> in the title, was to establish a MIME type. I also gave a description of
> the JSON Data Interchange Format. My mistake was in conflating the two,
> putting details about the MIME type into the description of the format. My
> intention was to add clarity. That obviously was not the result.
> 
> JSON is just a format. It describes a syntax of brackets and commas that
> is useful in many contexts, profiles, and applications. JSON is agnostic
> about all of that stuff. JSON shouldn't even care about character encoding.
> Its only dependence on Unicode in the hex numbers used in the \u notation.
> JSON can be encoded in ASCII or EBCDIC or even Hollerith codes. JSON can
> be used in contexts where there is no character encoding at all, such as
> paper documents and marble monuments.
> 
> There are uses of JSON however in which such choices matter, and where
> behavior needs to be attached to or derived from the syntax. That is
> important stuff, and it belongs in different documents. Such documents
> will place necessary restrictions on JSON's potential. No such document
> can fit all applications, which causes much of the controversy we've seen
> here. One size cannot fit all. JSON the format is universal. But real
> applications require reasonable restrictions.
> 
> So we should be working on at least two documents, which is something we have
> discussed earlier. The first is The JSON Data Interchange Format, which is
> a simple grammar. The second is a best practices document, which recommends
> specific conventions of usage.