Format issue with Read on multi-resource

[mkrstic]

I observed strange behavior when reading empty multi-resources. Here is the flow:

1. LWM2M server sent GET /4/0/7; Accept "application/vnd.oma.lwm2m+json"
2. Anjay client responded with ACK-2.05, content: {"bn":"/4/0/7","e":[{"sv":""}]}

It seems to me that client response is not correct, or at least ambiguous, because it indicates that /4/0/7 is single value resource.

Spec says:

Each entry of the JSON format is a Resource Instance, where the Name attribute need to be prepended by the Base Name attribute to form the unique identifier of this Resource instance

I think client should have sent either: a) If there is a single value then {"bn":"/4/0/7/0","e":[{"sv":""}]} or {"bn":"/4/0/7","e":[{"n": "/0", "sv":""}]} b) {"bn":"/4/0/7","e":[]} when values are absent. Maybe more appropriate would be to send 4.04 Not Found in this situation.

[krwc]

Thanks for the report.

This is not a JSON related problem, but rather a consequence of Connectivity Monitoring Object read handler being broken - it currently (erroneously) returns an empty string instead of an empty array of resources - we are aware of this, and will fix it soon.

Anjay indeed returns an empty JSON list, on attempt to read an empty Multiple Resource. You could observe this by issuing Read on some Multiple Resources implemented in Anjay's Test Object (/1337):

create /1337
=> created /1337/1

read /1337/1/3 accept=JSON
=> {"bn":"/1337/1/3","e":[]}

It might however be confusing that the same resource (/1337/1/3) won't be reported in response to a Read on entire Instance - it doesn't look like it's representable (according to the LwM2M specification).

[mkrstic]

I see. Thank you for your quick reply!

[krwc]

This is now fixed in 1.3.1.