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

"Martin J. Dürst" <duerst@it.aoyama.ac.jp> Fri, 01 March 2013 10:01 UTC

Return-Path: <duerst@it.aoyama.ac.jp>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 645EB21F8830 for <json@ietfa.amsl.com>; Fri, 1 Mar 2013 02:01:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.04
X-Spam-Level:
X-Spam-Status: No, score=-104.04 tagged_above=-999 required=5 tests=[AWL=-4.250, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S2OP5BvFaDDY for <json@ietfa.amsl.com>; Fri, 1 Mar 2013 02:01:48 -0800 (PST)
Received: from scintmta01.scbb.aoyama.ac.jp (scintmta01.scbb.aoyama.ac.jp [133.2.253.33]) by ietfa.amsl.com (Postfix) with ESMTP id 006B421F8745 for <json@ietf.org>; Fri, 1 Mar 2013 02:01:41 -0800 (PST)
Received: from scmse01.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta01.scbb.aoyama.ac.jp (secret/secret) with SMTP id r21A1YBm003897 for <json@ietf.org>; Fri, 1 Mar 2013 19:01:34 +0900
Received: from (unknown [133.2.206.133]) by scmse01.scbb.aoyama.ac.jp with smtp id 0620_c1bf_ffe73daa_8256_11e2_ab77_001d096c566a; Fri, 01 Mar 2013 19:01:33 +0900
Received: from [IPv6:::1] ([133.2.210.1]:36837) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id <S163C40C> for <json@ietf.org> from <duerst@it.aoyama.ac.jp>; Fri, 1 Mar 2013 19:01:36 +0900
Message-ID: <51307C75.7060908@it.aoyama.ac.jp>
Date: Fri, 01 Mar 2013 19:01:25 +0900
From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= <duerst@it.aoyama.ac.jp>
Organization: Aoyama Gakuin University
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4
MIME-Version: 1.0
To: Nico Williams <nico@cryptonector.com>
References: <CAHBU6ityBeA+M-PEme09gO_jVySr33-X308i1UttxrQwSgYmGQ@mail.gmail.com> <0F513426-F26D-48F4-A7A8-88F3D3DA881B@vpnc.org> <CAK3OfOjFCnR8k1csVOkSKTDpA8exDvYdAijn80HKD5zwNzzeSw@mail.gmail.com> <4514F5D7-4A7E-476F-987D-C4C617F2BCBD@vpnc.org> <4D80AE86-4DBA-4236-9E2A-A06F2F9C30F7@mnot.net> <00b001ce1509$c4c99fc0$4e5cdf40$@packetizer.com> <CAC4RtVDXwPRL-Cz_Xf-kjU3dzzY+JheDGivSE9hF2v1NLkWEgQ@mail.gmail.com> <63519CDF-144F-4DA4-A9F3-A1AB824861D2@vpnc.org> <CAHBU6ivXpRaTPsbLd90zBDdiypO2pYn9mckkNcCh9ZEApsK1yg@mail.gmail.com> <CAK3OfOhX0aAhX6rsK5mL+5AUvX1bepgeN9o3OReRGykg8ycWhA@mail.gmail.com>
In-Reply-To: <CAK3OfOhX0aAhX6rsK5mL+5AUvX1bepgeN9o3OReRGykg8ycWhA@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Cc: Barry Leiba <barryleiba@computer.org>, Tim Bray <tbray@textuality.com>, Paul Hoffman <paul.hoffman@vpnc.org>, json@ietf.org
Subject: Re: [Json] What does "break compatibility" mean?
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Discussion related to JavaScript Object Notation \(JSON\)." <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 01 Mar 2013 10:01:49 -0000

Putting the horse before the chart, I think we don't want to break 
compatibility, but where necessary, we want to improve interoperability. 
Senders that send two of the same keys in the same object, and receivers 
that take any other than the last one, both create interoperability 
problems. Fixing that is valuable progress.

Using a standard language lawyer approach, I think we can observe that 
changing the SHOULD NOT to a MUST NOT should be okay because SHOULD NOT 
means that you can do it if you have a really good reason for it, but I 
haven't yet seen anybody come up with a good reason for it, so I'd claim 
that the cases with duplicate keys that exist out in the wild actually 
don't comply to the current spec.

The result of the two approaches above is the same, something like the 
lanugage that Nico proposed.

Regards,   Martin.

On 2013/03/01 5:46, Nico Williams wrote:
> On Thu, Feb 28, 2013 at 2:06 PM, Tim Bray<tbray@textuality.com>  wrote:
>> 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.
>
> The obvious compromise is to say senders MUST NOT send dup object keys
> and receivers MUST take the last key value pair of any dup keys,
> per-ECMAScript.  The latter preserves compatibility.
>
> Nico
> --
> _______________________________________________
> json mailing list
> json@ietf.org
> https://www.ietf.org/mailman/listinfo/json