SenML-CBOR Time reprentation description error ?

[sbernard31]

When reading the LWM2M specification about SenML-CBOR representation of TIME datatype, I see :

Data Type	Text Format	TLV Format	JSON SenML Format	CBOR SenML Format
Time	Represented as an ASCII integer. For example, 1476186613 seconds since Jan 01 1970, which represents Tuesday, 11-Oct-16 11:50:13 UTC, are represented as the ASCII string "1476186613", which has 10 characters/bytes.	Same representation as Integer.	Represented as a number.	:point_right: Represented as date/time strings, as defined in Section 2.4.1 of [RFC7049].

(from : LWM2M-v1.1.1@core§C.2-Data Type Mapping)

Data Type	Text Format	TLV Format	SenML JSON Format	CBOR, LwM2M CBOR, and SenML CBOR Formats
Time	Represented as an ASCII integer. For example, 1476186613 seconds since Jan 01 1970, which represents Tuesday, 11-Oct-16 11:50:13 UTC, are represented as the ASCII string "1476186613", which has 10 characters/bytes.	Same representation as Integer.	Represented as a number.	:point_right: Represented as an unsigned integer or a date/time string, as defined in Section 2.4.1 of [RFC7049].

(from : LWM2M-v1.2@core§C.2-Data Type Mapping)

I saw some contradiction with CBOR and SenML RFC but maybe I just missed the point.

---

About CBOR RFC7049, the specification says about Date and Time:

Tag value 1 is for numerical representation of seconds relative to 1970-01-01T00:00Z in UTC time. (For the non-negative values that the Portable Operating System Interface (POSIX) defines, the number of seconds is counted in the same way as for POSIX "seconds since the epoch" [TIME_T].) The tagged item can be a positive or negative integer (major types 0 and 1), or a floating-point number (major type 7 with additional information 25, 26, or 27). Note that the number can be negative (time before 1970-01-01T00:00Z) and, if a floating- point number, indicate fractional seconds.

So it allows Floating point number and negative one, so is there any reason to limit it to unsigned integer ?

---

About SenML-CBOR RFC8428, there is no value of type date/time, see

• https://datatracker.ietf.org/doc/html/rfc8428#section-4.3
• https://datatracker.ietf.org/doc/html/rfc8428#section-6

And LWM2M specification says that TIME value should be encoded using v which should be a number, see LWM2M-v1.2@core§SenML-JSON-format-and-description

That sounds contradictory with "Represented as date/time strings, as defined in Section 2.4.1 of [RFC7049]." from C.2-Data Type Mapping of LWM2M specification.

[mkgillmore]

@sbernard31 Is this an issue that has been clarified in the IETF?

[sbernard31]

@mkgillmore I'm not sure to see which IETF clarification is needed.

At least from my point of view, the 2 RFC (RFC7049 and RFC8428) are clear.

I think "issue" comes with LWM2M specification.

For CBOR,

LWM2M add some limitation for date compare to RFC. (maybe it's OK but I just ask why ? to be sure this is not an unintentional issue?)

RFCt allows Floating point number and negative one, so is there any reason to limit it to unsigned integer in LWM2M ?

For SenML-CBOR

LWM2M seems to add some contradiction with the RFC. RFC says that v value should be encoded as number. LWM2M says v should be encoded"as a JSON float if the Resource data type is Integer, Float, or Time" but also says Time should be "Represented as date/time strings, as defined in Section 2.4.1 of [RFC7049]".

I think for SenML-CBOR, this should rather be "integers, floating-point numbers, or decimal fractions (CBOR Tag 4) as defined in in Section 6 of RFC8428"

?

[eliasweingaertner]

Well spotted @sbernard31

I also think that the spec is too vague here. The description for TEXT actually makes it clear that LWM2M 1.2 doesn't allow TIME values before Jan 01 1970. The unsigned integer type for the CBOR formats is inline with this restriction, while TLV and SenML JSON allow negative numbers and hence bypass the restriction.

At DMSO, we actually need to decide if we want to enforce TIME always to be newer than Jan 01 1970. In this case, we'd need to put a restriction into the spec for TLV and SENML_JSON. In the contrary case of allowing prior dates, we'd need to turn SENML_JSON to Integer (less range...) and need to discuss what to do with TEXT (for example allow a - prefix)

[sbernard31]

@eliasweingaertner, you raise the point about consistency between all format regarding "allowing TIME values before Jan 01 1970", this is a good point that I missed.

And that point :point_up: should be addressed to correctly answer to my CBOR question, but my question was more why LWM2M limit to string where RFC support String and different kind of number.

For SenML question, this is not too much related. My point was more that "LWM2M say to encode time with string" where "RFC say to use number". (so here LWM2M goes againts RFC)

To be crystal clear, I think the most important point about SenML is that : "Represented as an unsigned integer or a date/time string, as defined in Section 2.4.1 of [RFC7049]." should be replaced by : "Represented as integers, floating-point numbers, or decimal fractions (CBOR Tag 4) as defined in in Section 6 of RFC8428"

[mkgillmore]

Group agrees to remove "unsigned" to the description

[sbernard31]

@mkgillmore, thanks for letting me know that, I really appreciate it. :pray:

I guess your are talking about SenML description, right ?

IF I'm right AND as I understand the specification THEN keeping "a date/time string" is :

• valid from a CBOR . (because https://datatracker.ietf.org/doc/html/rfc7049#section-2.4.1)
• not valid from a SenML-CBOR . (because https://datatracker.ietf.org/doc/html/rfc8428#section-4.3 and https://datatracker.ietf.org/doc/html/rfc8428#section-6)

[eliasweingaertner]

In my opinion, for all CBOR formats we should for each data type simply say that they use the corresponding CBOR data type in RFC7049, as specified in the Table 3, just above paragraph 2.4.1

[sbernard31]

@eliasweingaertner I agree for CBOR. For LWM2M CBOR I didn't know that format so maybe(probably?) this makes sense too.

For SenML-CBOR, I think this is not a good idea because RFC8428 should be followed.