[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 [127.0.0.1]) 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-Level:
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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (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 [209.85.128.178]) 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 10.58.2.137 with SMTP id 9mr325502veu.50.1372827699450; Tue, 02 Jul 2013 22:01:39 -0700 (PDT)
Received: by 10.220.219.200 with HTTP; Tue, 2 Jul 2013 22:01:38 -0700 (PDT)
X-Originating-IP: [209.121.225.215]
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 contravened. 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
- [Json] What are we trying to do? Tim Bray
- Re: [Json] What are we trying to do? Peter brooks
- Re: [Json] What are we trying to do? Nico Williams
- Re: [Json] What are we trying to do? Markus Lanthaler
- Re: [Json] What are we trying to do? Bjoern Hoehrmann
- Re: [Json] What are we trying to do? Paul Hoffman
- Re: [Json] What are we trying to do? Paul Hoffman
- Re: [Json] What are we trying to do? Nico Williams
- Re: [Json] What are we trying to do? Tatu Saloranta
- Re: [Json] What are we trying to do? Tim Bray
- Re: [Json] What are we trying to do? Carsten Bormann
- Re: [Json] What are we trying to do? Nico Williams
- Re: [Json] What are we trying to do? John Cowan
- Re: [Json] What are we trying to do? Norbert Lindenberg
- Re: [Json] What are we trying to do? Tatu Saloranta