Core Object implicit versioning between LwM2M patch releases about oma_lwm2m_for_developers HOT 8 OPEN

That's a really good question which makes me discover that we do not handle default version correctly in Leshan 😬
(eclipse-leshan/leshan#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 :

4. 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>,</1/0>,</1/1>,</3/0>,</4/0>

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

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.

from oma_lwm2m_for_developers.

Based on information about the Object 4 (Connectivity Monitoring). In OMA Registry there is all these following versions of this 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.

from oma_lwm2m_for_developers.

@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 ;

• should we use v1.1 from lwm2m v1.1 (see Object URN)
• OR v1.2 from lwm2m v1.1.1

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

from oma_lwm2m_for_developers.

Note that there is exactly same issue with device object :

• device object v1.0 is defined in lwm2m v1.1 (see Object URN)
• and v1.1 is defined in lwm2m v1.1.1

from oma_lwm2m_for_developers.

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

• Defines "Initial Version" to be 1.0.
  • However section 6.2.3 Object Definition and Object Version Usage e) softens this assumption introducing a "minimal Version" which somehow now can also be omitted, I guess only for core objects?
• According to Table 19: Object Version usage rules the object version has to be provided explicitly only if object version is > 1.0 and for non-core objects. I assume non-core objects are Objects defined Outside any LwM2M TS Enabler
• The content of Table 19: Object Version usage rules is not precise. It is not clear what a server should do because the object version may be omitted for core objects of any version.

LwM2M 1.1

Similar behavior as 1.0.

• Table 19: Object Version usage rules is now Table: 7.2.3.-1 Object Version usage rules with the same content.
• "Initial Version" is still 1.0 in section 7.2.1. General Policy

LwM2M 1.2

• Table 19 and Table: 7.2.3.-1 respectively are missing
• Section 7.2.3. Object Definition and Object Version Usage

If a Core Object version does not correspond to 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.

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.

from oma_lwm2m_for_developers.

@mlasch waiting OMA answer,

Here is what we decide to implement in Leshan :

• eclipse-leshan/leshan#1434 (comment)
• eclipse-leshan/leshan#1452

Do not hesitate to ask if this is not clear.

from oma_lwm2m_for_developers.

@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.

from oma_lwm2m_for_developers.

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 :

• device object in version 1.0
• connectivity monitoring in version 1.1

LWM2M v1.1.1 defines :

• device object in version 1.1
• connectivity monitoring in version 1.2

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 🙂 )

from oma_lwm2m_for_developers.