Subject: [Json] FYI ECMA, W3C, IETF coordination on JSON

From: Larry Masinter <[email-masked]>
Date: Tue, 8 Oct 2013 07:47:22 -0700

IETF JSON members might want to review

http://www.w3.org/2001/tag/2013/10/02-minutes.html#item03

a report and discussion of (some members of) TC39 and the W3C TAG on the IETF activities around JSON.

---

From: Tim Bray <[email-masked]>
Date: Tue, 8 Oct 2013 08:31:19 -0700

Oh joy, dueling specs.  That’s so 1999.

On Tue, Oct 8, 2013 at 7:47 AM, Larry Masinter <[email-masked]> wrote:

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

---

From: "Peter F. Patel-Schneider" <[email-masked]>
Date: Tue, 08 Oct 2013 08:51:09 -0700

I was trying to find the TC39 "stable standalone draft" for JSON that is 
mentioned by YK. Does anyone know where that is? There also doesn't appear to 
be a pointer to the "proposed JSON standard to be submitted to Ecma" that Doug 
Crockford presented to the July TC39 meeting. Does anyone know where that is?

I also note that there was no pushback at the W3C TAG on "ECMAScript [...] 
defines parsing and serialization [for JSON]".

peter

On 10/08/2013 08:31 AM, Tim Bray wrote:
> On Tue, Oct 8, 2013 at 7:47 AM, Larry Masinter <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     [email-masked] <mailto:[email-masked]>

---

From: Allen Wirfs-Brock <[email-masked]>
Date: Tue, 8 Oct 2013 09:01:54 -0700

The draft was approved by a letter ballot of the Ecma General Assembly.  It is now available as Ecma-404:

see http://www.ecma-international.org/publications/standards/Ecma-404.htm 

Allen

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 8 Oct 2013 18:11:27 +0200

> http://www.w3.org/2001/tag/2013/10/02-minutes.html#item03

This record demonstrates a significant need for outreach and education.
The conversation does not seem to benefit at all from the information that the IETF JSON WG has been able to assemble.

Grüße, Carsten

---

From: "Peter F. Patel-Schneider" <[email-masked]>
Date: Tue, 08 Oct 2013 09:37:41 -0700

What is the relationship (supposed to be) between this standard and the JSON 
MIME type?  As far as I can tell they cover precisely the same ground, except 
for interoperability warnings and admonitions.

peter

---

From: John Cowan <[email-masked]>
Date: Tue, 8 Oct 2013 12:42:19 -0400

> The draft was approved by a letter ballot of the Ecma General Assembly.  It is now available as Ecma-404:

Almost all of it is derived directly from the RFC, with some editorial
cleanup.  The Introduction, however, is new.  I reproduce it here in case
the Editor wishes to mine it for anything:

    JSON is a text format that facilitates structured data interchange
    between all programming languages. JSON is syntax of braces,
    brackets, colons, and commas that is useful in many contexts,
    profiles, and applications.  JSON was inspired by the object
    literals of JavaScript aka ECMAScript as defined in the ECMAScript
    Language Specification, third Edition [1]. It does not attempt
    to impose ECMAScript’s internal data representations on other
    programming languages. Instead, it shares a small subset of
    ECMAScript’s textual representations with all other programming
    languages.

    JSON is agnostic about numbers. In any programming language,
    there can be a variety of number types of various capacities
    and complements, fixed or floating, binary or decimal. That
    can make interchange between different programming languages
    difficult. JSON instead offers only the representation of numbers
    that humans use: a sequence of digits. All programming languages
    know how to make sense of digit sequences even if they disagree
    on internal representations. That is enough to allow interchange.

    JSON text is a sequence of Unicode code points. JSON also depends
    on Unicode in the hex numbers used in the \u escapement [sic]
    notation.

    Programming languages vary widely on whether they support objects,
    and if so, what characteristics and constraints the objects
    offer. The models of object systems can be wildly divergent
    and are continuing to evolve. JSON instead provides a simple
    notation for expressing collections of name/value pairs. Most
    programming languages will have some feature for representing
    such collections, which can go by names like record, struct,
    dict, map, hash, or object.

    JSON also provides support for ordered lists of values. All
    programming languages will have some feature for representing such
    lists, which can go by names like array, vector, or list. Because
    objects and arrays can nest, trees and other complex data
    structures can be represented. By accepting JSON’s simple
    convention, complex data structures can be easily interchanged
    between incompatible programming languages.

    JSON does not support cyclic graphs, at least not directly. JSON
    is not indicated for applications requiring binary data.

    It is expected that other standards will refer to this one,
    strictly adhering to the JSON text format, while imposing
    restrictions on various encoding details. Such standards may
    require specific behaviours. JSON itself specifies no behaviour.

    Because it is so simple, it is not expected that the JSON grammar
    will ever change. This gives JSON, as a foundational notation,
    tremendous stability. JSON was first presented to the world
    at the JSON.org website in 2001. JSON stands for JavaScript
    Object Notation.

