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

[Vadim Goncharov <[e-mail]>]

Hi,

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.

I'd note, however, that draft lacks complete CDDL for tag structure,
probably that may be the cause of confusion.

-- 
WBR, @nuclight

On Mon, 16 Jan 2023 19:08:32 -0400
Emile Cormier <[e-mail]> wrote:

> On Mon, Jan 16, 2023 at 5:43 PM Vadim Goncharov
> <[e-mail]> wrote:
> 
> > Sounds like it is "inheritance" what is needed - possibility to have
> > "base" tagged map in a big structure with "settings" keys and
> > smaller "inheriting" ones with just timestamps itself.
> >
> > For simplicity "inheritance" could be defined by just combining keys
> > with overriding, e.g. in Perl example:
> >
> >   <snip example>
> >
> > To Emile Cormier: then your fixed-size structs can just have a
> > pointer to "base" struct", will it be enough?
> >  
> 
> By design, my CBOR decoder's parse events can only contain "atoms",
> where "atoms" are entities (e.g. numbers, strings) that are not
> recursive (e.g. maps and arrays). When my decoder detects a map or
> array, it emits a map_start or array_start event. This is a common
> feature of SAX-style parsers.
> 
> When my CBOR decoder encounters tags 1001 and 1002, it consumes the
> entire map and emits an extended_time parse event. Tag 1003 is
> decoded into an extended_interval parse event. Both extended_time and
> extended_interval contain all available information in an easily
> accessible manner. A deserializer converting extended_time to a
> std::chrono (or std::tm, or whatever) is agnostic of the underlying
> wire format (CBOR, Msgpack, JSON, etc) and shouldn't have to know
> anything about magic CBOR key values like -3, -6, etc.
> 
> The problem right now is that a clock quality attribute can be a
> nested CBOR timestamp, and that nested CBOR timestamp can contain
> clock quality attributes (there is nothing preventing this in the
> draft RFC). Even if I disallow two levels of clock qualities, my
> extended_time is still messy because it contains optional
> clock_quality objects that can optionally contain extended_time. Yuck!
> 
> In my proposed tags 1001 thru 1007, I could parse it like this:
> 
> Tag 1001 -> Time Point -> extended_time
> Tag 1002 -> TIme Duration -> extended_time
> Tag 1003 -> Time Period -> extended_interval
> Tag 1004 -> Clock Quality -> clock_quality
> Tag 1005 -> Precision Time -> precision_time
> Tag 1006 -> Precision Duration -> precision_time
> Tag 1007 -> Precision Period -> precision_interval
> 
> where (simplified):
> 
> struct time_length
> {
>     number seconds; // number is a variant type that can contain
> floats or integers
>     uint64_t subseconds;
>     int subsecondsExponent;
> };
> 
> struct extended_time
> {
>     time_length length;
>     time_scale scale; // none (duration), utc, tai
> };
> 
> struct extended_interval
> {
>     optional<extended_time> start;
>     optional<extended_time> end;
>     optional<time_length> length;
> };
> 
> struct clock_quality
> {
>     optional<time_length> uncertainty; // Yay, no recursion!
>     optional<time_length> guarantee; // Yay, no recursion!
>     optional<uint16_t> variance;
>     optional<uint8_t> classification;
>     optional<uint8_t> accuracy;
> };
> 
> struct precision_time
> {
>     extended_time time;
>     optional<clock_quality> quality;
> }
> 
> struct precision_interval
> {
>     optional<precision_time> start;
>     optional<precision_time> end;
>     optional<precision_time> length;
> }
> 
> See in the above how:
> 1. no recursion is involved
> 2. the parse event data structures are tidy with no circular
> dependencies 3. the size of the data structures are known at compile
> time
> 
> I hope visualizing how the data is actually stored in intermediate
> parse event structures will help convince folks of the advantages of
> decoupling clock quality from "basic" timestamps.
> 
> I sometimes think CBOR goes too far in economizing every possible
> byte over the wire, to the detriment of keeping encoders/decoders
> "stupid" (thus more robust) and not being too taxing on CPU. I
> believe this is one occasion where having an extra byte to carry
> optional clock quality is well worth it.
> 
> Cheers,
> Emile