JSON Duplicate Keys

Paul Hoffman paul.hoffman at gmail.com
Mon Jun 10 08:35:04 PDT 2013


The term "incompatible change" is being used too loosely here. RFC 4627 and
the ES spec are currently different. If we simply republished RFC 4627, it
would be an incompatible change from ES. If we publish a new RFC that says
exactly what ES says, it will be an incompatible change from the earlier
RFC.

Developers have read both documents and dealt with the incompatibilities
however they felt appropriate.

--Paul Hoffman


On Sun, Jun 9, 2013 at 7:25 PM, Brendan Eich <brendan at mozilla.com> wrote:

> Paul Hoffman wrote:
>
> Thanks, but that doesn't match what Yehuda said. If anything, it shows
> that there is as widespread disagreement within TC39 as to what is a
> "breaking" change with respect to duplicate names in objects as there so
> far is in the JSON WG.
>
>
> The minutes Rick cited show no disagreement other than Doug (I missed this
> part of the March meeting). The "FTR: Majority opposition, no consensus"
> note, I believe, means that everyone but Doug agreed that an incompatible
> change was a bad idea, to be opposed.
>
> Is anything else unclear? Am I missing some other notes section? I do not
> see "widespread disagreement within TC39 as to what is a "breaking" change
> with respect to duplicate names in objects" in any of the "JSON, IETF
> changes" meeting notes text (cited below).
>
> /be
>
>
> <https://github.com/rwldrn/tc39-notes/blob/master/es6/2013-03/mar-12.md#49-json-ietf-changes>4.9
> JSON, IETF changes
>
> (Presented by DC Crockford)
>
> Currently, JSON is an RFC, informational, the IETF version will be an
> internet standard and there is a minor correction that affects ECMAScript.
>
> The use of "should" in 15.12.2
>
> AR: What is the motivation of the change?
>
> DC: The change involves the mistake of using "should" w/r to multiple
> same-named keys error. Multiple same-name keys are invalid and *must*throw an error (vs. "should" throw an error)
>
> LH: This is a breaking change
>
> DH: The worst being the use case of multiple, same-named keys as comments
>
> DC: That's stupid
>
> YK: That's based on on your recommendation to use a keyed entry as a
> comment, so people naturally used the same key, knowing they'd be ignored.
>
> DC: I would certainly never recommend that practice
>
> YK: It was a side-effect
>
> AR: Which key is used now?
>
> AWB: The last one wins.
>
> AR: Is that the root of the security vector?
>
> DC: Not in ES, but in other encodings
>
> AR: Order matters, unescaped content that follows...
>
> DC: The current spec says "[they should not]", but will say "[they must
> now]"
>
> YK: Let's define an ordering and make it cryptographically secure.
>
> DC: (recapping to Mark Miller, who just arrived)
>
> MM: You can't do that. (laughs)
>
> MM: You can't change "should" to "must"
>
> YK: Agreed, you cannot change JSON, there are too many JSON documents in
> existence.
>
> MM: Agreed.
>
> AR: It's possible to ignore this change?
>
> DC: Yes
>
> DH: Then why are we creating a dead letter?
>
> MM: ES has a grammatical specification for validating and parsing JSON.
> Anything that is not conformant JSON, would not parse. This change loses
> that property.
>
> DC: Or we don't change the spec
>
> MM: The way that you properly reject our favorite fixes, I think you
> should apply to your favorite fixes
>
> DC: I'll consider that
>
> AR: There is considerable opposition to this change
>
> DC: Two choices...
>
>    1. Make it an error
>    2. Continue to take the last one
>
> DC: Decoders have license to do what they want with non-conformant
> material. Encoders *must* be conferment to new changes.
>
> MM: Our current encoder conforms...
>
> AWB: I don't think it does... reviver/replacer
>
> MM: No, can only apply objects instead of the original objects.
>
> AR: Did not realize the production/consumption distinction of this change.
>
> WH: Supports this change. ECMAScript is already conformant because it
> never generates duplicate keys.
>
> MM: With this change ECMAScript would have two unappealing choices: A. No
> longer be a validating parser (i.e. a parser that doesn't allow any
> optional syntax or extensions, even though extensions are permitted by the
> JSON spec). B. Do a breaking change by throwing errors when seeing
> duplicates when parsing.
>
> <https://github.com/rwldrn/tc39-notes/blob/master/es6/2013-03/mar-12.md#conclusionresolution>
> Conclusion/Resolution
>
>    - Revisit this, after DC has made a final decision.
>    - FTR: Majority opposition, no consensus.
>
>
>
>
> If there are other public minutes that relate to the TC39-IETF
> relationship, I'd certainly appreciate them. The ECMA-IETF discussions all
> happened before Matt Miller and I were made co-chairs of the WG.
>
>  --Paul Hoffman
>
>
> On Sun, Jun 9, 2013 at 4:53 PM, Rick Waldron <waldron.rick at gmail.com>wrote:
>
>>
>>
>>
>> On Sun, Jun 9, 2013 at 7:19 PM, Paul Hoffman <paul.hoffman at gmail.com>wrote:
>>
>>> >At two TC39 meetings, members of TC39 expressed deep concern about the
>>> prospect of incompatible changes to JSON by the IETF.
>>>
>>> Those concerns have not been expressed directly to the IETF's JSON
>>> Working Group. I say this as one of the two co-chairs of the JSON WG. If
>>> TC39 wants to express "deep concern", they certainly know where to do so.
>>> Them doing so sooner rather than later would be helpful all around.
>>>
>>> I would note that some of the possibly-incompatible changes to RFC 4627
>>> that are being discussed relate to places where the RFC is
>>> self-contradictory or blatantly unclear. In such cases, leaving the RFC
>>> alone might just as easily lead to incompatible implementations as
>>> clarifications would. That is going to have be determined by the IETF's
>>> consensus process.
>>>
>>> No one can force anyone here to follow the official WG discussion for
>>> the successor to RFC 4627, of course. However, given that some people on
>>> this list are JSON experts, if you don't want to participate in the
>>> evolution of the RFC, I would be interested in hearing (possibly off-list)
>>> why that is. Part of the job of the chairs is to make sure experts feel
>>> welcome in the IETF process.
>>>
>>
>> Paul,
>>
>> Here are the notes from the first TC39 meeting that this topic was
>> discussed
>>
>>
>> https://github.com/rwldrn/tc39-notes/blob/master/es6/2013-03/mar-12.md#49-json-ietf-changes
>>
>> Rick
>>
>>
> _______________________________________________
> es-discuss mailing listes-discuss at mozilla.orghttps://mail.mozilla.org/listinfo/es-discuss
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130610/045497bd/attachment.html>


More information about the es-discuss mailing list