-- 
John Cowan    http://ccil.org/~cowan    [email-masked]
SAXParserFactory [is] a hideous, evil monstrosity of a class that should
be hung, shot, beheaded, drawn and quartered, burned at the stake,
buried in unconsecrated ground, dug up, cremated, and the ashes tossed
in the Tiber while the complete cast of Wicked sings "Ding dong, the
witch is dead."  --Elliotte Rusty Harold on xml-dev

---

From: Jorge Chamorro Bieling <[email-masked]>
Date: Tue, 8 Oct 2013 19:20:20 +0200

That's it. It says all that needs to be said.  And in a language that
anybody can understand. Very good.

---
( Jorge )();

---

From: "Peter F. Patel-Schneider" <[email-masked]>
Date: Tue, 08 Oct 2013 11:26:04 -0700

The paragraph on numbers, see below, seems rather dangerous, as well as being 
incorrect.  The paragraph on strings, also below, ignores all the problems 
with escaped code units that do not represent a Unicode code point.

peter

On 10/08/2013 09:42 AM, John Cowan wrote:
> [...]
> [...]

---

From: Tim Bray <[email-masked]>
Date: Tue, 8 Oct 2013 11:32:13 -0700

On the other hand, the opening paragraph of section 9 makes sure that
you’re really clear about which characters may and may not be placed
between quotation marks.

On Tue, Oct 8, 2013 at 11:26 AM, Peter F. Patel-Schneider <
[email-masked]> wrote:

> The paragraph on numbers, see below, seems rather dangerous, as well as
> being incorrect.  The paragraph on strings, also below, ignores all the
> problems with escaped code units that do not represent a Unicode code point.
>
> peter
>
>

---

From: Jorge Chamorro <[email-masked]>
Date: Tue, 8 Oct 2013 20:43:50 +0200

On 08/10/2013, at 20:26, Peter F. Patel-Schneider wrote:

> The paragraph on numbers, see below, seems rather dangerous, as well as being incorrect.

Is it? Why?

-- 
( Jorge )();

---

From: "Peter F. Patel-Schneider" <[email-masked]>
Date: Tue, 08 Oct 2013 11:58:28 -0700

Yes indeed.  Yes indeed.   The double quote may not appear within quotation 
marks, by a two-to-one vote.

peter

On 10/08/2013 11:32 AM, Tim Bray wrote:
> On the other hand, the opening paragraph of section 9 makes sure that you’re 
> really clear about which characters may and may not be placed between 
> quotation marks.
>
>
> On Tue, Oct 8, 2013 at 11:26 AM, Peter F. Patel-Schneider 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>             The draft was approved by a letter ballot of the Ecma General
>             Assembly.  It is now available as Ecma-404:
>

---

