Re: [arch-d] draft-iab-protocol-maintenance / JSON feedback

Rob Sayre <sayrer@gmail.com> Mon, 18 July 2022 17:12 UTC

Return-Path: <sayrer@gmail.com>
X-Original-To: architecture-discuss@ietfa.amsl.com
Delivered-To: architecture-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 197C8C13C515 for <architecture-discuss@ietfa.amsl.com>; Mon, 18 Jul 2022 10:12:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.106
X-Spam-Level:
X-Spam-Status: No, score=-2.106 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NYsLw6QCnF-w for <architecture-discuss@ietfa.amsl.com>; Mon, 18 Jul 2022 10:12:09 -0700 (PDT)
Received: from mail-ej1-x62b.google.com (mail-ej1-x62b.google.com [IPv6:2a00:1450:4864:20::62b]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99BE7C15A72B for <architecture-discuss@ietf.org>; Mon, 18 Jul 2022 10:12:09 -0700 (PDT)
Received: by mail-ej1-x62b.google.com with SMTP id tk8so11113305ejc.7 for <architecture-discuss@ietf.org>; Mon, 18 Jul 2022 10:12:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=S1tbVh1xF6uMOGwC8OxfPH489VHtULk6K+en+/NVjho=; b=fYhNYf4RjZglYP9xsMqO3f/eJxUyL5cWxICP3KdUH6u02HYA8uDKCkupFnZqhgRKky Wo0iqQW2l0amUY0n0QDPI18iRbC26h8VYHDMIZ9p07niEgtkR7/QO6aQgQmZEINE26cr 5ZkHywp1qp5/pWHZR2wuw4ntKk8+LB+OuBZNjgRpGx/aL5L1J+ljR5Vs5QSSnTbbW+sE pAJj6vdqhkeO8bm+Uv9Nqxidj6G2QNvgFffWAnZl8XgDky+QcYUy6g0vKsFIpo4Ey+oA mjZxHPG7FEXqIUapiv/zlo95DCXq8uZTP+uN44ycltRAf+gYrKgfMcJKLgUsfFRqljwK h7Ig==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=S1tbVh1xF6uMOGwC8OxfPH489VHtULk6K+en+/NVjho=; b=ZSXKqpiKjHC9kTeR7bzB5+He447rdypsXchY3ab8lVd/8PApdNGhwtapTGQhC1HIh3 tqAx09VntR8U59Zl+BO0LSR/RU0+DXLwKD98I8j8b24x++e5do0R5LmenMsGgYqhloJM 4l5JFxGv7425yitFdXE+wlEHCplr9S7mPMiA1UHKyFzTzLPL4Gg6iqKc3KT8o+QP0vih xWG4sQkCVz1QR2xydGxni0spCb2HUH73ruG0A0sEtBLgKu4W8o0GXpDQk8FhPVsWY97L ASIVckyqRKX6h9metjYbWRDjJU8Wa2vWX86PWvqlDNWK+CSu1wOkOz/2Ym5RvzoQpVff jYEQ==
X-Gm-Message-State: AJIora+foycSX9m/FA7xZxblgXPG13zNg5Ls0ZVdNSMjZOdVRq7g2Sx1 BFZc4TdZqGKLYXsmh9J+o54FjYsncZcul+3XbE/9bBJw
X-Google-Smtp-Source: AGRyM1v/s8StsieRus5uVwPbp58NGembdHk2McSZjrQT7xp9+PF0SW9Nb4kj5O7GbKh08B/zUN3cTUmZ4nSouymNPG0=
X-Received: by 2002:a17:907:a413:b0:72f:1959:f35f with SMTP id sg19-20020a170907a41300b0072f1959f35fmr10920496ejc.112.1658164327473; Mon, 18 Jul 2022 10:12:07 -0700 (PDT)
MIME-Version: 1.0
References: <CAChr6Sxy66Yrr=0wnSGOUFBboFBaJsWzrWduvXep9L5akmYiNg@mail.gmail.com>
In-Reply-To: <CAChr6Sxy66Yrr=0wnSGOUFBboFBaJsWzrWduvXep9L5akmYiNg@mail.gmail.com>
From: Rob Sayre <sayrer@gmail.com>
Date: Mon, 18 Jul 2022 10:11:56 -0700
Message-ID: <CAChr6Sx5OtZLf1c27CzV7UMfHHnRgP5pUbga0+Jij7rtzq5krw@mail.gmail.com>
To: architecture-discuss@ietf.org
Content-Type: multipart/alternative; boundary="000000000000b7ebf305e4177799"
Archived-At: <https://mailarchive.ietf.org/arch/msg/architecture-discuss/cVBQCh2Lryje19JYlVShpwb3ZbI>
Subject: Re: [arch-d] draft-iab-protocol-maintenance / JSON feedback
X-BeenThere: architecture-discuss@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: open discussion forum for long/wide-range architectural issues <architecture-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/architecture-discuss>, <mailto:architecture-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/architecture-discuss/>
List-Post: <mailto:architecture-discuss@ietf.org>
List-Help: <mailto:architecture-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/architecture-discuss>, <mailto:architecture-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 18 Jul 2022 17:12:14 -0000

Hi,

After reading all of these comments, which each contain some correct
statements, I still think the JSON example is a bad one.

Some corrections, as someone who was in both ECMA, the IETF, and the
pre-history:

- there are no comments deliberately, as Crockford thought people would use
them for extensions
- the number precision issue was widely known (Crockford even designed a
thoughtful number format called DEC64, he definitely knew)
- the comma issue was raised by me, but rejected. it wasn't an oversight
that the process missed

I did manage to get one point across: the design of JSON.stringify makes it
difficult to produce invalid JSON. The original API let implementations
insert arbitrary text.

The standardization process was basically: "OK, people like this, but we
can't have them using eval()".

I also raised the point that JSON necessarily implies ECMA262 semantics for
hashmaps and other things, in the IETF process (again, rejected, but not an
oversight).

thanks,
Rob


On Sun, Jul 17, 2022 at 2:56 PM Rob Sayre <sayrer@gmail.com> wrote:

> Hi,
>
> I'm sympathetic to concerns raised in the document, but I think the JSON
> example is not a very good one.
>
> JSON was deliberately underspecified because it would work most of the
> time* in languages where typical payloads could get by using an "eval()"
> function, rather than requiring an implementation at all, JavaScript and
> Python being the most common. RFC4627 was an after-the-fact production, the
> problems were already there.
>
> So, the JSON case is actually showing that loose specification can drive
> adoption (like HTML etc). I do not think that's the point you intended to
> make.
>
> thanks,
> Rob
>
> * the problems mentioned in the draft are real, but rare and often not
> obvious
>