Subject: [Json] Response to Statement from Ecma International TC39

From: "Matt Miller (mamille2)" <[email-masked]>
Date: Thu, 5 Dec 2013 02:57:05 +0000

Hello All,

The JSON Working Group has received a statement from Ecma International's Technical Committee 39 (TC39) regarding draft-ietf-json-rfc4627bis.  The statement can be found at < https://datatracker.ietf.org/documents/LIAISON/liaison-2013-11-25-ecma-tc39-json-ecma-tc39-comment-for-rfc-4727bis-attachment-1.pdf >.

In response, the Chairs and sponsoring Area Director propose to send the following on behalf of the JSON Working Group.  We wish to send the response on December 10.  If there are any serious factual errors in the following response, let us know before then.  Note that we are *not* asking the WG to re-open any of the consensus discussions, simply to see if we misstated anything factual.

Thank you,

-- Paul Hoffman and Matt Miller

-----BEGIN RESPONSE-----
Thank you for your statement of concern about draft-ietf-json-rfc4627bis. The chairs of the IETF's JSON Working Group were not aware of any serious concerns that TC39 had with the update process. Over the past many months, we repeatedly contacted ECMA and TC39 members about the JSON WG and draft-ietf-json-rfc4627bis, but never received any significant reply. We know that some TC39 members joined the JSON WG mailing list but did not voice any process concerns in the WG -- or privately to the WG Chairs -- before or during either of the Last Calls on the document.

In the future, it would probably be useful for Ecma and the IETF to have a formal liaison relationship. We have heard that there were preliminary discussions several months ago, but stopped short of a formal relationship before the JSON Working Group was formed. Formalizing the liaison relationship will help both SDOs communicate with each other and thus avoid late surprises.

As to your specific requests:

- In IETF Last Call, there was consensus to change the definition of "JSON text" in draft-ietf-json-rfc4627bis to match the one in ECMA-404. The latest draft reflects that change. At this point, we believe that there are no syntactic differences between the two specifications.

- The JSON WG decided to change the title of the document to better reflect its content. The current document is much more than a media type registration: it repeats the JSON syntax originally documented in RFC 4627, and has been stable for many years, it is a discussion of the JSON semantics important to freestanding encoders and parsers, it is a discussion of interoperability issues that have been encountered since RFC 4627 and ECMA-262 5th Edition were published, and it is a media type registration. Having a more accurate title on the document will help readers understand its contents and the difference between it and ECMA-404.

- After Ecma published ECMA-404, the JSON WG discussed whether to remove the ABNF version of the JSON syntax that was established in RFC 4627 from draft-ietf-json-rfc4627bis; it was decided not to do so. One reason is that ECMA-404 uses "racetrack pictures" to define the syntax, whereas IETF documents have traditionally used ABNF, and many developers have expressed a strong preference for the ABNF. This might be considered simply a matter of style, but it was deemed important by many WG members. We intend to keep the discussion and reference to ECMA-404 in draft-ietf-json-rfc4627bis, even if Ecma continues to choose not to reciprocate in ECMA-262 6th Edition, because developers reading draft-ietf-json-rfc4627bis might indeed prefer the racetrack pictures.

- A normative reference to ECMA-404 would be premature without a clear and well-understood document management process. Historically, when someone reading an RFC sees a normative reference to one version of another SDO's standards, they tend to think the reference will apply to future versions of that external standard as well. Given the closed process that resulted in ECMA-404, it seems quite possible that Ecma could later make changes to ECMA-404 that would have a negative effect on interoperability from the Internet perspective. When the IETF normatively refers to other standards, it almost exclusively does so to standards that were developed with processes that are open to discussion and contribution by anyone.

If the IETF believed that future development of ECMA-404 would involve a similar kind of open participation as seen with the development of draft-ietf-json-rfc4627bis, it could certainly revisit the topic of a normative reference in any subsequent update. Such a belief could be one of the positive products of a formal liaison relationship between the IETF and Ecma.
-----END RESPONSE-----

---

