Re: [core-parameters] Heads up for senml-versions

[Carsten Bormann <[e-mail]>]

Hi Esko,

> As an outsider to SenML I think the reason for doing this particular encoding in the version number is not yet well explained in the draft.  Somewhere it should state e.g. "re-purposing the version number is preferred to adding an additional feature-bitmask field in a version-11 format, because shorter to encode in average use cases”.

Re being short as a rationale: See first paragraph of 2.1 (OK, it’s called “efficient” there).

There is an infinite number of other approaches that solve this problem.
The specific one you mention really didn’t come to mind as it is inferior both to the one we chose and the introduction of a separate must-understand feature bit mask (no need to update the version number then).
I’m not sure we should discuss all these potential alternative approaches.

> The registry looks okay from what I can tell!
> For the sake of caution it could be useful to already reserve one feature code (e.g. the last one?) to indicate a far-future-version that doesn't encode a particular set of features but leaves open the door towards a completely different format (not using the feature codes) some day. 

Well, we do have must-understand fields, so we can switch some features over to them whenever we like (possibly earlier than exhaustion of the version number bits).  (See parenthesis in penultimate paragraph of 2.1., which I think also at least partially covers the previous point.)

Grüße, Carsten