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

Tim Bray <> Thu, 28 February 2013 20:06 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 32C6121F87B9 for <>; Thu, 28 Feb 2013 12:06:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.976
X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id WJj0Y-WQXn1v for <>; Thu, 28 Feb 2013 12:06:07 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 046DD21F87A4 for <>; Thu, 28 Feb 2013 12:06:06 -0800 (PST)
Received: by with SMTP id b10so2261508vea.30 for <>; Thu, 28 Feb 2013 12:06:06 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=EoaMKxEYR06B7NGdf+3r3k6iWDdzeBslgf8lZ4sAU3s=; b=AekqAxykLDnh7FpZF/nmDq6Bgy8Nhes/7SyqoYQj0HR60w23QFzjl8WhE8vtHcYAiT h7hbcb0iXkOBbpfm41m70svSSzB4+7AOiPRAk2vNQHyiZu5A7M8Sl8+JMKZyqWgOpzMw 0w2vHsEaLbrv+dal0n1MT0550myOoR06kqNfsgfGynfoc5o2+frX4jBqMCCLPjOO0+aK lmqiKbS9TadXzB8YTnjNJHkFyaDWaQp7l09sILojRQbsfM6lZwiH4IpeKr2TIiRVfgou CDldpMW/rECc4tXWMFbdokVn8r9my1+IO36pO/EZi6FNIEOGJZkSnj3DZKNn9vgO7SC/ /EGw==
MIME-Version: 1.0
X-Received: by with SMTP id vv3mr3049533veb.50.1362081966372; Thu, 28 Feb 2013 12:06:06 -0800 (PST)
Received: by with HTTP; Thu, 28 Feb 2013 12:06:06 -0800 (PST)
X-Originating-IP: []
Received: by with HTTP; Thu, 28 Feb 2013 12:06:06 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <> <00b001ce1509$c4c99fc0$4e5cdf40$> <> <>
Date: Thu, 28 Feb 2013 12:06:06 -0800
Message-ID: <>
From: Tim Bray <>
To: Paul Hoffman <>
Content-Type: multipart/alternative; boundary=047d7b67002dc307dc04d6ce6ba1
X-Gm-Message-State: ALoCoQmKW3iIdy+4TGczNiCG+2mA2FShD8mvol+fuvAMmRgBA9grg5PYyLHDFmX+Sj4h8rPtdmZw
Cc: Barry Leiba <>,
Subject: Re: [Json] What does "break compatibility" mean?
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Discussion related to JavaScript Object Notation \(JSON\)." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 28 Feb 2013 20:06:08 -0000

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.

On Feb 27, 2013, at 10:15 AM, Barry Leiba <> 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
>> 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