[core] core-interfaces: SenML unit in link format response

[chrysn <[e-mail]>]

hello people who are interested in core-interfaces and SenML,

as of implementing a data logger that heavily relies on SenML and
core-interfaces in describing its resources, it occurred to me that most
of SenML can be viewed as a way to collect many resources that reside
under a resource (or, when used as core.[l]b, resources that are
scattered on a server).

for example, the queries

> GET /s/light
< OK text/plain
< 123

> GET /s/temp
< OK text/plain
< 27.2

etc.

can be collected to the single query

> GET /s
< OK text/plain
< {"e":[
<       {"n":"/s/light", "v":123, "u": "lx"},
<       {"n":"/s/temp", "v":27.2, "u": "degC"}
< ]}

. several details of the SenML response (eg. name, value, update time) can be
mapped to HTTP or CoAP resource data (eg. url, resource representation,
max-age, respectively).

apart from time stamps (which are often 0, and if not, the response
might contain more than a single representation), an important piece
SenML information that can't be easily mapped to CoAP or HTTP are the
units.

i'd like to publish the units in /.well-known/core, so that the
information can be used even by clients that only support plain text
requests, or to get the information to clients that will always observe
(and to keep packages small will choose the smallest representation,
text/plain). three approaches come to my mind, in order of decreasing
preference:

* </s/light>;if="core.s";rt="core.unit.lx" -- register in the rt=
  subregistry of core-parameters

* </s/light>;if="core.s";unit="lx" -- register at link-relations

* use mime-type parameters -- would work for http, but would need an
  individual content-format codepoint in coap

which approach do you consider most promising?

best regards
chrysn

-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom