Re: [Cbor] I-D Action: draft-ietf-cbor-time-tag-04.txt

[Emile Cormier <[e-mail]>]

On Tue, Jan 17, 2023 at 1:46 PM Vadim Goncharov <[e-mail]>
wrote:

> I don't understand what do you mean by "nesting" and where recursion
> is possible at all. Do you mean 1001 tag can contain another 1001
> tagged map inside itself? I don't see such evidence in draft.
> If your parser already slurps all map at once, then it can emit proper
> event (right column of your table) after parsing.
>

The way it currently stands in the draft, a 1001 tag can contain another
1002 tag via a either a clock quality Uncertainty or Guarantee attribute.
See sections 3.5.4 and 3.5.5.

> 3.5.4. Uncertainty (Key -7)
>
> Key -7 (Uncertainty) can be used to represent a known measurement
uncertainty for the clock, as a numeric value in seconds *or as a duration*
(Section 4).

There is nothing in the draft that says a 1002 tag nested within a clock
quality attribute cannot itself contain clock quality attributes. I don't
think there's a reasonable real world case for clock quality attribute
durations to have nested clock qualities, so I'm willing to discard those
nested clock quality attributes in my decoder even if it doesn't strictly
follow the spec.

My proposed alternate set of tags (1001 thru 1007) sidesteps the recursion
situation altogether, at the cost of an extra byte for clock quality
information. It also takes up more slots in the tag registry.