Subject: [Cbor] Another view on tags

From: Laurence Lundblade <[email-masked]>
Date: Fri, 29 Mar 2019 12:07:47 +0100

Seems like a large part of the value of defining tags is in the selection or design of the type itself rather than the actual tagging.  It is the CBOR experts writing down the best way to encode some particular type of data. Epoch-based date is a good example. If you want to put a nice compact date into a CBOR protocol, use the epoch-based date (and don’t do something awkward like repackage ASN.1 GeneralizedTime). Bignums, decimal fractions, big floats and arrays are types designed by CBOR experts. Epoch date, date string and the like are existing types pre-approved for use in CBOR protocols by experts.

Further, these standardized extended types, can be implemented by generalized encoder/decoders and get broad support. This is a big win IMO.

It seems possible and sometimes useful to use these “extended types” without an explicit tag. A protocol might say, a particular data item in a map should be in the format of a bigfloat even though there is no tag 5. You might call this implicit tagging.

I’m not sure where to go next:
- Should we say explicitly that it is OK to use extended data types without a tag?
- Should general encoder decoders have APIs to deal with these extended types even when not tagged? 
- Recommendations for use of explicit or implicit tagging of extended types in protocols? 

LL

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 29 Mar 2019 12:13:40 +0100

On Mar 29, 2019, at 12:07, Laurence Lundblade <[email-masked]> wrote:
> 
> It seems possible and sometimes useful to use these “extended types” without an explicit tag.

Yes.  A somewhat informal way to make use of this in CDDL is:

{
  Nbf: ~time
  Exp: ~time
}

(Where `time` is a `#6.1(number)` as per prelude.)

Grüße, Carsten