[Json] Compliance vs. interop (Re: What does "break compatibility" mean?)

Nico Williams <nico@cryptonector.com> Fri, 01 March 2013 16:46 UTC

Return-Path: <nico@cryptonector.com>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id DFC9B21E80CD for <json@ietfa.amsl.com>; Fri, 1 Mar 2013 08:46:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.077
X-Spam-Status: No, score=-3.077 tagged_above=-999 required=5 tests=[AWL=-1.100, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id SlRmXg2B63IJ for <json@ietfa.amsl.com>; Fri, 1 Mar 2013 08:46:31 -0800 (PST)
Received: from homiemail-a88.g.dreamhost.com (caiajhbdcagg.dreamhost.com []) by ietfa.amsl.com (Postfix) with ESMTP id 2656921E80CB for <json@ietf.org>; Fri, 1 Mar 2013 08:46:31 -0800 (PST)
Received: from homiemail-a88.g.dreamhost.com (localhost []) by homiemail-a88.g.dreamhost.com (Postfix) with ESMTP id DBA0E264058 for <json@ietf.org>; Fri, 1 Mar 2013 08:46:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:date:message-id:subject:from:to:cc:content-type: content-transfer-encoding; s=cryptonector.com; bh=EUSScVurY4Vjs0 tV5dwUpKWv7SU=; b=i0Z058zFdPjWckV4TUGe9muo7OveyA0ZbYiG/MTDCpHqcg nD/vlD8N2eQd4w1XqA5kRgcdEG6ylyy8zot/f8and/T0/Ffuz+ScTZrd6ZZAzqfX 0Z9idQELjG0tvwTxt/LsjNSVH8Fy1hBZ9+iwbxtW7mOuvNx4sH028HptGfaMw=
Received: from mail-we0-f182.google.com (mail-we0-f182.google.com []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a88.g.dreamhost.com (Postfix) with ESMTPSA id 8F3CA264059 for <json@ietf.org>; Fri, 1 Mar 2013 08:46:30 -0800 (PST)
Received: by mail-we0-f182.google.com with SMTP id t57so2740896wey.27 for <json@ietf.org>; Fri, 01 Mar 2013 08:46:29 -0800 (PST)
MIME-Version: 1.0
X-Received: by with SMTP id i20mr5164497wiw.9.1362156389138; Fri, 01 Mar 2013 08:46:29 -0800 (PST)
Received: by with HTTP; Fri, 1 Mar 2013 08:46:28 -0800 (PST)
Date: Fri, 1 Mar 2013 10:46:28 -0600
Message-ID: <CAK3OfOjjAowhrSuYCGDWeHtVD0JY4q18_nkVa9i74QG9W2esCg@mail.gmail.com>
From: Nico Williams <nico@cryptonector.com>
To: Paul Hoffman <paul.hoffman@vpnc.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: "json@ietf.org" <json@ietf.org>
Subject: [Json] Compliance vs. interop (Re: 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 16:46:32 -0000

On Fri, Mar 1, 2013 at 9:31 AM, Paul Hoffman <paul.hoffman@vpnc.org> wrote:
> On Mar 1, 2013, at 2:01 AM, Martin J. Dürst <duerst@it.aoyama.ac.jp> wrote:
>> 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.
> That's not true at all. A perfectly valid reason for a JSON producer to put in two or more of the same name is a streaming producer that doesn't know what has been added before. Changing SHOULD NOT to MUST NOT means that a JSON producer MUST know everything else in the object before emitting it. It would be reasonable for this to be the consensus, but we can't say that it does not break compatibility with some producers. (And, of course, the other option is to break compatibility with some JSON processors.)

The new requirement for receivers takes care of not breaking senders
that continue to send duplicate keys.  There's no breakage, except
where previously undefined receiver behavior changes due to the new
requirement on receivers, but that was always a possibility before, so
there's no new breakage.

You seem to define "break" as including "rendering no longer being
compliant, even if still being interoperable".

Perhaps you could offer your proposal.  Or we can speculate about it.
You seem to want to keep the SHOULD NOT send dups but (?) add the new
receiver requirement.  Your rationale for this seems to be that
rendering senders of dups non-compliant is somehow bad, to which I've
two responses:

a) The old senders will remain compliant with the RFC in force when
they were deployed.  Ergo there there's no valid "rendered
uncompliant" concern.

b) Even if (a) is unconvincing, again, we have NO IETF COMPLIANCE
POLICE.  When these sorts of changes come up the first question should
be "what about interop?"; the "what about causing implementations to
remain interoperable but no longer compliant?  who will soothe their
feelings?" should have much lower importance.

Perhaps we need to deal with that meta issue first: do we (the WG, the
area, and/or the IETF) have a goal of not rendering existing
implementations of Internet standards non-compliant with updates to
said standards?  Is this even a valid question (see point (a) above)??

(It's clear we still care first and foremost about
interoperability/compatibility when it comes to updating existing
Standards-Track RFCs.  As we should.  I hope that doesn't come into