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

[Vadim Goncharov <[e-mail]>]

On Tue, 17 Jan 2023 14:02:46 -0400
Emile Cormier <[e-mail]> wrote:

> 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.

Ah, OK, now I've re-read this more carefully. I agree that recursion
(at least for compound types) must be prohibited.

> > 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).

Then I understand you, but instead of seven new tags I think reference
to Section 4 here and in 3.5.5 should be prohibited. It allows for too
large values if a generic #6.1002 duration would be allowed. In fact,
as most clocks support 1-second resolution, it should give part of
second (no more than 1 second), like Precision field in NTP.

> 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.

Well, I suppose 3 tags should be enough (instead of 2), at maximum, but
seven seems too much - conceptually, a point in time is still one
value, and separate e.g. clock quality would be of no much use alone.

-- 
WBR, @nuclight