Re: [Json] Two Documents

Carsten Bormann <cabo@tzi.org> Wed, 19 June 2013 16:14 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 8665021F9DA9 for <json@ietfa.amsl.com>; Wed, 19 Jun 2013 09:14:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.201
X-Spam-Level:
X-Spam-Status: No, score=-106.201 tagged_above=-999 required=5 tests=[AWL=0.048, 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 TyljOnPxag1w for <json@ietfa.amsl.com>; Wed, 19 Jun 2013 09:14: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 C2FE321F9DA6 for <json@ietf.org>; Wed, 19 Jun 2013 09:14:29 -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 r5JGER5n023521; Wed, 19 Jun 2013 18:14:27 +0200 (CEST)
Received: from [192.168.217.105] (p54893A31.dip0.t-ipconnect.de [84.137.58.49]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id B94543BEB; Wed, 19 Jun 2013 18:14:26 +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>
X-Priority: 3
In-Reply-To: <2E8AF23771284CF0BE394DBFF12DEB80@codalogic>
Date: Wed, 19 Jun 2013 18:14:25 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <2F8332EF-4FE5-43CF-AFA6-D3BACEC11D55@tzi.org>
References: <51B9EA49.2050604@crockford.com><BF7E36B9C495A6468E8EC573603ED9411528A0E2@xmb-aln-x11.cisco.com><51C1121E.8050004@crockford.com> <CAHBU6isgo-pLBUHM-6ix3eChD4khMgFBEyf6pDYzU3-oteAD=g@mail.gmail.com> <2E8AF23771284CF0BE394DBFF12DEB80@codalogic>
To: Pete Cordell <petejson@codalogic.com>
X-Mailer: Apple Mail (2.1508)
Cc: Tim Bray <tbray@textuality.com>, json@ietf.org
Subject: Re: [Json] Two Documents
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: Wed, 19 Jun 2013 16:14:41 -0000

On Jun 19, 2013, at 17:37, "Pete Cordell" <petejson@codalogic.com> wrote:

> can't fix them with a one document strategy

It is still possible to have a section with behavior that the spec accepts as legacy but doesn't approve of.
Concentrate it into a section so the rest stays readable without a million exceptions.

Cf. the "BWS" (bad white space) in HTTPbis:

   BWS is used where the grammar allows optional whitespace, for
   historical reasons, but senders SHOULD NOT generate it in messages;
   recipients MUST accept such bad optional whitespace and remove it
   before interpreting the field value or forwarding the message
   downstream.

This is quite different from "best practices" in that it is a legacy-based addition to the accepted set, not a restriction of the accepted set based on some "best practices".

Not part of the desirable spec     Allowed by the desirable spec
                                |                 _______________
                                |                /
                                |                \
                               /|                /
                              / |                \    Best
                             /  |                /     Practices
                            /   |                \
                           /Barf|                /
                           \ bag|                \
                            \___|                 \
                                |                  \_____________
                                |

The main part of the normative spec would describe the vertical line.
That special section with legacy behavior we can't get rid of in the normative spec is marked "Barf bag" for brevity above.
The "best practices" are over in desired land, but way more restricted.

Grüße, Carsten