IETF Logo Mail Archive

Re: [Json] JSON and int64s - any change in current best practice since I-JSON

Rob Sayre <sayrer@gmail.com> Fri, 26 January 2024 23:42 UTC

Return-Path: <sayrer@gmail.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 B857BC15109E; Fri, 26 Jan 2024 15:42:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.107
X-Spam-Level:
X-Spam-Status: No, score=-2.107 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_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 BsN1zGv0iTp1; Fri, 26 Jan 2024 15:42:07 -0800 (PST)
Received: from mail-wm1-x330.google.com (mail-wm1-x330.google.com [IPv6:2a00:1450:4864:20::330]) (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 1E03CC15109D; Fri, 26 Jan 2024 15:42:07 -0800 (PST)
Received: by mail-wm1-x330.google.com with SMTP id 5b1f17b1804b1-40ee9e21fcdso6497275e9.0; Fri, 26 Jan 2024 15:42:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1706312525; x=1706917325; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=Dw8SMeDdO17yCfJR01noI2u27tqEFW5t/v+n16eivck=; b=FU4xQ78yPfOrQ7oJ38tLcyw87Lq4hzSuoV/0vauDVDYARPw7xpwZMRuJhZV+kHJlZn 5mCz34NZchJ3QZvshGZyBc4y+OlJvgdB2e/8yzUYL1Ek3Ioia3O/vU2KZ8cZ1hX5akCd FM4qjfpr87LH7rCq7/beY4cY/diyMD6WnEqq5wXSKeQA0sOMkzlpID7QBhY1n1X73/n+ h8lIijHZYhjyKmhEoHgz/p9BWd5MYt3VUXLN0zDGkRBZ+tUG83tgvpdUteYc6iCszjDR Vded4xs1Ei9VuZ0V6b2+i/jgHgn2IqcMpxwxn7Q2xGD4V2OFvE4x05Lj05x2guxCLVId 1jyQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706312525; x=1706917325; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=Dw8SMeDdO17yCfJR01noI2u27tqEFW5t/v+n16eivck=; b=JVnF2RC9mj9EVF3o89Aq/bxsCpHgu3IG05YqDTNwiLLmhWicPX25JhGRd7qD2KFGNl YLOAEH8utRZ+JUqv5kCWIZXdd6HJjJklGdNNV1uqHqBw0arEa7IxZaSHz1lawNU8qAMP yBK46lK/0553EGpVyClFyywTJbCL5FJA1rkjqSZs8l3L1wplAX+Xml8UXJihoLJpB+oY dVD05+QRWtyK5OBZ54A+4ViTB9QmXWsdbv8n3YgPDNg3Z3XEeTmyJ2sWG9b9CLBZYzum OFB9/QbT3UUwKelmjms21+i/9a/DC87ie321zCo4iDyjqo0Z+CSBXEMQ2FuHSMLPlpaz cfwg==
X-Gm-Message-State: AOJu0YwQCb+QzmyFUWnmXeepJU7ernQWCi5LZ/YUfnmQ7HLskELP8XzM AF0WhLNgbEVljAoPfthgI14tcOrMbp6JPFUukjNK6Bd9q8KJ867BTrS+jszbelW/226L0HV8IFn XspbqGtxUaJGcmGtZ55+3NH9hc4E=
X-Google-Smtp-Source: AGHT+IFdyPEN25Ki0wcnN4aq03SL2PFExfFHnyTvhtXXcvoI/QNTspYCgbM7IYwXQQD+lCmKYcrtZBT5z/K1XX5Qh4k=
X-Received: by 2002:a05:600c:4f50:b0:40e:93b4:25ef with SMTP id m16-20020a05600c4f5000b0040e93b425efmr369535wmq.26.1706312524861; Fri, 26 Jan 2024 15:42:04 -0800 (PST)
MIME-Version: 1.0
References: <87527a42-aaac-4f39-b320-05f18a2808c1@codalogic.com> <C31BF4C8-9E6C-48F8-BF7B-D2C379273B3F@tzi.org> <CAHBU6it4SaLawSiBgK9ySkbxjtHE6CX-P3r=hzcVy4ksoQo-Cg@mail.gmail.com> <CAChr6SxHfLW-A1asAndKJz-AiyJv5QP18bi=_bNdKXw7zYHThw@mail.gmail.com> <CAChr6SweYdCWxSABZ7g20Zd-xBFzcK0Ritq53S7WtjSwc-vLmw@mail.gmail.com> <E5A68370-CC2F-4618-AB39-39A382656616@cursive.net> <807fea1b-a22b-4d6b-aa5d-720c9b12023c@codalogic.com> <09233A73-3A6B-4E6F-AEB8-596AC6442E24@cursive.net> <869950DC-647B-4481-AEF8-9E092384E99F@tzi.org> <CBD32B58-8328-4602-89C6-BC2A7A875A0D@cursive.net> <994E2C0A-4AE0-4720-8C67-913BBF033E11@tzi.org> <0BB09B30-B606-44CC-85DC-95A47E485316@cursive.net> <B22EDB2D-0AD1-4582-9191-EFB40E163F19@tzi.org> <F6EB02CA-C240-4FA1-92A8-C5BB883929C7@cursive.net> <29BD1557-59A1-4578-901B-C626ABBE9A78@tzi.org> <B25E10D2-17CF-4B3D-B04B-BABE3A209B90@cursive.net> <6A73993B-B54D-480D-AF79-081EE9D2E1C8@cursive.net> <F9928C16-9FA4-4ED2-9196-8527B7221E4C@tzi.org>
In-Reply-To: <F9928C16-9FA4-4ED2-9196-8527B7221E4C@tzi.org>
From: Rob Sayre <sayrer@gmail.com>
Date: Fri, 26 Jan 2024 15:41:53 -0800
Message-ID: <CAChr6Sw7_xNoTvMPdE3dbNvwiDaMwpZVg3HhXA9E1vZKV3ty+w@mail.gmail.com>
To: Carsten Bormann <cabo@tzi.org>
Cc: Joe Hildebrand <hildjj@cursive.net>, "json@ietf.org" <json@ietf.org>, cbor@ietf.org, Tim Bray <tbray@textuality.com>
Content-Type: multipart/alternative; boundary="000000000000eb97cb060fe1d7df"
Archived-At: <https://mailarchive.ietf.org/arch/msg/json/jgHaoKLvXJVYVnFJXvm2TI6G61c>
Subject: Re: [Json] JSON and int64s - any change in current best practice since I-JSON
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.39
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: <https://mailarchive.ietf.org/arch/browse/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: Fri, 26 Jan 2024 23:42:07 -0000

On Fri, Jan 26, 2024 at 3:01 PM Carsten Bormann <cabo@tzi.org> wrote:

> On Jan 23, 2024, at 00:54, Joe Hildebrand <hildjj@cursive.net> wrote:
> >
> > I put together a quick requirements doc:
> https://github.com/hildjj/draft-hildebrand-eson-requirements
>
> Did anyone ever mention leaving out the outer braces for a top-level map?
>
> This breaks the self-delimiting property even more, but it is so common
> practice in informal use…
>

The reasoning here is that leading characters can predict the encoding.
Since this ESON thing doesn't require a quote, that's out. I always try to
remind people that correct decisions can become wrong over time, but I
still think this is a good one. Tim pointed this one out already, but I
tried to state it more plainly. It's possible to take the view that
"everything is UTF-8, whatever", but then you'd be losing track of some
very ugly corner cases that JSON handles well.

thanks,
Rob

v2.23.0 | Report a Bug | By Email