From: "Peter F. Patel-Schneider" <[email-masked]>
Date: Tue, 08 Oct 2013 12:14:36 -0700

Well, for starters, interchanging non-integers can lead to loss of precision, 
which can be dangerous.  Further, interchanging numbers without some notion of 
the limits of the receiver is also dangerous.

Second, JSON does not only use sequences of digits to represent numbers, and 
there are many JSON numbers that cannot be represented as a sequence of 
base-ten digits.

Third, there are many numbers that humans interchange that cannot be 
represented as finite sequences of digits, even if you allow also a decimal 
point and a negative sign, for example 1/7, pi, and the square root of two.  
(Perhaps the wording in the introduction is meant to allow infinite sequences 
of digits, but then using JSON for interchange is a bit difficult.)  My 
understanding is that limiting the representation of numbers to something like 
the JSON syntax is more of a computer thing than a human thing.

peter

---

From: Brian Kardell <[email-masked]>
Date: Tue, 8 Oct 2013 12:21:58 -0700

On Tue, Oct 8, 2013 at 11:58 AM, Peter F. Patel-Schneider <
[email-masked]> wrote:

> Yes indeed.  Yes indeed.   The double quote may not appear within
> quotation marks, by a two-to-one vote.
>
> peter
>
>
>> [email-masked] <mailto:[email-masked]**>> wrote:
>>
>>         cleanup.  The Introduction, however, is new.  I reproduce it here
>> in
>>         case
So I guess my big question I keep asking myself is this:  Despite the fact
that it didn't involve standards bodies and committees to get out the door
- JSON is really *really* interoperable.  There are potentially some edge
cases, but given its importance to the Web it does seem like the ECMA
version is the most important baseline here.  If we want to make
improvements, why not just invent some other thing - not JSON... Call it
"super json" or "phil" or - just something else...And let that something
else attempt to address perceived problems and make some minor comments
about the ability to parse a subset of it with the standard JSON parsers
that conform to ECMA-404 or something and then go out there and compete and
see if it actually does better.  Maybe it will and we can all go have beers
and laugh about it, but - maybe it won't and at least we don't have to
break things.

-- 
Brian Kardell :: @briankardell

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 8 Oct 2013 21:37:12 +0200

On Oct 8, 2013, at 20:26, "Peter F. Patel-Schneider" <[email-masked]> wrote:

> The paragraph on strings, also below, ignores all the problems with escaped code units that do not represent a Unicode code point.

Actually, no, this point is not ignored at all.

It makes it very clear that JSON is composed of Unicode code points.
UTF-16 only occurs once, where the twelve-character-escape for non-BMP code points is explained.
So that may be one point where following ECMA-404*) might make the work of this WG simpler.

Grüße, Carsten

*) Great numbering :-)
We should try to get RFC 7404 :-)

---

From: Allen Wirfs-Brock <[email-masked]>
Date: Tue, 8 Oct 2013 12:37:43 -0700

On Oct 8, 2013, at 9:37 AM, Peter F. Patel-Schneider wrote:

> What is the relationship (supposed to be) between this standard and the JSON MIME type?  As far as I can tell they cover precisely the same ground, except for interoperability warnings and admonitions.
> 
> peter

I can't speak officially for TC39 but I can give you my personal interpretation of the discussions and consensus that lead to the release of Ecma-404.

JSON is used for many purposes.  All of those uses require at least two agreements between a producer and consumer of JSON text:

1) There must be agreement upon the syntactic structure of JSON text so it can consistently decomposed into its constituent elements. 

2) The must be agreement upon the semantic interpretation of the syntactic elements.

Ecma-404 address the first of these needs.  It specifies the JSON syntax structure for sequences of Unicode code points and nothing more.

