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

[Vadim Goncharov <[e-mail]>]

On Wed, 18 Jan 2023 17:56:11 -0400
Emile Cormier <[e-mail]> wrote:

> > > [quantity, exponent]
> > >
> > > where 'quantity' is an integer or float, and 'exponent' is an
> > > integer for a 10^(exponent) multiplier for the quantity.  
> >
> > May be two variants of exponent - one decimal, other binary?
> >  
> 
> It could be as simple as:
> 
> [magnitude, radix, exponent]
> 
> where radix is either 2 or 10. I would actually prefer this scheme
> for the subseconds component in Tags 1001-1003 (instead of the
> current messiness of scanning "magic" -3/-6/-9/-12 key values that

If there are only two values of exponent, then it can be encoded
by a single bit, is so needed. Just need to choose from which value
this bit should be sacrificed :-)

> >  But that would require an extra precious byte (Carsten, you need
> > to get a better mobile data plan. ;-)  ).
> >  
> 
> In making that silly joke (intended as genial), it made me think
> about how CBOR would work nicely in the remote telemetry domain with
> radio modems, so I guess there is a case for making CBOR as compact
> as reasonably possible, at the expense of some encoder/decoder
> complexity and CPU usage.
> 
> It's not easy to please everyone, and I don't envy Carson's position.

Well, CBOR is such because of IEEE 802.15.4 where maximal packet size
(MTU) is limited to 128 bytes and the usable space in corner case may
be as small as just 33 bytes. Actually I'm designing protocol able to
run on excatly this Procrustus size, needing even more compactness than
CBOR could offer (going sub-byte resolution and giving up some
genericity), and I can tell you it's very hard to achieve more compact
than CBOR, and definitely with more complex implementation - CBOR is in
fact pretty easy to implement.

-- 
WBR, @nuclight