Re: [Json] Proposal: the minimal edit

Carsten Bormann <cabo@tzi.org> Mon, 24 June 2013 20:04 UTC

Return-Path: <cabo@tzi.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 CF9F411E8186 for <json@ietfa.amsl.com>; Mon, 24 Jun 2013 13:04:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.214
X-Spam-Level:
X-Spam-Status: No, score=-106.214 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XLPJVOS556pb for <json@ietfa.amsl.com>; Mon, 24 Jun 2013 13:04:35 -0700 (PDT)
Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id AEB3F11E8185 for <json@ietf.org>; Mon, 24 Jun 2013 13:04:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r5OK4SJf004523; Mon, 24 Jun 2013 22:04:28 +0200 (CEST)
Received: from [192.168.217.105] (p548945FE.dip0.t-ipconnect.de [84.137.69.254]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id A9C59323C; Mon, 24 Jun 2013 22:04:27 +0200 (CEST)
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
Content-Type: text/plain; charset="iso-8859-1"
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <20130624185314.GB19899@mercury.ccil.org>
Date: Mon, 24 Jun 2013 22:04:26 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <4D90CADD-9197-4243-AE77-D03B48AFD2BC@tzi.org>
References: <CAChr6SyN4Z3Hh8OFGHkK+AJN0+S09wMfjeobZ51GjKNL+GhPsw@mail.gmail.com> <CAHBU6ivSG_jYEAzQLnNr+JJXPfMnt9qvhtKyo=HK+38iG_Z3xQ@mail.gmail.com> <F3805A10-4068-4D34-AABB-E199588BDB8D@lindenbergsoftware.com> <20130624185314.GB19899@mercury.ccil.org>
To: John Cowan <cowan@mercury.ccil.org>
X-Mailer: Apple Mail (2.1508)
Cc: Norbert Lindenberg <ietf@lindenbergsoftware.com>, "json@ietf.org" <json@ietf.org>, Tim Bray <tbray@textuality.com>, R S <sayrer@gmail.com>
Subject: Re: [Json] Proposal: the minimal edit
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <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: Mon, 24 Jun 2013 20:04:40 -0000

On Jun 24, 2013, at 20:53, John Cowan <cowan@mercury.ccil.org> wrote:

> It's standard vs. standard that needs to be
> called out, not standard vs. implementation.

Actually, I'm more interested in interoperability standards reflecting interoperability reality than reflecting other standards.

There is a fine line to walk here, of course.

In particular, "allowing" more and more deviations from a normative reference encourages implementors to turn that normative reference into soup *).  So it is quite understandable that the community behind that normative reference will be outraged each time that happens.

Documenting reality is not enough.  Behavior that creates interoperability problems needs to be discouraged, even if it is widespread.  

Conformity is not enough.  Behavior that creates interoperability problems needs to be discouraged, even if it is condoned by a normative reference.

Grüße, Carsten

*) I'm using that word as a technical term here.
Quick usage example:
HTML was based on SGML, but turned it into soup.