search

OpenMobileAlliance / OMA_LwM2M_for_Developers

OMA LightweightM2M public resources.
http://openmobilealliance.github.io/OMA_LwM2M_for_Developers/
Other
239 stars 52 forks source link

Core Object implicit versioning between LwM2M patch releases #561

Open Pinioo opened 1 year ago

Pinioo commented 1 year ago

I have a question regarding object versioning rules. I wonder what is the correct version in such a scenario:

The LwM2M server receives a registration from the client, it declares LwM2M version 1.1 and contains object 4 without an explicit object version. Object 4 is a core object defined in protocol specification so the server should assume the object version corresponding to the one contained in the specification, as explained in LwM2M 1.2 Core TS:

If a Core Object version does not correspond to the version contained in the LwM2M Enabler release supported by the LwM2M Client, the Object Version MUST be provided by the LwM2M Client to the LwM2M Server.

However, V1_1-20180710 and V1_1_1-20190617 versions of LwM2M 1.1 specification mention this object with different versions

I would assume a version 1.1 for object 4 since this is the one mentioned in the initial release of LwM2M 1.1 but I can't find it directly explained in the specification.

And don't get me wrong, I don't ask about this particular object, I just want to know the general rule behind it.

sbernard31 commented 1 year ago

That's a really good question which makes me discover that we do not handle default version correctly in Leshan :grimacing:
(https://github.com/eclipse/leshan/issues/1434)

(Note that I'm not member of OMA and not author of the LWM2M specification)

I would assume a version 1.1 for object 4 since this is the one mentioned in the initial release of LwM2M 1.1

I also think the only way to be sure that everybody uses same default value is to take the object version which appears in the initial version of LWM2M Enabler supported.

So I would have expected something like :

If a Core Object version does not correspond to the version contained in the initial LwM2M Enabler release supported by the LwM2M Client, the Object Version MUST be provided by the LwM2M Client to the LwM2M Server.

But looking at the example 4., its seems this is not what it is expected :

  1. An LwM2M Client supporting LwM2M Enabler version 1.1 registers the Server Object version 1.1 ("urn:oma:lwm2m:oma:1.1"), the Device Object version 1.1 ("urn:oma:lwm2m:oma:3:1.1"), and the Connectivity Monitoring Object version 1.2 ("urn:oma:lwm2m:oma:4:1.2"). Because each of these Object versions correspond to the Object versions released as part of the LwM2M Enabler version 1.1, the Object version information can be omitted. The registration payload is:

,</1/0>,</1/1>,</3/0>,</4/0>

Here we both expect that the right payload should be : ,</1/0>,</1/1>,</3/0>,</4/0>;ver="1.2" :grimacing:

So either we missed something OR there is something an issue in specification. So we probably need clarification from OMA.

Note that : In practice when there is an ambiguity between 2 minor version of an object. This is probably better for a server to use the last version of the object because it should be backward-compatible, but of course this will be better to remove the ambiguity at the specification level.

JaroslawLegierski commented 1 year ago

Based on information about the Object 4 (Connectivity Monitoring). In OMA Registry there is all these following versions of this Object 4:

Object_4

If the device says it support globally lwm2m version 1.1, we can see among the 4 above versions, that the Minimum Object Version compatible with LwM2M Version 1.1 is Object Version 1.2. Therefore this is not necessary to explicitly mention ver="1.2" in registration. The question is which version of the object should be the default version in this case: "1.2" (minimum) or "1.3" (because backward-compatibility), ? I think that clarification from OMA is strongly needed.

sbernard31 commented 1 year ago

@JaroslawLegierski, Just to be sure we get it in a same way.

The specification v1.1 says nothing clear how to handle this but specification v1.2 says :

If a Core Object version does not correspond to the version contained in the LwM2M Enabler release supported by the LwM2M Client, the Object Version MUST be provided by the LwM2M Client to the LwM2M Server.

In this specific case where device is using lwm2m v1.1 and object "Connectivity Monitoring" (id:4), the question is limited to should we use object 4 in v1.1 or v1.2 .

More explicitly ;

Unless I missed something, I think we can clearly move aside v1.0 or v1.3 as default version for lwm2m v1.1.

sbernard31 commented 1 year ago

Note that there is exactly same issue with device object :

mlasch commented 1 year ago

I came across exactly the same issues you mention above while working with the Zephyr LwM2M client and Wakaama server. All three specifications (1.0, 1.1, 1.2) define a slightly different default version reporting behavior.

Summary of my understanding:

LwM2M 1.0

LwM2M 1.1

Similar behavior as 1.0.

LwM2M 1.2

My understanding is such, that a server has to look up the version contained in the LwM2M Enabler to restore the object version accordingly. E.g. object 4 version 1.2 for client version 1.1. and object 4 version 1.3 for client version 1.2. The version contained in the LwM2M Enabler for LwM2M 1.2 would be the list defined in Appendix E. LwM2M Objects defined by OMA (Normative).

If a Non-core Object is not version 1.0, the Object Version MUST be provided by the LwM2M Client to the LwM2M Server.

I understand this statement: Always send the object version, if it is not 1.0 for non-core objects.

Finally

I think that clarification from OMA is strongly needed.

I agree, I find it very difficult to implement this in a robust way. A workaround would be, to always report the object version regardless of the optimizations in any LwM2M specification. This would sacrifice a few bytes in the registration message but would improve interoperability between different implementations and LwM2M versions.

sbernard31 commented 1 year ago

@mlasch waiting OMA answer,

Here is what we decide to implement in Leshan :

Do not hesitate to ask if this is not clear.

mlasch commented 1 year ago

@sbernard31 thanks for your message

To summarize this for the Leshan server: Use the core objects defined in the specification in Appendix E as default. For non-core objects use version 1.0 if version was not reported by the client.

sbernard31 commented 1 year ago

Use the core objects defined in the specification in Appendix E as default. For non-core objects use version 1.0 if version was not reported by the client.

This is almost what we implement. I tried to summarize here.

Some definitions: If client doesn't report version of an object, we try to guess this version. Let's call it default version. Let's call a core object an object defined in the specification in Appendix E.

What we implement : For none core object, we use 1.0 as default version. I think there is no ambiguity in the specification here For core object, we use object version defined in Appendix E of the last patch version of the specification we implement. I think the ambiguity in the specification is here especially for object device and connectivity monitoring in LWM2M v1.1.x.

For this last point see this code

Why the last and not the first ? LWM2M v1.1.0 defines :

LWM2M v1.1.1 defines :

We choose to use version from LWM2M v1.1.1 instead of v1.1.0 because last version of those objects (device and connectivity monitoring) are backward compatible so we think this is better for interoperability. (but I guess discussion is still open :slightly_smiling_face: )