Re: [core] SenML and its use in core-interfaces (follow-up on bn/n URI clarification)

[Christian Amsüss <[e-mail]>]

Hello Cullen,
hello core-interfaces authors,

On Fri, Mar 31, 2017 at 07:16:46PM -0500, Cullen Jennings wrote:
> Might be good to have a short phone call about this. I don't think I
> understand what problem we are trying to solve.

sure; let's do this. I'm sending you contact details off-list in
parallel.


Nevertheless, ahead-of-time and for the record:

The examples you've been giving of proper SenML use make it get across
better; and I see the utility of having a format with always unique and
fully given names[1].

The problem I'm trying to solve is that the users of SenML (not in terms
of implementations but in terms of Internet Drafts referencing SenML;
don't know about SDOs) do not follow that line of thought. The two
documents[2] that describe applications on it (core-interfaces,
t2trg-hsml) do so in a way that is not aligned with SenML as you
describe it.

What I've been trying to do with my proposal is to find a way to enable
both use cases (yours of transporting uniquely named sensors' data, and
core-interface's of transporting different resource's values; reading
the latest t2trg-hsml, something similar is already attempted there).

It may well be (and I think more so since your last mail) that those
goals can not be reconciled, and that core-interfaces & co would be
well-advised to stop using SenML (if it's not the right tool for the
job) and specify something else (maybe something different, maybe
something generalized like SenML w/o "n" and unique-name requirements
that's clear about not being SenML compatible).

The situation as I see it now is that SenML is (rightfully) pushing for
a WGLC, but its users are sitting quietly in the WG with different
ideas about it, and I have no clue about why.

Christian


[1] My applications never had a need for strong uniqueness as they
must consider both name and time anyways, but that's not the issue here.

[2] Of the 7 references to the SenML draft[2], 2 are about extending
SenML (with no further issues), 3 merely mention it as a possible
content-format; in detail:
* draft-groves-core-senml-bto-00 (ext)
* draft-groves-core-senml-options-00 (ext)
* draft-ietf-lwig-crypto-sensors-02 (mention)
* draft-groves-core-obsattr-00 (mention)
* draft-keranen-t2trg-rest-iot-04 (mention)
* draft-ietf-core-interfaces-09 (problem: linked batch)
* draft-koster-t2trg-hsml (problem: all examples uri-like)

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