In particular, it does not address any issues relating to the semantic interpretation of that syntactic structure.  This includes issues such as the maximum precision of a "JSON number" or even a mathematical interpretation of a JSON numbers.  Semantis also includes any meaning  associated with the "names" of JSON Object name/value pairs including issues of ordering or repetition.  Finally, there are likely to be many domain specific semantic issues  that may be loosely described as the "schema" of a particular JSON text.  The TC39 consensus was that there is no universal semantics that can be applied to all uses of JSON texts.  It is up to produces and consumers to agree upon a semantics.  Perhaps via ad hoc agreements or perhaps via other standards that address specific use cases.  TC39 currently has no plans to develop any additional standards at this semantic level.

There are other situational agreements that may be necessary in order to coordinate a producer and consumer of JSON text.

For example, Ecma-404 defines a syntax over unicode code points.  A producer and consumer may communicate in a manner that does not directly transfer such code points.  In that case, there needs to be agreement upon an transport encoding of JSON text.  Such encodings might place restrictions upon the JSON text it can deal with.  For example, it  might specify an UTF-8 encoding and refuse to encode JSON text that includes unmatched surrogates.  To me, this seems to be where the question of a JSON MIME type lives.  As far as far as I know, nobody has suggested that TC39 should issues a standard relating to this encoding level or concerning the JSON MIME type.  This seems like an appropriate subject area for the IETF.

Another area of coordination relates to the translation of JSON texts to/from language specific data structures.  Use of JSON does not require such a translation (a producer could just directly output syntactically valid JSON text and a consumer could take direct action as it parses a JSON text) but expectations and experience suggest this usage mode to be very common. Translation to/from a syntactically valid JSON text requires the specification of a mapping from the JSON syntactic elements specified in Ecma-404 to language specific data structures.  Such a translation is itself a semantics applied to the JSON syntax.  Like any semantics it may place restrictions on the JSON texts that it will accept or produce.  Ecma-262, the ECMAScript Language Specification, includes the definition of such a mapping of JSON text to ECMAScript language values.  The next edition of Ecma-262 will be updated to normatively reference Ecma-404.  It will continue to impose ECMAScript specific semantic restrictions such as the conversion of JSON number tokens to ECMAScript Number values and a specific interpretation of repeated names within a JSON object.   Ecma-262 doesn't say that this is the only way to translate a JSON text into ECMAScript language values. It simply defines the translation behavior that is provided by the standard ECMAScipt library. Other languages are likely to define there own mappings to/from JSON text.

TC39 internally agreed that the foundation for the use of JSON is the syntactic structure of JSON text and that is the purpose of Ecma-404. There was no consensus (and minimal discussion) concerning encoding or semantic issues (other than the Ecma-262 mapping) or even a consensus on the need/desirability of a single standard addressing semanitic issues.  TC39 is not currently working on additional standards that address those areas and I doubt that this will change in the near future.  If a need emerges addressing a specific use case or application domain that fits within the TC39 charter (just as an example,  using JSON to encode ECMAScript debugging information) then we might start an activity in that area.

Allen

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 8 Oct 2013 12:39:22 -0700

On Oct 8, 2013, at 11:26 AM, Peter F. Patel-Schneider <[email-masked]> wrote:

> The paragraph on numbers, see below, seems rather dangerous, as well as being incorrect.  The paragraph on strings, also below, ignores all the problems with escaped code units that do not represent a Unicode code point.

If you have issues with the spec that was produced by TC39, it would be much better if you brought it up with them directly, not here. Few TC39 members are on this list, and the ECMA procedures are really different than the IETF procedures.

--Paul Hoffman

---

From: "Peter F. Patel-Schneider" <[email-masked]>
Date: Tue, 08 Oct 2013 12:48:46 -0700

I had first thought that JSON was really really interoperable.  Then I saw all 
the problems JSON-LD had with JSON.  Then I looked closer and saw the problems 
in JSON with numbers, and strings, and arrays. Then I said to myself "There 
really is no problem - although the syntax of JSON is too loose, and the 
description is too loose, everyone interprets JSON as if it was transmitting 
ECMAScript values."  Then I realized that this is not the case, and, moreover, 
that even ECMAScript JSON doesn't match the intuitive description of JSON.

