[Json] What are we trying to do?

Tim Bray <tbray@textuality.com> Wed, 03 July 2013 05:01 UTC

Return-Path: <tbray@textuality.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 3A6F221F9B0F for <json@ietfa.amsl.com>; Tue, 2 Jul 2013 22:01:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.976
X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 0SjT4eCnbiUG for <json@ietfa.amsl.com>; Tue, 2 Jul 2013 22:01:40 -0700 (PDT)
Received: from mail-ve0-f178.google.com (mail-ve0-f178.google.com []) by ietfa.amsl.com (Postfix) with ESMTP id 3063021F9AE9 for <json@ietf.org>; Tue, 2 Jul 2013 22:01:40 -0700 (PDT)
Received: by mail-ve0-f178.google.com with SMTP id pb11so5626153veb.9 for <json@ietf.org>; Tue, 02 Jul 2013 22:01:39 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=lNfXBvufsZKQrpTJS8IFDfRAno0o9zXjOVRHzEl8gi0=; b=k/981xL9S6IqshOj5xs7ZgyH55/Ea+N4w2nP25drZpoxznrJXLqlvRkMtBBxzJo/y/ 2gvf8S+ki8xmfv+01DFkV3LaX9pN2Kiho7wm3k0c+Wc3TS4x5vM8vuRbT8ooXaxCQSgi QC47zmd6e9hk7Hq/x2R6vyZ0kAPDvlOC1gJr85RGzwxQgCSXevHJY2nBZPtfvWsqD1aM RtgaC7M28sRxmTigH3yqyqgG7WN+bXNls+IL5rH+BKbkNIUFE27QdVUIs2VY4+Ym6Fy7 Umkc+mNb9QsukZGA6YlmeIU5MMYQNdWFUBjI1RVIhb/e7EMjoqDSwcYCDH9JGng+NTR+ vq5w==
MIME-Version: 1.0
X-Received: by with SMTP id 9mr325502veu.50.1372827699450; Tue, 02 Jul 2013 22:01:39 -0700 (PDT)
Received: by with HTTP; Tue, 2 Jul 2013 22:01:38 -0700 (PDT)
X-Originating-IP: []
Date: Tue, 02 Jul 2013 22:01:38 -0700
Message-ID: <CAHBU6iv0wXYvAyasSE8Wga0K_sD_pKL6o-a-ca9yemhy3m6zzw@mail.gmail.com>
From: Tim Bray <tbray@textuality.com>
To: "json@ietf.org" <json@ietf.org>
Content-Type: multipart/alternative; boundary="047d7b2e75cc5d257d04e0945b81"
X-Gm-Message-State: ALoCoQlWVzdRrdl09BkNNBOfVP6QPMLADOV18oIotkSXQ7cL1dZ74VfPCKwVwzH1xQ2HpHdDGUae
Subject: [Json] What are we trying to do?
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, 03 Jul 2013 05:01:46 -0000

I’m having trouble dealing with the recent proposals from our co-chairs
because I don’t think I understand what they’re trying to achieve.  Just to
refresh, our charter says

“The work is essentially a reclassification in place, with minimal changes.
The working group will   eview errata and update the document as needed to
incorporate those, and will correct significant  errors and
inconsistencies, but will keep changes to a minimum.

It is acknowledged that there are differences between RFC 4627 and the
ECMAScript specification  in the rules for parsing JSON. Any changes that
break compatibility with existing implementations of  either RFC 4627 or
the ECMAScript specification will need to have very strong justification
and broad support. ”

The changes proposed by the chairs are pretty big. Maybe the problem is
that any change which would actually CORRECT the two biggest
errors/inconsistencies in 4267 would necessarily be pretty significant.
When your charter is self-contradictory, you can either re-charter or
decide to ignore one of the two contradictory directives.

I was getting really comfortable with the minimal proposal, which noted
that while the spec more or less means what it says (strings should be
Unicode, objects should have unique keys), there are other standards with
different interpretations.  Also, there is variation among observed
behavior in software, when the JSON RFC’s high-level directives are

What the industry really needs is a document normatively describing
JSON-as-best-practiced, with an RFC number.  It would say that senders MUST
NOT do X and Y, and that receivers, upon encountering X OR Y, MUST DO Z.
Thus  other spec writers can say “Do what RFCXXXX says” and not have to
resort to the sort of drafting pain that the people in Jose are
experiencing right now in order to avoid attacks on cryptographically
signed protocol elements by exploiting variation in dupe-key handling.

Is it the sense of the WG that such a document is within our mandate?  -T