Re: [Json] Proposed rechartering for the JSON WG

Tim Bray <tbray@textuality.com> Sun, 09 February 2014 19:10 UTC

Return-Path: <tbray@textuality.com>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8091A1A050F for <json@ietfa.amsl.com>; Sun, 9 Feb 2014 11:10:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level:
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tVfFHYEwVmEA for <json@ietfa.amsl.com>; Sun, 9 Feb 2014 11:10:25 -0800 (PST)
Received: from mail-vc0-f182.google.com (mail-vc0-f182.google.com [209.85.220.182]) by ietfa.amsl.com (Postfix) with ESMTP id 15C491A03E6 for <json@ietf.org>; Sun, 9 Feb 2014 11:10:25 -0800 (PST)
Received: by mail-vc0-f182.google.com with SMTP id id10so4200001vcb.13 for <json@ietf.org>; Sun, 09 Feb 2014 11:10:25 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=UfIeZ5XMnq860khCoxcq0WIL1TdzjxNJIwIIaqL+Gjg=; b=PyYa5gpU/ZtrX4OH1Pls1nPz6Ea5hGGhGB+bcG02/sUMrSbDzGZBf63G56o3O1IksG FP1GHzHqncZW9U6oOkPDOd5lx5kKF2AmFB3KOodlovzvDxFXKl0EdBX8bJ2SYiSFNxK0 iXsST66B6EyzRZAwLzzx7PcAVhoR1W8sMkt769Rweltj7FRleufOzGzZv2W9owv6vKcs B6m5SKUOqigJXiYdT1o7roLsQmg4FVKUOGlUn/Rl6qI0mJs9Var/Ylsw7VKcfNSGgmHq 9HxRjJsSZQR6v8xy1M9nn/0/2I1YQPoX4VVPxFulssJayqZKWqSl2id4jISsOZqLb66o BvoA==
X-Gm-Message-State: ALoCoQncODSjTqf6OD8RGft1E9Qf70j4Hc9RBK23lajaPWGSWEGF/PjsXIfOFEfV9aW5GBE8P5fM
MIME-Version: 1.0
X-Received: by 10.58.49.129 with SMTP id u1mr20897906ven.0.1391973024960; Sun, 09 Feb 2014 11:10:24 -0800 (PST)
Received: by 10.220.98.73 with HTTP; Sun, 9 Feb 2014 11:10:24 -0800 (PST)
X-Originating-IP: [24.84.235.32]
In-Reply-To: <85017697-48CF-420F-9935-B78193953493@tzi.org>
References: <52D9B39C.5020102@cisco.com> <1C1347D2-0D99-4D49-B4C1-199246167D23@vpnc.org> <CAMm+Lwj0phrmP563tBbZJKHeYw=Azh1as6GZOA6rANPpC6PJgA@mail.gmail.com> <CAHBU6iv+-9xQYAjZdfZk7+GeA6J+sjaV5era3L+PiJ9RoauBYg@mail.gmail.com> <CAMm+Lwh0O4+iuaJMUhYgj+0GS8e9b_nZtNNX91hOmjUypsgkTQ@mail.gmail.com> <CAK3OfOhu0GZY9CVQrqD4SyjHLVEoEg1DtYj_6imZbbHtzX2eEw@mail.gmail.com> <CAHBU6iuR0MPm9q483jBMqTRkGV1f2giGNhp+UciQ7rRnrvcEBA@mail.gmail.com> <C271F837-40FD-4E87-A56B-0F0357553923@mnot.net> <7E1F7FE6-E7A9-4B7D-902C-A60D39B7B994@vpnc.org> <8AA70C014EEED3158A177F1C@cyrus.local> <85017697-48CF-420F-9935-B78193953493@tzi.org>
Date: Sun, 09 Feb 2014 11:10:24 -0800
Message-ID: <CAHBU6itF4GyN_nk406pLTFs7MSLM8BXU=J9GxyYtKA1ztxsciQ@mail.gmail.com>
From: Tim Bray <tbray@textuality.com>
To: Carsten Bormann <cabo@tzi.org>
Content-Type: multipart/alternative; boundary="089e013c7136b0adc304f1fdf933"
Cc: Cyrus Daboo <cyrus@daboo.name>, JSON WG <json@ietf.org>
Subject: Re: [Json] Proposed rechartering for the JSON WG
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
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: Sun, 09 Feb 2014 19:10:27 -0000

On Sun, Feb 9, 2014 at 8:32 AM, Carsten Bormann <cabo@tzi.org> wrote:


> Having a minimal parseable description technique for JSON-based protocols
> would save us from tedium such as in RFC 7071 section 6.2.2.
> (Not needing something like that ever again*) in the future is my personal
> benchmark for what we need to achieve here.)
>

Hm, I just went and looked at
http://tools.ietf.org/html/rfc7071#section-6.2.2 - it reads like a
perfectly sensible piece of specification-ware to me. Looks to me like it
leaves implementors very little uncertainty, and it’s easy to understand.
 It all fits on a couple of screens on my laptop. The dorky ALL_CAPS makes
it typographically ugly, but it’s hard to imagine a formalism that would
make it dramatically shorter, or more useful.

I actually thought what we were talking about was something to replace
6.2.1 in that spec, so people don’t ever need to write an “Imported JSON
terms” section again.



>
> The important thing**) here is the 80-20 rule — we don’t need to make this
> thing powerful or perfect, because we can always fall back to English.
> But we shouldn’t always have to, even for the most basic purposes.
>
> (draft-newton looks like an 85 % solution to me; maybe this can be even
> simpler.)
>
> Grüße, Carsten
>
> *) Yes, I know why it was done, and I agree that it had to be done at the
> time.
>
> **) The other important thing is that a JSON description technique doesn’t
> have to be parse as JSON, just as an XML schema does not have to be parse
> as XML.
> Why are people falling into this trap again and again...
>
> _______________________________________________
> json mailing list
> json@ietf.org
> https://www.ietf.org/mailman/listinfo/json
>