So I would say that JSON is only interoperable if you don't care too much 
about interoperability, and you don't hit any of the really ugly corner cases.

So why then is JSON so successful?  Well, it's easy to write, easy to read, 
matches programming language data fairly closely, and either you are both 
producer and consumer or you don't care that your system works correctly all 
the time so you don't care that JSON does not support interoperability.

peter

On 10/08/2013 12:21 PM, Brian Kardell wrote:

[...]
> that it didn't involve standards bodies and committees to get out the door - 
> JSON is really *really* interoperable.  There are potentially some edge 
> and laugh about it, but - maybe it won't and at least we don't have to break 
> things.
>
>
> --

---

From: "Peter F. Patel-Schneider" <[email-masked]>
Date: Tue, 08 Oct 2013 13:01:46 -0700

I think that everyone agrees that JSON text is a sequence of Unicode code 
points, but that's not the issue.  The issue is whether JSON strings represent 
sequences of Unicode characters or something else.

The JSON syntax in ECMA-404 appears to allow "\uDEAD" as a string. What 
Unicode character does this represent?

A similar problem infects JSON numbers.  There is no debate as to the syntax 
of JSON numbers.   However, there is very little guidance on what a JSON 
number represents.  Is -0 the same as 0?  Is -0.0 the same as 0?  Is 
1.10000000000000000000000000000000000000000000001 the same as 1.1?  Is 1E1 the 
same as 10?

peter

---

From: Tatu Saloranta <[email-masked]>
Date: Tue, 8 Oct 2013 13:02:04 -0700

On Tue, Oct 8, 2013 at 12:48 PM, Peter F. Patel-Schneider <
[email-masked]> wrote:

> I had first thought that JSON was really really interoperable.  Then I saw
> all the problems JSON-LD had with JSON.  Then I looked closer and saw

Could you elaborate bit on what kinds of problems there are?

the problems in JSON with numbers, and strings, and arrays. Then I said to
> myself "There really is no problem - although the syntax of JSON is too
> loose, and the description is too loose, everyone interprets JSON as if it
> was transmitting ECMAScript values."  Then I realized that this is not the
> case, and, moreover, that even ECMAScript JSON doesn't match the intuitive
> description of JSON.
>
> producer and consumer or you don't care that your system works correctly
> all the time so you don't care that JSON does not support interoperability.
>
>
I keep hearing all the claims of non-interoperability, but have seen barely
any problems that are actually on JSON data format level.
Almost only one I have seen is the limited numeric range of Javascript wrt
64-bit integers being one of few that has ACTUALLY surfaced.
This based on my 5 years of working on one of most widely used Java JSON
libraries, interacting on mailing lists.
Even discussion on potential issues (such as other concerns regarding
number representation) has been very limited.

Actual problems that are reported for interoperability are almost all
related to higher-level incompatibility: how are Dates translated into JSON
(numeric timestamp or String? Which of ISO-8601 variants?); whether it is a
good idea to translate simple structs into more elaborate ones with
metadata and so on.
But while these are real problems in context of systems that use JSON, none
of these issues is part of JSON the Format specification
In short, I think that these concerns are used in wrong context -- nothing
within syntactic definition, or semantics of simple values JSON has, will
help with these (valid) concerns.

Unless there is some effort to actually quantify ACTUAL syntax-level
interoperability problems encountered, it would be best to consider these
alleged or potential issues. They are not at "well-known fact" level
(except when used ironically to indicate that it's all hear-say & urban
legens).

-+ Tatu +-

>> So I guess my big question I keep asking myself is this:  Despite the
>> fact that it didn't involve standards bodies and committees to get out the
>> door - JSON is really *really* interoperable.  There are potentially some
>> edge cases, but given its importance to the Web it does seem like the ECMA
> ______________________________**_________________
> json mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/json<https://www.ietf.org/mailman/listinfo/json>
>