From: Nico Williams <[email-masked]>
Date: Wed, 4 Dec 2013 22:42:56 -0600

On Thu, Dec 05, 2013 at 02:57:05AM +0000, Matt Miller (mamille2) wrote:
> [...]

Comments:

 - s/rfc4727/rfc4627/g  (the link to the attachment says 4727)

 - I don't think we ought to demand anything more than stability for
   normatively referencing ECMA-404.  In particular it seems odd to
   demand that the other SDO (ECMA) establish open processes before
   we'll consider referencing their documents -- a demand of that sort
   ought to be backed up by a statement (as a published RFC) from the
   IESG and/or IAB, not from a WG.

   I know, you said "[the IETF] _almost_ exclusively...".

   Are you asking the WG to demand that the ECMA commit to open
   processes in regards to TC39's future updates of ECMA-404?  Is that a
   consensus call?

 - While I think your note says everything that it must (and only a tad
   too much; see above), it reads a bit too plaintive to me.

   We had representation from TC39 members, and we had ECMA-404.  We had
   enormous threads on RFC4627bis.  We knew about the landmines we
   should not step on, and in the end we didn't step on them.  Things
   worked out, even if things could have worked better.

   I'm also not sure that concerns from ECMA TC39 would not have been
   dismissed as easily as similar concerns from individuals were (at
   least for a while).  We probably needed to have those long threads to
   come to our current consensus.

More in-line.

> -----BEGIN RESPONSE-----
> Thank you for your statement of concern about
> draft-ietf-json-rfc4627bis. The chairs of the IETF's JSON Working
> Group were not aware of any serious concerns that TC39 had with the
> update process. Over the past many months, we repeatedly contacted
> ECMA and TC39 members about the JSON WG and
> draft-ietf-json-rfc4627bis, but never received any significant reply.

