IETF Logo Mail Archive

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

Tim Bray <tbray@textuality.com> Thu, 28 February 2013 21:59 UTC

Return-Path: <tbray@textuality.com>
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 0104121F8B49 for <json@ietfa.amsl.com>; Thu, 28 Feb 2013 13:59:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.376
X-Spam-Level:
X-Spam-Status: No, score=-3.376 tagged_above=-999 required=5 tests=[AWL=-0.400, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
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 BCw+fdcT19Ks for <json@ietfa.amsl.com>; Thu, 28 Feb 2013 13:59:38 -0800 (PST)
Received: from mail-vc0-f173.google.com (mail-vc0-f173.google.com [209.85.220.173]) by ietfa.amsl.com (Postfix) with ESMTP id 7EB7221F8B1D for <json@ietf.org>; Thu, 28 Feb 2013 13:59:38 -0800 (PST)
Received: by mail-vc0-f173.google.com with SMTP id fy27so1554165vcb.18 for <json@ietf.org>; Thu, 28 Feb 2013 13:59:38 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; 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=Fa3ZXMjKL1ToLy8J0m0pgwMxH5ZRnQBgQYLyUtG8p8I=; b=C4/gp3kXbg71EsNeIirXqOCawpSCPVmkoJzmnF6jxCwfYrp6+O/dcrpbts6i5EpUXQ lLZ/ewwgMRkHa/l76u3n9RzHH1ihvg1tpPLakmT/xF3UPkCjDMlYuWiS3cex53OY05Pd OAu+riaw099V34DPYSvvYDS8Xjak4NeRGvygWLY0EIm8HDTp+jX0u8pJD1/Afn9cGRZm qIgjcxrfiFn7+zjWfFzcigEEGh+rYRVBPeO7YoPXbojieq0VuhsH1oHDH6adaAYm/H04 1ofAkF5AAUjMs8s1+xwOOOMhDgGUmkNogXe/4N4ll0eK6nvQbAaeT1MmJeSdRAcNNgmw xz6A==
MIME-Version: 1.0
X-Received: by 10.52.89.52 with SMTP id bl20mr2731531vdb.85.1362088777801; Thu, 28 Feb 2013 13:59:37 -0800 (PST)
Received: by 10.220.167.10 with HTTP; Thu, 28 Feb 2013 13:59:37 -0800 (PST)
X-Originating-IP: [96.49.81.176]
In-Reply-To: <AB5022CF-A698-49A5-A138-2EC3D6995905@vpnc.org>
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> <AB5022CF-A698-49A5-A138-2EC3D6995905@vpnc.org>
Date: Thu, 28 Feb 2013 13:59:37 -0800
Message-ID: <CAHBU6ivwK2T3srn9E4recLFQjNaq7UVNdHMkjARC63zfb5Lqaw@mail.gmail.com>
From: Tim Bray <tbray@textuality.com>
To: Paul Hoffman <paul.hoffman@vpnc.org>
Content-Type: multipart/alternative; boundary="20cf307f37f4c1297604d6d001c4"
X-Gm-Message-State: ALoCoQkgJEOgoyQfahKPzSVEdambq/z2rlQCPRbaV775Ii0B38EN4iLe7wDaEwArr1oYc67SC7jB
Cc: Nico Williams <nico@cryptonector.com>, Barry Leiba <barryleiba@computer.org>, "json@ietf.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: Thu, 28 Feb 2013 21:59:40 -0000

If there were a significant number of protocols, or deployed software
components, that relied on the use of multiple keys, then changing the
SHOULD to a MUST would be a breaking change. I do not believe that there
are any, and thus this is not, *de facto*, a breaking change.  That
hypothesis is easily falsified, if in the course of the IETF work someone
sticks their hand up and says “this is going to break me”.  But I’m not
holding my breath.

 -T


On Thu, Feb 28, 2013 at 1:51 PM, Paul Hoffman <paul.hoffman@vpnc.org> wrote:

> On Feb 28, 2013, at 12:46 PM, Nico Williams <nico@cryptonector.com> 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.
>
> ...but the former ("say senders MUST NOT send dup object keys") breaks it,
> given that the RFC had a SHOULD not a MUST. Thus the question in this
> thread.
>
> --Paul Hoffman
> _______________________________________________
> json mailing list
> json@ietf.org
> https://www.ietf.org/mailman/listinfo/json
>

v2.23.0 | Report a Bug | By Email