---

From: Tatu Saloranta <[email-masked]>
Date: Tue, 8 Oct 2013 13:04:55 -0700

On Tue, Oct 8, 2013 at 1:01 PM, Peter F. Patel-Schneider <
[email-masked]> wrote:

> points, but that's not the issue.  The issue is whether JSON strings
> represent sequences of Unicode characters or something else.
>
> A similar problem infects JSON numbers.  There is no debate as to the
> syntax of JSON numbers.   However, there is very little guidance on what a
> JSON number represents.  Is -0 the same as 0?  Is -0.0 the same as 0?  Is 1.
> **100000000000000000000000000000**00000000000000001 the same as 1.1?  Is
> 1E1 the same as 10?
>
>
I thought that earlier discussions converged towards consensus that only
syntactic equivalence would be defined. If so, none of those would be
considered equivalent at level that this specification operates.
This because binding to native types would be out of scope here.

Equality question could/would be tackled at "best practices" document, or
similar higher-level document.

-+ Tatu +-

>>  The paragraph on strings, also below, ignores all the problems with
>>> escaped code units that do not represent a Unicode code point.
>>>

---

From: "Peter F. Patel-Schneider" <[email-masked]>
Date: Tue, 08 Oct 2013 13:04:51 -0700

Yes, agreed.

peter

---

From: Jorge Chamorro <[email-masked]>
Date: Tue, 8 Oct 2013 22:06:21 +0200

On 08/10/2013, at 21:14, Peter F. Patel-Schneider wrote
> Well, for starters, interchanging non-integers can lead to loss of precision, which can be dangerous.  Further, interchanging numbers without some notion of the limits of the receiver is also dangerous.
> 
> Second, JSON does not only use sequences of digits to represent numbers, and there are many JSON numbers that cannot be represented as a sequence of base-ten digits.
> 
> Third, there are many numbers that humans interchange that cannot be represented as finite sequences of digits, even if you allow also a decimal point and a negative sign, for example 1/7, pi, and the square root of two.  (Perhaps the wording in the introduction is meant to allow infinite sequences of digits, but then using JSON for interchange is a bit difficult.)  My understanding is that limiting the representation of numbers to something like the JSON syntax is more of a computer thing than a human thing.

Ok, look: he's done -and very well- what he said should be done:

Begin forwarded message:

> From: Douglas Crockford <[email-masked]>
> Date: 13 de junio de 2013 17:50:33 GMT+02:00
> To: "[email-masked]" <[email-masked]>
> 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.
> 

ECMA-404 is simple, complete, easy to read and extremely clear: excellent.

-- 
( Jorge )();

---

From: Brian Kardell <[email-masked]>
Date: Tue, 8 Oct 2013 13:10:06 -0700

On Oct 8, 2013 3:48 PM, "Peter F. Patel-Schneider" <[email-masked]>
wrote:
>
> I had first thought that JSON was really really interoperable.  Then I
saw all the problems JSON-LD had with JSON.  Then I looked closer and saw
> So I would say that JSON is only interoperable if you don't care too much
about interoperability, and you don't hit any of the really ugly corner
cases.

> So why then is JSON so successful?  Well, it's easy to write, easy to
read, matches programming language data fairly closely, and either you are
both producer and consumer or you don't care that your system works
correctly all the time so you don't care that JSON does not support
interoperability.

And I would simply say "that is an over-statement".  Of course the world
cares about interoperability and JSON is the lingua franca of data that
makes the Web go round every single day.  Problems and opinions are not
necessarily the same thing "JSON should specify X but doesn't" (where X is
something about dates or numbers or schema validation) doesn't mean we
don't make it actually work in the real world to do an astonishing number
of real things.  Breaking things is really where I would draw the line WRT
the language itself personally - parsers just *have* to be able parse what
they did before, pretty much the way they did before or you risk making
things measurably *less* interoperable in the vast majority of cases in the
name of making it more so.

