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

[Christian Amsüss <[e-mail]>]

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