Is there documentation of "official" attempts to contact ECMA TC39.
(I'm not sure what that would look like.)

> We know that some TC39 members joined the JSON WG mailing list but did
> not voice any process concerns in the WG -- or privately to the WG
> Chairs -- before or during either of the Last Calls on the document.

I've certainly seen complaints about direction or specific consensus
calls.  Were any by TC39 members?  I'd not know.  Were they about
process?  Perhaps if asked for clarification those voicing concerns
might specify the process as a source of concern.

> In the future, it would probably be useful for Ecma and the IETF to
> have a formal liaison relationship. We have heard that there were
> preliminary discussions several months ago, but stopped short of a
> formal relationship before the JSON Working Group was formed.
> Formalizing the liaison relationship will help both SDOs communicate
> with each other and thus avoid late surprises.

I think I'd phrase this more like:

   Given the late stage of RFC4627bis in the RFC publication process we
   came rather close to publishing an RFC of interest to the ECMA
   without formal input from the ECMA.  The ECMA's concerns were
   -accidentally- voiced in time.  The IETF has a formal liason
   relationship process for interaction with other SDOs.  Establishing
   an IETF-ECMA liason will likely make future interactions smoother.

Nico
--

---

From: Tim Bray <[email-masked]>
Date: Wed, 4 Dec 2013 21:02:18 -0800

I’m OK with most of this it goes a bit off the rails in the last paragraph.
 I think the ECMA process is better described as “opaque” than “closed”,
and the last paragraph gets into speculative territory.  While the
not-necessarily-immutable nature of 404 is a good reason to avoid a
normative reference, we don’t need to speculate on what we might do in a
future alternative universe.

I think that the most important reason to skip a normative reference to 404
is that a normative reference implies that you have to read that to
understand this, which clearly simply is not true.

There are also obvious content concerns with 404, in particular its sloppy
editing and its assertion that strings are composed of Unicode code points
which, while probably an improvement, takes us outside our charter which as
I understand it doesn’t allow us to say that documents which formerly were
JSON aren’t any more.

On Wed, Dec 4, 2013 at 6:57 PM, Matt Miller (mamille2)
<[email-masked]>wrote:

> Hello All,
>
> The JSON Working Group has received a statement from Ecma International's
> Technical Committee 39 (TC39) regarding draft-ietf-json-rfc4627bis.  The
> statement can be found at <
> https://datatracker.ietf.org/documents/LIAISON/liaison-2013-11-25-ecma-tc39-json-ecma-tc39-comment-for-rfc-4727bis-attachment-1.pdf>.
>
> In response, the Chairs and sponsoring Area Director propose to send the
> following on behalf of the JSON Working Group.  We wish to send the
> response on December 10.  If there are any serious factual errors in the
> following response, let us know before then.  Note that we are *not* asking
> the WG to re-open any of the consensus discussions, simply to see if we
> misstated anything factual.
>
>
> Thank you,
>
> Thank you for your statement of concern about draft-ietf-json-rfc4627bis.
> The chairs of the IETF's JSON Working Group were not aware of any serious
> concerns that TC39 had with the update process. Over the past many months,
> we repeatedly contacted ECMA and TC39 members about the JSON WG and
> draft-ietf-json-rfc4627bis, but never received any significant reply. We
> know that some TC39 members joined the JSON WG mailing list but did not
> voice any process concerns in the WG -- or privately to the WG Chairs --
> before or during either of the Last Calls on the document.
>
> In the future, it would probably be useful for Ecma and the IETF to have a
> formal liaison relationship. We have heard that there were preliminary
> discussions several months ago, but stopped short of a formal relationship
> before the JSON Working Group was formed. Formalizing the liaison
> relationship will help both SDOs communicate with each other and thus avoid
> late surprises.
>
> - In IETF Last Call, there was consensus to change the definition of "JSON
> text" in draft-ietf-json-rfc4627bis to match the one in ECMA-404. The
> latest draft reflects that change. At this point, we believe that there are
> no syntactic differences between the two specifications.
>
> - The JSON WG decided to change the title of the document to better
> reflect its content. The current document is much more than a media type
> registration: it repeats the JSON syntax originally documented in RFC 4627,
> and has been stable for many years, it is a discussion of the JSON
> semantics important to freestanding encoders and parsers, it is a
> discussion of interoperability issues that have been encountered since RFC
> 4627 and ECMA-262 5th Edition were published, and it is a media type
> registration. Having a more accurate title on the document will help
> readers understand its contents and the difference between it and ECMA-404.
>
> - After Ecma published ECMA-404, the JSON WG discussed whether to remove
> the ABNF version of the JSON syntax that was established in RFC 4627 from
> draft-ietf-json-rfc4627bis; it was decided not to do so. One reason is that
> ECMA-404 uses "racetrack pictures" to define the syntax, whereas IETF
> documents have traditionally used ABNF, and many developers have expressed
> a strong preference for the ABNF. This might be considered simply a matter
> of style, but it was deemed important by many WG members. We intend to keep
> the discussion and reference to ECMA-404 in draft-ietf-json-rfc4627bis,
> even if Ecma continues to choose not to reciprocate in ECMA-262 6th
> Edition, because developers reading draft-ietf-json-rfc4627bis might indeed
> prefer the racetrack pictures.
>
> - A normative reference to ECMA-404 would be premature without a clear and
> well-understood document management process. Historically, when someone
> reading an RFC sees a normative reference to one version of another SDO's
> standards, they tend to think the reference will apply to future versions
> of that external standard as well. Given the closed process that resulted
> in ECMA-404, it seems quite possible that Ecma could later make changes to
> ECMA-404 that would have a negative effect on interoperability from the
> Internet perspective. When the IETF normatively refers to other standards,
> it almost exclusively does so to standards that were developed with
> processes that are open to discussion and contribution by anyone.
>
> If the IETF believed that future development of ECMA-404 would involve a
> similar kind of open participation as seen with the development of
> draft-ietf-json-rfc4627bis, it could certainly revisit the topic of a
> normative reference in any subsequent update. Such a belief could be one of
> the positive products of a formal liaison relationship between the IETF and
> Ecma.
> -----END RESPONSE-----
>
>
> _______________________________________________
> json mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/json
>
>

---

From: Nico Williams <[email-masked]>
Date: Wed, 4 Dec 2013 23:15:19 -0600

Though I should add that i agree with the sentiment regarding open
processes.

Nico
--

---

From: "Martin J. Dürst" <[email-masked]>
Date: Thu, 05 Dec 2013 15:22:50 +0900

[Cc'ed to some people I know or suspect are involved in TC39, to 
hopefully get some clarifications.]

> Though I should add that i agree with the sentiment regarding open

I had the same sentiment. But I think part of it comes from the fact 
that I just don't know what kind of process ECMA TC39 is using.

And the other part comes from the fact that I repeatedly got messages 
from [email-masked] saying:

Messages from non-subscribers are automatically rejected. Please
subscribe to the list first before attempting to post, or ensure that
you are posting using the address you subscribed with.

Maybe I should just have tried to subscribe. Maybe I should have asked 
somebody. But frankly, it was the first time I can remember that in a 
standard-related mailing list, a mail was just automatically rejected.

I have managed mailing lists at both the W3C and the IETF, and in both 
cases, mails from addresses that don't match a whitelist (which is much 
wider than just the subscribers of the particular list) get sent through 
moderation. Maybe there are some specific reasons why this is different 
at ECMA, but it definitely doesn't help with inter-WG collaboration.

