Object Versioning or Object and Object Instance Versioning?

[bejost]

A LwM2M-Client that supports LwM2M-1.1 send a register to a LwM2M-Server.

In LwM2M-Specification in chapter "6.2.1 Register Operation" is a table "Registration Parameters" in this table is specified, that a client send in every Registration Request "Objects and Object Instances".

In chapter "7.2.3 Object Definition and Object Version Usage" is object versioning specified.

I have a LwM2M-Server (Leshan) and an Hardware-Module that supports LwM2M-1.1.

The Hardware-Module can't successful registered on the LwM2M-Server. The issue is, that Client send in LwM2M-Register a with Object and Object Instance and Server expects only a Object in register message.

In textual description of chapter 7.2.3 is only Object versioning described, not Object and Object Instance versioning. The examples shows Object and Object Instance Versioning.

Can you please clarify, is there a versioning of objects or of objects and object instances in LwM2M 1.1?

Is it correct, that the server rejects versioned object and object instances? (Because not described in specification only described as examples)

This issue is as well discussed here: Leshan Issue 1273 and here Leshan Issue 1315

[sbernard31]

Hi @bejost,

Thx for opening this ticket, I'm Leshan main maintainer and I hope you will get an answer.

Even if all is already explained in Leshan, I prefer to summarize the issue here for OMA authors.

All LWM2M specs says that Object Version attribute must be attached to Object :

• LWM2M-v1.2.1@core§Table: 5.1.2.-1 Class Attributes
• LWM2M-v1.1.1@cire§Table: 5.1.2.-1 Class Attributes
• LWM2M-v1.0.2@cire§Table 3: Class Attributes

In v1.0.2 and v1.1.1, all examples respect this statement. More than that you can even see that link to object is added just to be able to version object. E.g : </1/0>,</1/1>,</3/0>,</44>;ver= “2.2”,</44/0> at 7.2.3. Object Definition and Object Version Usage

The only ambiguity could come from LWM2M v1.2 examples at 7.2.3. Object Definition and Object Version Usage :

• </1>;ver=1.0,</1/0>,</1/1>,</3/0>
• </1/0>,</1/1>,</3/0>,</44/0>;ver=2.2

So my understanding :

1. This ambiguity doesn't not concern LWM2M v1.0.x and LWM2M v1.1.x.
2. For LWM2M v1.2.x, I strongly bet this is just an example mistake. This happens often and most of the time better to follow text specification than examples.

From Leshan point of view :

1. Leshan v1.x implements LWM2M v1.0.x and Leshan v2.x implements LWM2M v1.1.x. So for now, Leshan is not concerned by this ambiguity.
2. About How Leshan should behave with Non Compliant Implementations ? you can read this wiki page.

For the future, maybe OMA will add this feature ? See eclipse-leshan/leshan#1315 (comment) 🤷

Would be happy to have OMA clarification / confirmation about that. 🙏

[dnav]

The only ambiguity could come from LWM2M v1.2 examples at 7.2.3. Object Definition and Object Version Usage :

• </1>;ver=1.0,</1/0>,</1/1>,</3/0>
• </1/0>,</1/1>,</3/0>,</44/0>;ver=2.2

So my understanding :

1. This ambiguity doesn't not concern LWM2M v1.0.x and LWM2M v1.1.x.
2. For LWM2M v1.2.x, I strongly bet this is just an example mistake. This happens often and most of the time better to follow text specification than examples.

Hi,

This is not an example mistake but a possibility introduced in the latest LwM2M TS:

In "Register", "Register Update", and "Discover" operations, when the Object Version of a given Object is communicated, the LwM2M Client MUST use the Object Version Class attribute ("ver").
If the Object has no Object Instance or several Object Instances, the Object Version attribute MUST be attached to the Object link.
If the Object has exactly one instance, the Object link MAY be omitted. In that case, the Object Version attribute MUST be associated to the Object Instance link.

Now there is still the ever ongoing discussion on the scope of a TS version related to the protocol version...

[sbernard31]

@dnav Thx a lot for clarification. 🙏

This is not an example mistake but a possibility introduced in the latest LwM2M TS

As :

If the Object has exactly one instance, the Object link MAY be omitted. In that case, the Object Version attribute MUST be associated to the Object Instance link.

was only added in v1.2.1.

From the outside that really looks like a mistake which turns on a new feature between v1.2 and v1.2.1 😁.

Anyway, If this is a real feature now, I feel there is maybe a mistake in specification v1.2.1 at Table: 7.3.1.-1 Class Attributes : Object Version attribute attachment is Object and should be Object, Object Instance ?

(or maybe I didn't get what means attachment ? the spec says : "The Level (Object, Object Instance, Resource, Resource Instance) to which an Attribute is attached")

[dnav]

IMHO "attachment" is from a logical point of view, and does not concern the representation in the CoRE-Link payload.

Anyway, If this is a real feature now, I feel there is maybe a mistake in specification v1.2.1 at Table: 7.3.1.-1 Class Attributes : Object Version attribute attachment is Object and should be Object, Object Instance ?

Reading this, my understanding would be that Instances of the same Object could have different versions.

[sbernard31]

Maybe this can be interpreted like this 🤔

Anyway I try to reformulate my point.
If attachment column is the logical point of view then as an implementer, I would really appreciate there is 1 (or several) column(s) in this table which clearly defined different levels where the attribute can be found in CoRE-Link payload (and in write-attribute request). This will remove all ambiguity and make validation easier.

Note that :

• In LWM2M v1.2, there was an attachment and assignation concept for attribute. (see Table: 5.1.1.-1 Attribute Characteristics).
• the assignation level was removed from the table in LWM2M v1.2.1. but there still some chapter which refers to it. See 6.4.4. Observe-Composite Operation.

[mkgillmore]

Group agrees that this issue is resolved and can be closed 10/31/2023

[sbernard31]

@mkgillmore can you elaborate ?

Resolved by what ? and in which version of the specification ?

Especially about #557 (comment)

[bejost]

I agree with @sbernard31: @mkgillmore Can you please elaborate, especially about #557 (comment) ?

The specifications published by the OMA are intended to provide technology that are compatible with each other, regardless of manufacturer/developer.

I asked this question, because i was working with a hardware module, that was unable to send a LwM2M-Register. Root cause was a object/ object instance/ ressource versioning implemented in the firmware and a server, that doesn't accept such a request.

Nobody is perfect, there is no "bug free" perfect software, and there is no perfect specification.

If you start writing software, that is specified in a document, there is always some unclearity or some gaps in the spec.

What approach does the OMA take? Does OMA publish specs with clearification nodes? Where can I find such information?