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 <[email protected]
<mailto:[email protected]>> wrote:
On Sun, Jun 9, 2013 at 7:19 PM, Paul Hoffman
<[email protected] <mailto:[email protected]>> 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 list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