Regards,   Martin.

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 5 Dec 2013 07:32:20 +0100

On 05 Dec 2013, at 07:22, Martin J. Dürst <[email-masked]> wrote:

> repeatedly got messages from [email-masked]

Yep.  And some messages from “over there” read like they came out of a bubble.
Running a discussion on several mailing lists at the same time is never a great idea, but it gets much, much worse when a subgroup of the participants never gets to hear input from outside their own subgroup.

Grüße, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 5 Dec 2013 07:43:52 +0100

On 05 Dec 2013, at 05:42, Nico Williams <[email-masked]> wrote:

> I don't think we ought to demand anything more than stability for
>   normatively referencing ECMA-404. 

Whoa.  
Actually, a major prerequisite is that any spec we rely on by referencing it normatively is a good specification.

Saying that the process leading to ECMA-404 wasn’t open may also be a veiled expression of dissatisfaction with the outcome.  (I have said openly that ECMA-404 is a great tutorial, just not a very good specification; some others have been trying to be more diplomatic about this.)

I still haven’t heard any argument that invalidates the very good ones made in http://lists.w3.org/Archives/Public/www-tag/2013Oct/0041.html (except for the fact that we are now tracking the gratuitous change that allows non-containers on the top-level).

Grüße, Carsten

---

From: Nico Williams <[email-masked]>
Date: Thu, 5 Dec 2013 00:50:27 -0600

On Thu, Dec 05, 2013 at 03:22:50PM +0900, "Martin J. Dürst" wrote:
> And the other part comes from the fact that I repeatedly got
> messages from [email-masked] saying:

Some IETF lists also do that.  The IETF allows IETF list owners to set
their own preferences for this.  I personally think that any member [in
good standing] of any IETF list ought to be able to post to any IETF
list without having to subscribe.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Thu, 5 Dec 2013 00:58:05 -0600

On Thu, Dec 05, 2013 at 07:43:52AM +0100, Carsten Bormann wrote:
> Actually, a major prerequisite is that any spec we rely on by
> referencing it normatively is a good specification.

OK, I grant that :)  I was referring to process, however.  We really
want to demand the stability of non-Internet standards normatively
referenced from Internet standards as we do of Internet standards
normatively [...].  IIRC the IETF does occasionally permit some
normative downrefs, but asking for a downref is asking for sturm und
drang.

> Saying that the process leading to ECMA-404 wasn’t open may also be a
> veiled expression of dissatisfaction with the outcome.  [...]

Maybe so, but that's neither here nor there.  If ECMA-404's quality is
insufficient then we won't reference it normatively.  If it is
insufficiently stable then we won't reference it normatively.  That ECMA
is or is not as open as we'd like is irrelevant -- that was my point, in
particular that we ought not make demands about their process (or at
least not without having WG consensus for such a heavy-handed position,
and preferably more than WG consensus).

