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

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

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" (or
  even, for other examples, "n":"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:[e-mail]  | Arbeitergasse 15, A-4400 Steyr
tel:[phone]                | http://www.energyharvesting.at/
                                      | ATU68476614