[core] SenML data ct indication and string content-format values

[Ari Keränen <[e-mail]>]

Hi all,

Based on the discussions this week with some of you, we are proposing a small further tweak to the SenML data value ct indication draft [1]: since allowing multiple different types of values (e.g., string and int) for a single SenML field causes problems with some high-speed data processing systems, automatic parser generators, and database schemas, it makes sense to avoid that. 

A simple way to avoid this with the "ct" field is to have both the string (content-type and -coding) and integer (CoAP content-format) IDs represented as strings. So, instead of:
"ct": 60
You would use:
"ct":"60"

While that may feel a bit weird design, it is only ~2 extra bytes of overhead (the quotes in JSON and string vs. uint in CBOR), and since this field will be in practice always compared to a small set of known values (i.e., no arithmetic operations involved), there does not seem to be much extra cost representing it as a string. I will present this proposal and the "@content-coding" syntax at the CoRE meeting on Thursday. Looking forward to your comments.


Thanks,
Ari

[1] https://tools.ietf.org/html/draft-keranen-core-senml-data-ct-02