Nico
--

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 5 Dec 2013 07:58:59 -0800

> - s/rfc4727/rfc4627/g  (the link to the attachment says 4727)

That's actually not part of the response we are sending, so there is nothing we can change. Yes, the link is wrong in the Liaison tool, but we'll just have to live with that.

>   processes in regards to TC39's future updates of ECMA-404?  Is that a

I don't think any of the wording in the response "demands" anything. Ecma made a request, and we are turning down the request for stated reasons. People in the WG discussion expressed consternation with ECMA-404, and the undertone was that they expected it to be developed in an IETF-like fashion. It's fine that Ecma didn't do that, of course, but it is also fine for us to base our decision on their process. Having said that, which sentences about "demands" were you referring to?

> (I'm not sure what that would look like.)

Matt and I were told about it by at least three different people in the IETF leadership. It (thankfully) happened at a different layer.

> might specify the process as a source of concern.

You can determine who is a TC39 member by looking at their roster.

--Paul Hoffman

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 5 Dec 2013 08:03:27 -0800

On Dec 4, 2013, at 9:02 PM, Tim Bray <[email-masked]> wrote:

> I’m OK with most of this it goes a bit off the rails in the last paragraph.  I think the ECMA process is better described as “opaque” than “closed”,

I was told that even if someone volunteered to help on a particular document from TC39, they would not be allowed to. That is "closed", not just "opaque".

> and the last paragraph gets into speculative territory.  

Of course, but it is based on lots of IETF history. That is, when organizations make liaison relationships with the IETF, things often to get smoother.

> While the not-necessarily-immutable nature of 404 is a good reason to avoid a normative reference, we don’t need to speculate on what we might do in a future alternative universe.   

We don't need to, but Matt and Pete and I thought that proposing a way forward that would lead to greater happiness was worthwhile.

--Paul Hoffman

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 5 Dec 2013 08:08:40 -0800

On Dec 4, 2013, at 10:50 PM, Nico Williams <[email-masked]> wrote:

> Some IETF lists also do that.  

This is off-topic, but I think your statement above has not been true for many years. There was an (informal?) decision by the IESG at least five years ago to change this, and all IETF-run lists were changed, and ones that were run by other organization (such as ones that I ran via IMC and VPNC) were told to change.

--Paul Hoffman

---

From: R S <[email-masked]>
Date: Thu, 5 Dec 2013 10:49:24 -0800

> misstated anything factual.

...

>
>
>  When the IETF normatively refers to other standards, it almost
> exclusively does so to standards that were developed with processes that
> are open to discussion and contribution by anyone.

A quick search turned up numerous IETF documents that normatively reference
ECMA standards. There are also *many* IETF documents that normatively
reference standards developed behind closed doors. Further, it seems like
this entire paragraph refusing to normatively reference ECMA-404 is full of
reasons that don't necessarily reflect the consensus of this WG (unless it
reflects a decision this WG took earlier--I didn't see one, though).

As an IETF participant and erstwhile TC-39 member , I don't think there is
a meaningful delta in "openness".

The IETF has a more regular process for establishing mailing lists and
taking bug reports (the easiest kind of "contribution" to accept). However,
TC-39 also happens to run an open mailing list and shares their meeting
minutes widely. When it comes to decision making, both organizations
operate in roughly the same way: some people's opinions count more than
others, and those people tend to have a lot of customers/money/etc.
Frankly, I think ECMA is more open about this.

- Rob

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 5 Dec 2013 11:13:58 -0800

On Dec 5, 2013, at 10:49 AM, R S <[email-masked]> wrote:

>  When the IETF normatively refers to other standards, it almost exclusively does so to standards that were developed with processes that are open to discussion and contribution by anyone.
> 
> A quick search turned up numerous IETF documents that normatively reference ECMA standards. There are also *many* IETF documents that normatively reference standards developed behind closed doors.

Fair point. We'll change "almost exclusively does" to "usually tries to do". 

> Further, it seems like this entire paragraph refusing to normatively reference ECMA-404 is full of reasons that don't necessarily reflect the consensus of this WG (unless it reflects a decision this WG took earlier--I didn't see one, though).

