[core] URI fragment use for SenML

[Ari Keränen]

Hi all,

When updating the T2TRG RESTful design draft we discussed role of URI fragments in IoT scenarios and realized that this could be useful for SenML too for addressing parts of a SenML pack.

It's good to note that URI fragments are for client side processing only and never sent on the wire. So the server would still send a full representation, but a fragment identifier allows applications on the client to refer to specific parts of SenML packs.

A potential way to implement this is to use the RFC 7111 ("URI Fragment Identifiers for the text/csv Media Type") row-part style (https://tools.ietf.org/html/rfc7111#section-2.1). For example, on a SenML pack from "sensors/temp", one could address:

3rd record: sensors/temp#rec=3
Records 4 to 7: sensors/temp#rec=4-7
Records from 4 to last: sensors/temp#rec=4-*

To handle base values, we could specify something along the lines of "Fragment MUST resolve (i.e., fill base values) to the same values as the given range in the whole pack would".

Is this something you would consider useful? Should it be added to the SenML spec media type definitions?


Cheers,
Ari

[Cullen Jennings (fluffy)]

Post by Ari Keränen
Hi all,
When updating the T2TRG RESTful design draft we discussed role of URI fragments in IoT scenarios and realized that this could be useful for SenML too for addressing parts of a SenML pack.
It's good to note that URI fragments are for client side processing only and never sent on the wire. So the server would still send a full representation, but a fragment identifier allows applications on the client to refer to specific parts of SenML packs.
3rd record: sensors/temp#rec=3
Records 4 to 7: sensors/temp#rec=4-7
Records from 4 to last: sensors/temp#rec=4-*
To handle base values, we could specify something along the lines of "Fragment MUST resolve (i.e., fill base values) to the same values as the given range in the whole pack would".
Is this something you would consider useful? Should it be added to the SenML spec media type definitions?

I'm sort of trying to figure out where we would use theses - it seem more like query specifiers with ? on URLs might be more useful. I'm not sure. But either way, I think I'd prefer to do them in an extension spec and not the base SenML spec.

[Carsten Bormann]

Post by Cullen Jennings (fluffy)
I'm sort of trying to figure out where we would use theses - it seem more like query specifiers with ? on URLs might be more useful. I'm not sure. But either way, I think I'd prefer to do them in an extension spec and not the base SenML spec.

Extending media type registrations post-facto to include new fragment identifier considerations is a bit icky (it can be done, but it requires special license from the IESG).
Ari and I believe we have figured it out, and it is not rocket-science, but of course contains a number of bike-sheds that we will all paint orange now.
(We can fix any dissonance that might come up in WGLC.)

Grüße, Carsten

[Alexey Melnikov]

Post by Carsten Bormann

Post by Cullen Jennings (fluffy)
I'm sort of trying to figure out where we would use theses - it seem more like query specifiers with ? on URLs might be more useful. I'm not sure. But either way, I think I'd prefer to do them in an extension spec and not the base SenML spec.

Extending media type registrations post-facto to include new fragment identifier considerations is a bit icky (it can be done, but it requires special license from the IESG).

It basically requires submitting a revised media type registration and
would have to go through the same review process as the original
registration. Nothing particularly special as far as IESG is concerned.

Post by Carsten Bormann
Ari and I believe we have figured it out, and it is not rocket-science, but of course contains a number of bike-sheds that we will all paint orange now.
(We can fix any dissonance that might come up in WGLC.)