[core] "ni" URIs in SenML names (and no "; " in allowed characters)

[Ari Keränen]

Hi all,

In the Friday CoRE session we discussed that adding ";" to the allowed characters of SenML names could be useful for accommodating for certain kinds of URIs, like "ni". However, as I mentioned during the meeting, whether the ";" character is safe for names needs to be checked with experts on the topic. We got now feedback that it is *not* safe to use that character and should not be included in the character set.

Therefore, instead of allowing ";" in names, we could consider documenting simple translation rule for "ni" URIs: just switch the ";" into ":". In the ni-URIs the ";" character is used just once: between base64 encoded hash and the algorithm used to generate the hash value [1]. And to avoid issues with encoding the authority part, we could use just the alg-val part of the URI as name.

This could be done in the SenML base spec, or we could leave all such translation / name-mapping rules for future spec(s) since they are just a special case for name generation and not a requirement for SenML as such. I'm perhaps leaning towards the latter option to get SenML shipped now.

Comments / opinions on this?


Cheers,
Ari

[1] https://tools.ietf.org/html/rfc6920#section-3

[Peter Saint-Andre - Filament]

Post by Ari Keränen
Hi all,
In the Friday CoRE session we discussed that adding ";" to the
allowed characters of SenML names could be useful for accommodating
for certain kinds of URIs, like "ni". However, as I mentioned during
the meeting, whether the ";" character is safe for names needs to be
checked with experts on the topic. We got now feedback that it is
*not* safe to use that character and should not be included in the
character set.

For the edification of working group participants, can you elaborate on
what the safety issue is? For instance, does using ';' introduce a
security vulnerability in some constrained systems?

Post by Ari Keränen
Therefore, instead of allowing ";" in names, we could consider
documenting simple translation rule for "ni" URIs: just switch the
between base64 encoded hash and the algorithm used to generate the
hash value [1]. And to avoid issues with encoding the authority part,
we could use just the alg-val part of the URI as name.

I'm sure we'd all like to avoid yet more bespoke encoding rules.

Post by Ari Keränen
This could be done in the SenML base spec, or we could leave all such
translation / name-mapping rules for future spec(s) since they are
just a special case for name generation and not a requirement for
SenML as such. I'm perhaps leaning towards the latter option to get
SenML shipped now.

Leaving this out of SenML for now makes sense, but (at the risk of
sounding like a broken record) I'll reiterate that we need to make it
very clear that many URI schemes and URN namespaces can't be used as
SenML names because of the restricted character set.

Peter

[Ari Keränen]

Post by Peter Saint-Andre - Filament

Post by Ari Keränen
Hi all,
In the Friday CoRE session we discussed that adding ";" to the
allowed characters of SenML names could be useful for accommodating
for certain kinds of URIs, like "ni". However, as I mentioned during
the meeting, whether the ";" character is safe for names needs to be
checked with experts on the topic. We got now feedback that it is
*not* safe to use that character and should not be included in the
character set.

For the edification of working group participants, can you elaborate on
what the safety issue is? For instance, does using ';' introduce a
security vulnerability in some constrained systems?

Apparently it's more of a problem for the back-end systems, but I'll let Cullen elaborate on the details since he raised the concerns on this.

Post by Peter Saint-Andre - Filament

Post by Ari Keränen
Therefore, instead of allowing ";" in names, we could consider
documenting simple translation rule for "ni" URIs: just switch the
between base64 encoded hash and the algorithm used to generate the
hash value [1]. And to avoid issues with encoding the authority part,
we could use just the alg-val part of the URI as name.

I'm sure we'd all like to avoid yet more bespoke encoding rules.

That would be nice. In case of "ni" URIs I don't think the translation rule is a big issue, but in general the restricted character set does restrict the usability of URIs as names. However, having such capability is not one of the design goals of SenML, but just the other way around: being able to use names *in* URIs.

Post by Peter Saint-Andre - Filament

Post by Ari Keränen
This could be done in the SenML base spec, or we could leave all such
translation / name-mapping rules for future spec(s) since they are
just a special case for name generation and not a requirement for
SenML as such. I'm perhaps leaning towards the latter option to get
SenML shipped now.

Leaving this out of SenML for now makes sense, but (at the risk of
sounding like a broken record) I'll reiterate that we need to make it
very clear that many URI schemes and URN namespaces can't be used as
SenML names because of the restricted character set.

Yes, I'm planning to incorporate the text you proposed for the updated revision to address this. All, please comment if you think that's a bad idea. It's not a technical change, just clarification of existing rules.


Cheers,
Ari