The topic of "should we just refer to Ecma" came up multiple times before Ecma produced ECMA-404, and each time the consensus was to keep our definition.

--Paul Hoffman

---

From: R S <[email-masked]>
Date: Fri, 6 Dec 2013 14:44:20 -0800

On Thu, Dec 5, 2013 at 11:13 AM, Paul Hoffman <[email-masked]> wrote:

>
> The topic of "should we just refer to Ecma" came up multiple times before
> Ecma produced ECMA-404, and each time the consensus was to keep our
> definition.

In that case, I don't understand what the factual basis for the text in
this paragraph is. It sounds like editorializing.

- Rob

---

From: Mark Nottingham <[email-masked]>
Date: Sat, 7 Dec 2013 16:20:17 +1100

Hi Matt,

Personal response below.

Generally, negotiation-through-liaison-statement is the WORST possible way to communicate. Why don’t we suggest a joint meeting, or appoint a temporary representative on both sides to work through the situation and report back, or…?

On Wed, Dec 4, 2013 at 6:57 PM, Matt Miller (mamille2) <[email-masked]> wrote:

> Thank you for your statement of concern about draft-ietf-json-rfc4627bis. The chairs of the IETF's JSON Working Group were not aware of any serious concerns that TC39 had with the update process. Over the past many months, we repeatedly contacted ECMA and TC39 members about the JSON WG and draft-ietf-json-rfc4627bis, but never received any significant reply.

Yes, the lack of communication has been unfortunate; I’m not sure driving that point too deeply here is really doing any good.

> We know that some TC39 members joined the JSON WG mailing list but did not voice any process concerns in the WG -- or privately to the WG Chairs -- before or during either of the Last Calls on the document.

Why the focus on “process” here? I’d like to believe that we’re engineers focusing on doing the right thing, not just enforcing a process. 

> In the future, it would probably be useful for Ecma and the IETF to have a formal liaison relationship. We have heard that there were preliminary discussions several months ago, but stopped short o…

Once JSON is done, will there be need for such a liaison in the future?

> - A normative reference to ECMA-404 would be premature without a clear and well-understood document management process. Historically, when someone reading an RFC sees a normative reference to one v…

As others have pointed out, this is misleading about the IETF’s requirements for references, and furthermore has a very patronising tone. Why don’t we ask what their intent is for the future of 404, rather than tell them what we deem it might be?

> If the IETF believed that future development of ECMA-404 would involve a similar kind of open participation as seen with the development of draft-ietf-json-rfc4627bis, it could certainly revisit th…

Getting into an our-process-is-more-open-than-your process fight is completely inappropriate, and does not represent the IETF well. 

Regards,

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

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 7 Dec 2013 08:10:09 -0800

<hat on>
<acknowledgement that Matt might disagree with some parts and can speak for himself>

On Dec 6, 2013, at 9:20 PM, Mark Nottingham <[email-masked]> wrote:

> Generally, negotiation-through-liaison-statement is the WORST possible way to communicate.

Fully agree. The response we propose to give is not "negotiation", it's a definitive response.

> Why don’t we suggest a joint meeting, or appoint a temporary representative on both sides to work through the situation and report back, or…?

We've had two face-to-face WG meetings since Ecma, and TC39 in specific, was actively and repeatedly invited to participate. If those weren't convenient, TC39 could have invited us to their face-to-face meetings, or asked for an interim or virtual interim.

> Yes, the lack of communication has been unfortunate; I’m not sure driving that point too deeply here is really doing any good.

The lack of communication up to this point, despite efforts on the part of the IETF, seems quite relevant in that Ecma is asking for substantial changes to the document at the last minute. If their statement was "we've asked for this repeatedly and you haven't given a good response", or "we didn't know that the IETF was working on this", those would be highly germane, but they are saying neither.

> Why the focus on “process” here? I’d like to believe that we’re engineers focusing on doing the right thing, not just enforcing a process. 