There is absolutely nothing, and I mean *nothing* from being something a
lot *like* JSON, even a superset capable of parsing the basic subset of
today's JSON the same way and turning it into a forward/competitive move.
 It can be as opinionated as you/we want - and there is literally no
problem.

---

From: Tim Bray <[email-masked]>
Date: Tue, 8 Oct 2013 13:10:34 -0700

Thanks for the invitation, but I think that you need one of our co-chairs
there so that we have an authoritative voice to describe what the IETF WG
is mandated to do.

On Tue, Oct 8, 2013 at 12:42 PM, Appelquist Daniel (UK) <
[email-masked]> wrote:

> Hi folks -
>
> On this topic, I will note that I took an action at last week's TAG f2f
> (http://www.w3.org/2001/tag/group/track/actions/836) to invite Tim Bray
> and Doug Crockford to attend a future TAG call to discuss the situation -
> which I had not yet put into action, but which which was intended to be a
> bit of outreach and fact finding on this topic.
>
> So (adding Doug to the to: list) would you be able / interested to join a
> discussion at one of our future TAG calls on this topic?  If so, I suggest
> we devote a whole call to this topic just to put it to bed.  Our regular
> calls are on Thursdays at 18:00 UK / 13:00 US Eastern / 10:00 US Pacific.
>
> East Side / West Side / Peace.
>
> Dan Appelquist
> W3C TAG Co-Chair
>
>
>
> From:  Tim Bray <[email-masked]>
> Date:  Tuesday, 8 October 2013 16:31

---

From: Larry Masinter <[email-masked]>
Date: Wed, 9 Oct 2013 03:13:54 -0700

>  If you have issues with the spec that was produced by TC39, it would be much
> better if you brought it up with them directly, not here.

If, as has been suggested, 4627bis were to normatively reference ECMA-404,

Then, the suitability of ECMA-404, and errors and lacunae of it, should
be discussed *here*. The only reason pushing to TC39 any
discussions of IETF participants' difficulties would be if there
were an explicit plan to update ECMA-404 and make 4627bis
normatively reference that update.

Larry
--
http://larry.masinter.net

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Wed, 09 Oct 2013 12:21:01 +0200

* Allen Wirfs-Brock wrote:
>As far as far as I know, nobody has suggested that TC39 should issues a 
>standard relating to this encoding level or concerning the JSON MIME 
>type.  This seems like an appropriate subject area for the IETF.

Per http://www.ietf.org/mail-archive/web/json/current/msg00267.html ECMA
"would like to jointly publish" the document the IETF JSON WG is making,
and the IETF JSON WG is explicitly chartered towards that end, quoting
<http://tools.ietf.org/wg/json/charters?item=charter-json-2013-05-31.txt>:

  The resulting document will be jointly published as an RFC and by 
  ECMA. ECMA participants will be participating in the working group 
  editing through the normal process of working group participation.  
  The responsible AD will coordinate the approval process with ECMA
  so that the versions of the document that are approved by each body 
  are the same.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Tim Bray <[email-masked]>
Date: Wed, 9 Oct 2013 08:05:40 -0700

>   so that the versions of the document that are approved by each body

Given that empirically, none of this happened, I suppose this paragraph is
no longer operative.  -T

---

From: "John Levine" <[email-masked]>
Date: 10 Oct 2013 01:50:52 -0000

>about interoperability, and you don't hit any of the really ugly corner cases.

JSON is very interoperable if your producer stays away from the corner
cases that have provoked blizzards of recent messages.

It is my impression that in practice, many, perhaps most, applications
do so.  Certainly for most of the stuff I do, the numbers are all
integers and the strings are straightforward Unicode.

R's,
John