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

From: Cullen Jennings <[email-masked]>
Date: Fri, 31 Mar 2017 19:16:46 -0500

Might be good to have a short phone call about this. I don't think I understand what problem we are trying to solve.

Most the sensors I am dealing with do not have long term stable DNS names. In fact often IP addressed only and in a non unique address space. 

So the HTTP URL one might be doing a HTTP GET on might look like 

http://192.168.0.2/s/temperature <http://192.168.0.2/s/temperature>

And might return 

[
     {"n":"urn:dev:ow:10e2073a01080063","u":"Cel","v":23.1}
]

Note that one of the key principals of SenML is that the name "must result in a globally unique identifier for the resource." This is a key property and critical to applications that process SenML for analytics , ML etc. 

The above is what I mostly what I was thinking about but I can easily imagine that there might be some cases where the device has a long term stable DNS address. So perhaps we have a light bulb that has the long term stable DNS name light22.building3.example.com <http://light22.building3.example.com/> and has a light and temperature resources 

I can imagine that an HTTP GET on 

http://light22.building3.example.com/s <http://light22.building3.example.com/s>/

returning 

[
{ "bn":"light22.building3.example.com-s <http://light22.building3.example.com_s/>-" }
{"n": "light", "v": 123, "u": "lx"},
{"n:" "temp", "v": 27.2, "u": "degC"}
]

I do not think we should support turning a SenML document where you can only figure out the unique name of the sensor is by looking at information outside the SenML document. 

So with that context ... I thought we had fleshed out a way for the URI approach to work and it was the "bn" indicated effectively the HTTP ref. 

I do not think that 

[{"n": "/s/light", "v": 123, "u": "lx"}] 

is a valid SenML in because the name is not globally unique.  If we added an bh (or h) attribute that looked like 

 [{     "h": "http://light22.building3.example.com/s/ <http://light22.building3.example.com/s/>"
	"n": "light", "v": 123, "u": "lx"}] 

Where the h is the same as the URL in the GET, I can see how we could get that transform to something that might work but is seem more or or less the same as using "n" or "bn". 

So with all that said .... I don't think I am clearly understanding what the problems is we are trying to solve. 

Thanks, Cullen

> On Mar 24, 2017, at 6:31 AM, Christian Amsüss <[email-masked] <mailto:[email-masked]>> wrote:
> 
> Hello SenML authors, and hello CoRE Interfaces authors,
> 
> I'd like to follow up on the IETF96 (Berlin) discussion on using URIs
> with SenML after reviewing the mails on the topic and the discussion
> footage. The point of the URI concatenation discussion back then was to
> allow CoRE Interfaces to do what they are currently doing, being
> 
> GET /l/
> [{"n": "/s/light", "v": 123, "u": "lx"},
> {"n:" "/s/temp", "v": 27.2, "u": "degC"}]
> 
> which is supposed to mean the /s/light and /s/temp resources on the
> origin server, and not /l//s/light etc. as it will by the SenML spec.
> 
> 
> In the Berlin discussion, there was a rough agreement on taking a route
> where URI users could use a different attribute to denote their
> anchor/href; this would avoid the pitfalls of doing URI concatenation
> wrong for people who don't use URIs there anyway.
> 
> This has not been fleshed out or at least explored since then AFAICT,
> and I'd like to at least see that there is a route of extensions CoRE
> interfaces can use if we publish SenML as it is now.
> 
> Two questions need answering IMO:
> 
> * Do we want to be able to share documents between "URI users" and
>  "non-URI users"? In many cases this will be possible; for example,
>  batches (as opposed to linked batches as above) would just work with
>  the current name building, and thus be usable by non-URI-aware clients
>  as well.
> 
> * If we want to keep them apart, how would we deal with the requirement
>  of having mandatory uniquely identifying names? A linked batch would
>  certainly not want to repeat names once in "n" and once in "h"
>  notation.
> 
> 
> For a strawman proposal, I'd assume the answers are "we want to allow
> mixed usership", and "the unique name requirement stays". Then we could
> construct an extension like this:
> 
> Resolved records have, in addition to their name, a URI name ("href"),
> which is optional to use but can be mandated to use in certain
> applications (eg. CoRE interfaces). The URI name is formed by doing
> RFC3986 relative URI resolution of the "h" property relative to the "bh"
> base attribute relative to the requested URI. If the "h" property is
> absent on a record, its "n" property provides a default value. If the
> "bh" property is absent on the first record, the "bn" property provides
> a default value.
> 
> This scheme has the properties that
> 
> + Batches (or generally, collections that worked so far) work equally
>  well for non-URI and URI users.
> + Representations stay as compact as they are.
> + The CoRE interfaces can refer to the records' URI names and thus be
>  sure that users must take the necessary steps to resolve relativities
>  correctly, while simpler SenML users arrive at resolved names by
>  concatenating.
> ~ Evaluating the name of, say, linked batch resources still gives a
>  unique name. It might or might not be a valid URI, and might or might
>  not be dereferncable, but since it's agreed on that a name is not
>  necessarily a URI, that's OK. For example, the linked batch of the
>  first example would give resolved "n":"coap://host/l//s/light <coap://host/l//s/light>" (or
>  even, for other examples, "n":"coap://host/l/http://remote/resource <coap://host/l/http://remote/resource>"),
>  but that would still be a unique name.
> - It doesn't survive representation as Resolved Records. (But are they
>  intended to be serialized again at all? How do other extensions cope
>  with Resolved Records?)
> - It defines properties that would, in actual use, barely (if at all)
>  show up. In particular, the CoRE Interfaces examples could stay as
>  they are and never use "h"/"bh". If we just dropped the arguments and
>  only defined a URI property, we're even worse again in the next point:
> - This has a smell of applications defining how to interpret the name,
>  which is what Cullen has already argued against in the July thread.
> 
> If we can live with the above downsides or those of another form of URI
> extension (which might have fewer or others), then I think we can
> procede with SenML as it is, otherwise we should either come up with a
> better URI story, or need SenML to accomodate such uses.
> 
> What do you think?
> 
> Best regards
> Christian
> 
> -- 
> Christian Amsüss                      | Energy Harvesting Solutions GmbH
> founder, system architect             | headquarter:
> mailto:[email-masked] <mailto:[email-masked]>  | Arbeitergasse 15, A-4400 Steyr
> tel:+43-664-97-90-6-39 <tel:+43-664-97-90-6-39>                | http://www.energyharvesting.at/ <http://www.energyharvesting.at/>
>                                      | ATU68476614
> _______________________________________________
> core mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/core

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 31 Mar 2017 19:16:02 -0500

http://192.168.0.2/s/temperature

And might return

[

]

The above is what I mostly what I was thinking about but I can easily imagine that there might be some cases where the device has a long term stable DNS address. So perhaps we have a light bulb that has the long term stable DNS name light22.building3.example.com and has a light and temperature resources

http://light22.building3.example.com/s/

returning

[

{ "bn":"light22.building3.example.com-s-" }

]

I do not think that

[{     "h": "http://light22.building3.example.com/s/"

Thanks, Cullen

On Mar 24, 2017, at 6:31 AM, Christian Amsüss <[email-masked]> wrote:

GET /l/

first example would give resolved "n":"coap://host/l//s/light" (or
even, for other examples, "n":"coap://host/l/http://remote/resource"),

What do you think?

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
_______________________________________________
core mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/core

---

From: Christian Amsüss <[email-masked]>
Date: Sun, 2 Apr 2017 13:51:46 +0200

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