All of the Ecma requests are for process items (title of the RFC and normative referencing). It would be inappropriate for us to ignore their requests because they were on process items.

> Once JSON is done, will there be need for such a liaison in the future?

Absolutely. First, Ecma is much more than TC39. But, even if the liaison relationship was just for TC39, decisions that TC39 makes about the semantics of JSON in ECMAScript have a large affect the interoperability of JSON in other areas. Having a much better form of communication than we have now could certainly lead to better interoperability in the future.

>  . . .
> 
> As others have pointed out, this is misleading about the IETF’s requirements for references, and furthermore has a very patronising tone.

We heard that, and both are being fixed in the final message.

> Why don’t we ask what their intent is for the future of 404, rather than tell them what we deem it might be?

Because their intent might change over time, just as anyone's might. Intention are not promises, nor should they be. If Ecma had looked at our intent for rfc4627bis nine months ago and thought they were promises, they would be really pissed at us. SDOs doing technical work are often surprised by what they find when a lot of different eyes focus on the topic, as you are well aware from your current experience in httpbis. 

> Getting into an our-process-is-more-open-than-your process fight is completely inappropriate, and does not represent the IETF well. 

We heard that, and we will are softening this bit as well.

--Paul Hoffman

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 9 Dec 2013 13:54:29 +1100

> Because their intent might change over time, just as anyone's might. Intention are not promises, nor should they be. If Ecma had looked at our intent for rfc4627bis nine months ago and thought they…

I don’t disagree with your logic, but fully applied, we couldn’t reference our own publications, much less external ones.

Cheers,

---

From: R S <[email-masked]>
Date: Sun, 8 Dec 2013 18:58:20 -0800

Has the WG debated a normative reference to ECMA-404?

It is worth considering.

- Rob

On Sun, Dec 8, 2013 at 6:54 PM, Mark Nottingham <[email-masked]> wrote:

> > Because their intent might change over time, just as anyone's might.
> Intention are not promises, nor should they be. If Ecma had looked at our
> intent for rfc4627bis nine months ago and thought they were promises, they
> would be really pissed at us. SDOs doing technical work are often surprised
> by what they find when a lot of different eyes focus on the topic, as you
> are well aware from your current experience in httpbis.
>
> I don’t disagree with your logic, but fully applied, we couldn’t reference
> our own publications, much less external ones.
>
> Cheers,
>
>
> --

---

From: Tim Bray <[email-masked]>
Date: Sun, 8 Dec 2013 19:04:29 -0800

Um, yes. Repeatedly.  Current hot thread is the one with “W3C TAG” in the
title.

On Sun, Dec 8, 2013 at 6:58 PM, R S <[email-masked]> wrote:

>> I don’t disagree with your logic, but fully applied, we couldn’t
>> reference our own publications, much less external ones.
>>
>> Cheers,
>>
>>
>> --

---

From: R S <[email-masked]>
Date: Sun, 8 Dec 2013 19:26:36 -0800

I see a few of the more vocal members of this WG emailing with TC39 there.
The fact of the matter is that you'll need to use the equivalent of a
LinkedHashMap (Java/Dart) to get good interoperability with JSON texts that
include duplicate names (JavaScript object implmentations are largely
compatible with this--I think V8 behaves differently with keys that could
pass as array indices). I happen to agree with Crockford[0] that this was a
mistake, but we're left with it.

In this thread, one of the chairs said "The topic of 'should we just refer
to Ecma' came up multiple times before Ecma produced ECMA-404, and each
time the consensus was to keep our definition." That is an unsatisfactory
answer, because ECMA-404 is a materially different specification than
ECMA-262, edition 5.1.

- Rob

[0] http://www.ietf.org/mail-archive/web/json/current/msg00351.html

---

From: R S <[email-masked]>
Date: Sun, 8 Dec 2013 19:39:01 -0800

On Sun, Dec 8, 2013 at 7:26 PM, R S <[email-masked]> wrote:

> include duplicate names

This is wrong: key order often matters, but I should have written that
overwriting duplicates in key order is what matters for parsers in this
case.

