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

[Vadim Goncharov <[e-mail]>]

On Mon, 16 Jan 2023 18:34:08 +0100
Carsten Bormann <[e-mail]> wrote:

> > I would prefer clock quality to be a separate tag altogether, so
> > that it is defined in terms of the date/time tag instead of
> > recursively.  
> 
> I’m not sure what’s wrong about recursion.
> But I hear that you would like to be able to carry around separately
> a clock quality data structure (e.g., for factoring out that
> information or to separate out its processing). This could be a map
> that contains only keys that indicate clock quality, including those
> defined in Section 3.5 and any further ones registered. There would
> be no base time and no additional information about the actual time.
> We could discuss whether this should be limited to clock quality only
> or could include, say, key -10 or -11.  If the latter, we’ll need to
> discuss whether timestamp-modifying keys such as -1 are allowed.

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:

  %basehash = (
    key1 => val1,
    key2 => val2,
  );
  %childhash = (
    key2 => val3,
    key4 => val4,
  );

results in

  %final = (
    key1 => val1,
    key2 => val3,
    key4 => val4,
  );

To Emile Cormier: then your fixed-size structs can just have a pointer
to "base" struct", will it be enough?

> > An application wanting to bundle a clock quality along with a
> > date/time could simply group them in a 2-element array (i.e. a
> > tuple).  
> 
> Sure (which might need a tag…).

Or like "namespaces" as tags 25/256 example - some tag (256) for big
outer structure, within it smaller tags (25) have their meaning...

-- 
WBR, @nuclight