Paul Hoffman wrote:
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.
Right, that's a good point -- something has to give.
In case it wasn't obvious, most TC39 folks generally believe the
"something" is the de-jure spec when de-facto practice (built on
another, later spec -- or built on no spec atll) is in conflict. Not all
TC39ers, and not all the time -- if something is so broken by design as
to be unused in practice outside of tests, we may try to break backward
compatibility. I observe that such cases are few.
Developers have read both documents and dealt with the
incompatibilities however they felt appropriate.
Developers also are constrained in the market to interoperate, most of
the time (we hope; I lived through the IE nuclear winter of near-95%
market share and fought back with Firefox; we're living through the
"mobile Web == iOS WebKit" era, with an end in sight finally).
So what actually works, the "intersection semantics" among popular
implementations, is what we ought to spec. That's something most TC39ers
agree on, most of the time, too.
This says to me that changing the RFC is the best course. People reading
will, I'm sure, let me know if I'm missing anything!
/be
--Paul Hoffman
On Sun, Jun 9, 2013 at 7:25 PM, Brendan Eich <[email protected]
<mailto:[email protected]>> 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
<[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] <mailto:[email protected]>
https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
