Re: [Cbor] Request for reviewers for external document / Record proposal

Christian Amsüss <christian@amsuess.com> Wed, 20 April 2022 15:41 UTC

Return-Path: <christian@amsuess.com>
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 D05D23A0DD3 for <cbor@ietfa.amsl.com>; Wed, 20 Apr 2022 08:41:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.905
X-Spam-Level:
X-Spam-Status: No, score=-1.905 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
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 UBuig6GqZXbW for <cbor@ietfa.amsl.com>; Wed, 20 Apr 2022 08:41:19 -0700 (PDT)
Received: from smtp.akis.at (smtp.akis.at [IPv6:2a02:b18:500:a515::f455]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 085723A0DDA for <cbor@ietf.org>; Wed, 20 Apr 2022 08:41:17 -0700 (PDT)
Received: from poseidon-mailhub.amsuess.com (095129206250.cust.akis.net [95.129.206.250]) by smtp.akis.at (8.17.1/8.17.1) with ESMTPS id 23KFfDSR043880 (version=TLSv1.2 cipher=ECDHE-ECDSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 20 Apr 2022 17:41:13 +0200 (CEST) (envelope-from christian@amsuess.com)
X-Authentication-Warning: smtp.akis.at: Host 095129206250.cust.akis.net [95.129.206.250] claimed to be poseidon-mailhub.amsuess.com
Received: from poseidon-mailbox.amsuess.com (poseidon-mailbox.amsuess.com [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bf]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 2E34BD0; Wed, 20 Apr 2022 17:41:12 +0200 (CEST)
Received: from hephaistos.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:f4a1:2988:1247:a691]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id E1742FD; Wed, 20 Apr 2022 17:41:06 +0200 (CEST)
Received: (nullmailer pid 642272 invoked by uid 1000); Wed, 20 Apr 2022 15:41:06 -0000
Date: Wed, 20 Apr 2022 17:41:06 +0200
From: Christian =?iso-8859-1?Q?Ams=FCss?= <christian@amsuess.com>
To: Kris Zyp <kriszyp@gmail.com>, "cbor@ietf.org" <cbor@ietf.org>
Cc: Emile Cormier <emile.cormier.jr@gmail.com>, Carsten Bormann <cabo@tzi.org>
Message-ID: <YmApkq89KA0E5xhs@hephaistos.amsuess.com>
References: <5C7719D8-8DCB-41BE-9111-882A02D43506@tzi.org> <CAEs2a6vVL9_wvrbwske80m5P5Y1xKw6_ecitDL9uybf2TsvWHw@mail.gmail.com> <CAEs2a6tW7K71wKfK-EerdntmyTppqDrz=Fjb7BfADXAkH5N3gA@mail.gmail.com> <CAM70yxB_YaRWccUk_UfLgxwd1gSUNxkDmaWfh-15wEiXsVe9Ng@mail.gmail.com> <CAEs2a6s3=jSb2N7+JHntApW9PWgBCUxV5TP5ej7vLfuR4T6fug@mail.gmail.com> <CAM70yxDJFiv=skuU4=vkos9Zk1JpqQ+6xGGDFj6+Tb6gqCdKFg@mail.gmail.com> <7AF3052A-3B03-4F8A-988D-9F7228001C91@tzi.org> <CAM70yxBhyXTGLegrQVFGu1pxKcZDfd6Q+oYDcoyotSPNAun0oA@mail.gmail.com> <CAEs2a6sP0bhJd3JxL15sjYojBfWHON=gmMSYR3esY8aRX-jp4Q@mail.gmail.com> <YmAe9nDsARviDw2d@hephaistos.amsuess.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="WOcqnHDBIEVw8wjI"
Content-Disposition: inline
In-Reply-To: <YmAe9nDsARviDw2d@hephaistos.amsuess.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/cbor/mHYlqxJ3Gf4u-kIpRcUyDOPe_1c>
Subject: Re: [Cbor] Request for reviewers for external document / Record proposal
X-BeenThere: cbor@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Concise Binary Object Representation \(CBOR\)" <cbor.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/cbor>, <mailto:cbor-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cbor/>
List-Post: <mailto:cbor@ietf.org>
List-Help: <mailto:cbor-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/cbor>, <mailto:cbor-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 20 Apr 2022 15:41:22 -0000

Hello Kris,

On Wed, Apr 20, 2022 at 04:55:50PM +0200, Christian Amsüss wrote:
> CBOR group, the text Kris describes the proposal comprehensively. Please
> consider providing feedback on the text -- as the numbers are not
> registered yet, there might still be room for improvement that could
> close once the entries are published.

picking that up myself, I've looked through the document, and have some
suggestions, with the latter two building on the former:

* When inline records are used, as a consumer I might have a hard time
  retrofitting an array to carry the state of having record definitions
  if I discover late that suddenly there appear inline records
  (especially when they're in a mixed array).

  Might it be good practice to wrap such arrays in a record-definitions,
  even if the record-definitions only has 2 elements (N=0)?

* If so, and given that it is established in record-definitions that the
  typical behavior of records is to be assigned incremental tags,
  inline-record might could lose its property number, become N+1, and
  just use the next property number in the given context.

* If you're OK with depending on enumerated alternative data
  items[1][2], and if you decide to go with the first item, then using
  these tags would be an alternative to registering the 55 tags. They
  become usable because "now" the record-referenes always occur in
  context, and the record-definitions could just say that they work that
  way here.

  This would make the low-index records a bit cheaper in terms of space,
  and through the design of the enumerated alternative data items tag
  removes the bounds on the number of record types.

  If this road is taken, you might also consider removing the initial
  item from record-definitions and always start with 0 (mapping to tag
  121 in the current proposal), as here it's not so much any more about
  custom tags but about using a structured set of tags.

  (This all does not work if the expectation is that the configured
  record definitions even work nestedly inside the records, but it was
  not my impression that that would be expected).

Translated examples (staying with your notation; diagnostic notation in
[3]), if you should decide to go with all of these, and assuming the
proposed numbers of [1]:

tag(57342): array(2):[
  array(2):["name", "value"],
  array(3):[
     tag(121): array(2):[
        "one",
        1
     ],
     tag(121): array(2):[
        "two",
        2
     ],
     tag(121): array(2):[
        "three",
        3
     ]
  ]
]

tag(57342): array(1):[
  array(3):[
     tag(57343): array(2):[
        array(2):["name", "value"],
        "one",
        1
     ],
     tag(121): array(2):[
        "two",
        2
     ],
     tag(121): array(2):[
        "three",
        3
     ]
  ]
]

Best regards
Christian


[1]: https://www.ietf.org/archive/id/draft-bormann-cbor-notable-tags-06.html#name-enumerated-alternative-data
[2]: https://mailarchive.ietf.org/arch/msg/cbor/H5UJC4O23728UZhobZ23BFoBoJE

[3]: Examples in diagnostic notation:

57342([
  ["name", "value"],
  [
     121([
        "one",
        1
     ]),
     121([
        "two",
        2
     ]),
     121([
        "three",
        3
     ])
  ]
])

57342([
  [
     57343([
        ["name", "value"],
        "one",
        1
     ]),
     121([
        "two",
        2
     ]),
     121([
        "three",
        3
     ])
  ]
])

-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom