Subject: [core] SenML suggestions 2/3: Content Format

From: Christian Amsüss <[email-masked]>
Date: Wed, 20 Jul 2016 15:22:36 +0200

Hello everyone interested in SenML,

(for introduction, see the 1/3 mail)

Second, content types.

When multiple resources' representations are sent in a batch, the client
loses the information otherwise present in the Content-Format header

GET /light/1 -> 2.05, Content-Format=0 (text/plain), "1"
GET /light/2 -> 2.05, Content-Format=0 (text/plain), "0"

in the aggregation

GET /light/ -> 2.05, Content-Format=application/senml+json,
[{"n":"1","v":1},{"n":2","v":0}]

. This leaves the client to guess what to actually do with the "sv"
strings. ("bv" and "v" booleans / numerics are a little odd here as this
is a rare situation where a resource has such a representation; I don't
see any harm there tough.)

I suggest that a pair of "cf"/"bcf" (content format, base content
format) be added with the usual "base" mechanism. Their values are an
integer number (like in the Content-Format option or the ct= link-format
parameter) or null, which is the default when neither bcf nor cf are
present, and has the semantics of an absent Content-Format option.

This is relevant in all situations when the transported content is not
text/plain, and would allow removing ambiguity in SenML interpretation
in a way that is widespread practice in unaggregated responses.

(I've considered that strings for mime types might be an option here,
and could be compressed between JSON and CBOR into the content formats
of the CoRE world, but this would be the first time an embedded device
would need to produce those, and should be avoided IMO.)

Best regards
Christian

-- 
Christian Amsüss                      | Energy Harvesting Solutions GmbH
founder, system architect             | headquarter:
mailto:[email-masked]  | Arbeitergasse 15, A-4400 Steyr
tel:+43-664-97-90-6-39                | http://www.energyharvesting.at/
                                      | ATU68476614

---

From: Lennart Dührsen <[email-masked]>
Date: Wed, 20 Jul 2016 18:02:04 +0200

Hi Christian,

> GET /light/2 -> 2.05, Content-Format=0 (text/plain), "0"

This is a very bad idea imho. Such resources and their aggregations
should always be represented in SenML. As I understood it, SenML is
developed precisely to avoid these arbitrary representations of sensor
values.

> see any harm there tough.)

Which "sv" strings..? Can you give a more verbose example of what you mean?

> present, and has the semantics of an absent Content-Format option.

Content format options are not available in all application layer
protocols, and SenML should be independent of the underlying stack,
right? I am strongly against including information from specific
underlying protocols in SenML.

Cheers,
Lennart