From nobody Mon Jun 26 22:27:57 2023 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 525FCC1524B3 for ; Mon, 26 Jun 2023 22:27:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=wolfmcnally-com.20221208.gappssmtp.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 mzrXh-BrWUce for ; Mon, 26 Jun 2023 22:27:52 -0700 (PDT) Received: from mail-ot1-x330.google.com (mail-ot1-x330.google.com [IPv6:2607:f8b0: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 EC6D3C1524B2 for ; Mon, 26 Jun 2023 22:27:52 -0700 (PDT) Received: by mail-ot1-x330.google.com with SMTP id 46e09a7af769-6b74faaac3bso1358480a34.1 for ; Mon, 26 Jun 2023 22:27:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wolfmcnally-com.20221208.gappssmtp.com; s=20221208; t=1687843672; x=1690435672; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:from:to:cc:subject:date:message-id:reply-to; bh=YzydeW7OH7C031fAonCCNJR6Wmqbt26CRpptmnDqdGc=; b=yxrLSlwNIUu+WHmJBO1KivLqbhuQe2Pm8TGuH/8jodV1mdrDnllsPETVT3n426/eFz zAQEMrn6UQc8x5jKlaXBviAsDxjhopKuZqhD+RA4h5kAkjy5N4I3rt0J2murcqu89X3r ogEHu7X0cmudE17xoIFNH3ScEwcRktDcxrKAjz3SboGd0f6aiIV4baQqbYni4/jq6hRy qe6g6ZIhCbmu+V0NNtBtfbnbnUpO88JnZlM5ruBI6nRJ9Ci21a5rBc2hY30kOOvhTXGk nGPegdZRxigxVI5q98gPgAkhY+AelaNk+k7rYX7/d7htrYjta9Nuj6ppJysZqVAyu96H X2vQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1687843672; x=1690435672; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=YzydeW7OH7C031fAonCCNJR6Wmqbt26CRpptmnDqdGc=; b=IOilHc3mXKO+U7xRZmxysILV99uAT7R4rw3fHbOnLSeazrR+EPneDOdSzO5bGFMnVl EqOebNtWtQ2mQdxPVRx50/BuFAXw85Uwl4o8YVe5I7xeWC+Wn96Sy4TwKX76an1ylhc4 BiYVIkSCim2nRzb7ZN2m/UAuD36q2omxre+iKwk4xAOTmTTSxO4u/ytiGbML+5znyuAl trhRbCP8uMGPp7tz8I07EiD6eOld0kRnbf2ZV80sIH4HpjfIqjD/u9xwUL5t2dy5aUcG n/TlE9vxRoZjmMMOaNvuvxgb9GzqAdGAc55cGJCmvnvEZgdRg/8BqRGzpTXvSTs9awm2 BjOA== X-Gm-Message-State: AC+VfDxZToJjUVV2tcluIi9XvV/7DJiat5i/sib5hFh7BRy2Bj42MIls 0ewEQQb+QTAHR1zAKx7S1jVG/ANME0wUURKKRkc= X-Google-Smtp-Source: ACHHUZ53cBMHK6LRfrRV599Ih8qbSkL5UjiqLFOlZxsbTyvqmoQs6vDf3hpLqrV9yINfZWHauBeC+g== X-Received: by 2002:a05:6358:f1e:b0:12b:e45b:3fac with SMTP id b30-20020a0563580f1e00b0012be45b3facmr18941322rwj.32.1687843671881; Mon, 26 Jun 2023 22:27:51 -0700 (PDT) Received: from smtpclient.apple (ip70-180-193-108.lv.lv.cox.net. [70.180.193.108]) by smtp.gmail.com with ESMTPSA id x3-20020a654143000000b00528b78ddbcesm4387933pgp.70.2023.06.26.22.27.50 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 26 Jun 2023 22:27:51 -0700 (PDT) From: Wolf McNally Message-Id: <2A0D7448-050D-49EF-8C1F-29EC5B8E9534@wolfmcnally.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_5F3FA966-76C0-438A-BB6C-765574E272D5" Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.600.7\)) Date: Mon, 26 Jun 2023 22:27:39 -0700 In-Reply-To: Cc: cbor@ietf.org, Christopher Allen To: Carsten Bormann References: <2B1FA8CC-AD83-4E58-BE27-B6504F555694@wolfmcnally.com> <8551021E-A1A2-4764-B0DF-D3E7591EC9B6@tzi.org> <35A71381-A9DD-479C-A7D5-9B06F70B6F50@wolfmcnally.com> <3CE988BD-C87E-4A0C-ADA8-79124FE1FB51@tzi.org> <382FB8D4-03B8-4B92-B7BA-B3760D77D258@wolfmcnally.com> <7AAE85BD-AD41-445C-B747-B80523B068ED@tzi.org> X-Mailer: Apple Mail (2.3731.600.7) Archived-At: Subject: Re: [Cbor] dCBOR moving from numerically-typeless systems X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.39 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jun 2023 05:27:57 -0000 --Apple-Mail=_5F3FA966-76C0-438A-BB6C-765574E272D5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Carsten, When I said that not all JSON can be converted to dCBOR, I was speaking = of generic JSON, not I-JSON as defined in RFC 7493. The key difference between Gordian dCBOR and (CBOR, JSON, and I-JSON) is = that none of the latter have *determinism* as a primary goal; = *interoperability* in I-JSON=E2=80=99s case yes, but *determinism* as = such, no. Therefore, dCBOR is necessarily strict about how it encodes = and what it accepts as valid for decoding. For example, I-JSON is all about what practices SHOULD be followed for = maximum interoperability, and as such an I-JSON decoder may accept or = reject duplicate map keys. It also specifies that that top-level objects = SHOULD be arrays or objects, primarily due to the way some legacy codecs = were written. In contrast, a dCBOR decoder has no problem accepting any type at the = top level, but MUST reject duplicate map keys. So neither I-JSON nor = CBOR are strict subsets of the other, and this is understandable because = interoperability is a non-goal for dCBOR, and determinism is a non-goal = for I-JSON. While I think conformant I-JSON should be translatable to dCBOR, there = are definitely elements that cannot make the round trip. For instance, = JSON (hence I-JSON) has no representation for INF, -INF, or NAN, while = CBOR (hence dCBOR) does. Notably, neither JSON nor dCBOR have a representation for `undefined`, = while CBOR does. So while I think there are good reasons to define profiles of these data = representation standards as subsets of each other, and while dCBOR is in = fact a strict subset of CBOR, focusing on what is a subset of what in = the whole data representation ecosystem makes it easy to lose sight of = dCBOR=E2=80=99s primary goal: determinism. ~ Wolf > On Jun 25, 2023, at 9:29 AM, Carsten Bormann wrote: >=20 > On 2023-03-12, at 23:02, Wolf McNally wrote: >>=20 >> it *can=E2=80=99t* be a requirement as not all CBOR is valid dCBOR, = and by extension not all JSON can be converted to dCBOR, >=20 > Non sequitur. >=20 > Of course not all CBOR is valid dCBOR. > You could design dCBOR so that all valid CBOR can be converted to = valid dCBOR, but you chose to (slightly) subset the generic data model = instead. > I=E2=80=99d say, quite appropriate for dCBOR=E2=80=99s area of = application. >=20 > The part I don=E2=80=99t understand is about JSON: JSON=E2=80=99s = generic data model already is a pretty heftily proper subset of CBOR. > (JSON does not define a generic data model, but I-JSON RFC 7493 does = record the common assumptions that are needed to make JSON=E2=80=99s = generic data model interoperable). =20 > What is in there that can=E2=80=99t be converted to your design of = dCBOR? >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 --Apple-Mail=_5F3FA966-76C0-438A-BB6C-765574E272D5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Carsten,

When I said that not all = JSON can be converted to dCBOR, I was speaking of generic JSON, not = I-JSON as defined in RFC 7493.

The key = difference between Gordian dCBOR and (CBOR, JSON, and = I-JSON) is that none of the latter have *determinism* as a primary goal; = *interoperability* in I-JSON=E2=80=99s case yes, but *determinism* as = such, no. Therefore, dCBOR is necessarily strict about how it encodes and what it = accepts as valid for decoding.

For example, I-JSON is all about what practices SHOULD be followed = for maximum interoperability, and as such an I-JSON decoder may accept = or reject duplicate map keys. It also specifies that that top-level = objects SHOULD be arrays or objects, primarily due to the way some = legacy codecs were written.

In contrast, a dCBOR = decoder has no problem accepting any type at the top level, but MUST = reject duplicate map keys. So neither I-JSON nor CBOR are strict subsets = of the other, and this is understandable because interoperability is a = non-goal for dCBOR, and determinism is a non-goal for = I-JSON.

While I think = conformant I-JSON should be translatable to dCBOR, there are definitely = elements that cannot make the round trip. For instance, JSON (hence = I-JSON) has no representation for INF, -INF, or NAN, while CBOR (hence = dCBOR) does.

Notably, = neither JSON nor dCBOR have a representation for `undefined`, while CBOR = does.

So while I think there are good reasons to define = profiles of these data representation standards as subsets of each = other, and while dCBOR is in fact a strict subset of CBOR, focusing on = what is a subset of what in the whole data representation ecosystem = makes it easy to lose sight of dCBOR=E2=80=99s primary goal: = determinism.

~ = Wolf

On Jun 25, 2023, at 9:29 = AM, Carsten Bormann <cabo@tzi.org> wrote:

On 2023-03-12, at 23:02, = Wolf McNally <wolf@wolfmcnally.com> wrote:

it *can=E2=80=99t* be a requirement as not all CBOR is = valid dCBOR, and by extension not all JSON can be converted to = dCBOR,

Non sequitur.

Of course not all CBOR = is valid dCBOR.
You could design dCBOR so that all valid CBOR can be = converted to valid dCBOR, but you chose to (slightly) subset the generic = data model instead.
I=E2=80=99d say, quite appropriate for dCBOR=E2=80=99= s area of application.

The part I don=E2=80=99t understand is = about JSON: JSON=E2=80=99s generic data model already is a pretty = heftily proper subset of CBOR.
(JSON does not define a generic data = model, but I-JSON RFC 7493 does record the common assumptions that are = needed to make JSON=E2=80=99s generic data model interoperable). =  
What is in there that can=E2=80=99t be converted to your = design of dCBOR?

Gr=C3=BC=C3=9Fe, = Carsten


= --Apple-Mail=_5F3FA966-76C0-438A-BB6C-765574E272D5--