Re: [Json] What does "break compatibility" mean?

It’s clear to me that, *for the purposes of the IETF*, someone needs to say
“People sending JSON MUST NOT use duplicate keys.”  The fact that certain
libraries allow less-clueful developers to do this, and that parsing
software is observed to behave unpredictably when they do, should only
encourage us.
-T

On Feb 27, 2013, at 10:15 AM, Barry Leiba <barryleiba@computer.org> wrote:

>>> I don't know. I think I'd be fine if we just asked Crockford (perhaps
>>> helped by a willing editor) to do 4627bis and then have the AD sponsor
>>> it on Standards Track.
>>
>> I did ask him.  I actually asked him about updating it even before I had
>> heard about the JSON BoF.  He indicated that he is willing to work on it
"as
>> long as it does not break compatibility with existing implementations."
>>
>> As editor, I think he would be in a good position to ensure that his
>> requirement is met.
>
> Indeed; I had talked with him back in August, as well, with the same
> response.  And as the likely responsible AD for any WG that forms, I
> can say that I strongly agree with the "doesn't break compatibility"
> point.

As we discussed, RFC 4627 says "The names within an object SHOULD be
unique." So, what does "break compatibility" mean for this specific issue?
If we make the SHOULD a MUST, there are emitters that will become
incompatible. If change the sentence to follow the ECMAScript spec ("In the
case where there are duplicate name Strings within an object, lexically
preceding values for the same key shall be overwritten."), there are
parsers that will become incompatible.

> My view is that the charter has to make it clear that the
> "4627 to Standards Track" work is essentially a re-classification in
> place, rolling in errata and clarifications, but *not* changing the
> language.

Is the ECMAScript text a clarification or a change?

> Any proposals that actually make changes would have to come
> later, and be considered as separate work proposals.

That certainly sounds reasonable. The question is whether you will allow
clarifications that might make something incompatible.

--Paul Hoffman
_______________________________________________
json mailing list
json@ietf.org
https://www.ietf.org/mailman/listinfo/json