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

Paul Hoffman <paul.hoffman@vpnc.org> Fri, 01 March 2013 17:39 UTC

Return-Path: <paul.hoffman@vpnc.org>
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 8C63C21E8037 for <json@ietfa.amsl.com>; Fri, 1 Mar 2013 09:39:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.68
X-Spam-Level:
X-Spam-Status: No, score=-102.68 tagged_above=-999 required=5 tests=[AWL=-0.081, BAYES_00=-2.599, 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 pzv4kU8KCrZe for <json@ietfa.amsl.com>; Fri, 1 Mar 2013 09:39:09 -0800 (PST)
Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id F13BF21F9365 for <json@ietf.org>; Fri, 1 Mar 2013 09:39:08 -0800 (PST)
Received: from [10.20.30.90] (50-1-98-12.dsl.dynamic.sonic.net [50.1.98.12]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r21Hd7IM001753 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 1 Mar 2013 10:39:07 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: Paul Hoffman <paul.hoffman@vpnc.org>
In-Reply-To: <CAK3OfOjjAowhrSuYCGDWeHtVD0JY4q18_nkVa9i74QG9W2esCg@mail.gmail.com>
Date: Fri, 1 Mar 2013 09:39:07 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <E5201070-46BB-446D-ACBE-C52D02BF3D2C@vpnc.org>
References: <CAK3OfOjjAowhrSuYCGDWeHtVD0JY4q18_nkVa9i74QG9W2esCg@mail.gmail.com>
To: Nico Williams <nico@cryptonector.com>
X-Mailer: Apple Mail (2.1499)
Cc: json@ietf.org
Subject: Re: [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 17:39:09 -0000

On Mar 1, 2013, at 8:46 AM, Nico Williams <nico@cryptonector.com> wrote:

> 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.

I was with you until that last phrase. We were talking about breaking *compatibility* before you changed the thread title. In the old thread, adding a specification for an undefined receiver breaks compatibility for anyone who wasn't doing what the new specification says. In your new thread, I agree that we would not be breaking compliance, but that's because we are defining compliance.

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

I didn't define "break"; I defined "break compatibility". So, yes.

> Perhaps you could offer your proposal.  

I have already said that I would be OK with either of the proposals for changes to the spec; what is not OK is to pretend that either would not break compatibility. That was the topic of the thread before you changed it.

> ...<incorrect assertions about what I want elided>...
> 
> 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)??

No, because we are defining compliance in the new document.

> (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
> question.)

Agree.

--Paul Hoffman