- Rob

> (JavaScript object implmentations are largely compatible with this--I
> think V8 behaves differently with keys that could pass as array indices). I
> happen to agree with Crockford[0] that this was a mistake, but we're left
> with it.
>
> In this thread, one of the chairs said "The topic of 'should we just
> refer to Ecma' came up multiple times before Ecma produced ECMA-404, and
> each time the consensus was to keep our definition." That is an
> unsatisfactory answer, because ECMA-404 is a materially different
> specification than ECMA-262, edition 5.1.
>
> - Rob
>

---

From: Tim Bray <[email-masked]>
Date: Sun, 8 Dec 2013 20:05:51 -0800

My sense of the consensus is that key order matters when JSON is parsed by
JavaScript; but the vast majority of software that deals with JSON
transmitted over the wire does not make key order information available to
applications, nor does it make any guarantee of what happens in the case of
dupe keys.  Thus, that is what the -bis should say: That some software
does, some doesn’t, and the most interoperable thing is to not rely on any
particular behavior in these cases.

Put another way, when JSON is used as a message format, objects are
serializations of hash tables, that’s all they are, and asking for anything
more than that is not interoperable.

On Sun, Dec 8, 2013 at 7:39 PM, R S <[email-masked]> wrote:

>> I see a few of the more vocal members of this WG emailing with TC39
>> there. The fact of the matter is that you'll need to use the equivalent of
>> a LinkedHashMap (Java/Dart) to get good interoperability with JSON texts
>> that include duplicate names
>>
>
>>> Um, yes. Repeatedly.  Current hot thread is the one with “W3C TAG” in
>>> the title.
>>>
>>>

---

From: "John Levine" <[email-masked]>
Date: 9 Dec 2013 04:25:17 -0000

>more than that is not interoperable.

Yeah.  Unless I've missed something in the past 100,000 messages (you
never know) our goal is to tell people how to write code that has the
greatest chance of interoperating with other JSON producers and
consumers, not to tell people how to be bug-compatible with specific
implementations.  Not even very popular specific implementations.

R's,
John

---

From: R S <[email-masked]>
Date: Sun, 8 Dec 2013 22:24:27 -0800

> implementations.  Not even very popular specific implementations.

RFC 4627 currently says: "The names within an object SHOULD be unique."

That sounds like what you two are saying. No change is needed.

ECMA-404 says:

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

IETF email threads often rathole on tangential points. Sometimes, this
happens because certain participants are very focused on certain technical
issues.

It seems obvious that the main point I made was:

"The topic of 'should we just refer to Ecma' came up multiple times before
Ecma produced ECMA-404, and each time the consensus was to keep our
definition." That is an unsatisfactory answer, because ECMA-404 is a
materially different specification than ECMA-262, edition 5.1.

For example, ECMA-262 specified required handling for duplicate keys, while
ECMA-404 does not.

Are there changes other than adding ABNF that the JSON WG would like to
make?

- Rob

---

From: "Martin J. Dürst" <[email-masked]>
Date: Mon, 09 Dec 2013 15:45:45 +0900

On 2013/12/06 0:58, Paul Hoffman wrote:
> On Dec 4, 2013, at 8:42 PM, Nico Williams<[email-masked]>  wrote:

> That's actually not part of the response we are sending, so there is nothing we can change. Yes, the link is wrong in the Liaison tool, but we'll just have to live with that.

I'm sure somebody is in charge of that tool, and can fix this. If the 
chairs don't know how to request this, please ask your ADs.

Regards,   Martin.

---

From: Pete Resnick <[email-masked]>
Date: Mon, 9 Dec 2013 01:34:24 -0600

On 12/9/13 12:45 AM, "Martin J. Dürst" wrote:
>> That's actually not part of the response we are sending, so there is 
>> nothing we can change. Yes, the link is wrong in the Liaison tool, 
>> but we'll just have to live with that.
>

Actually, that was an error in the liaison as submitted that I failed to 
correct. I've let the secretariat know to fix it.

pr

-- 
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478