Summary: Has 3 DISCUSSes. Has enough positions to pass once DISCUSS positions are resolved.
Hopefully this is easy to address: §4.7 talks about how SenML can also be used to configure parameters and controlling actuators. That capability has some rather significant security implications, but I failed to find mention of it in the security considerations. That needs to be explicitly discussed.
Substantive: §4.4: "If this value is a version number larger than the version which the system understands, the system SHOULD NOT use this object." Why not MUST NOT? Are there situations where an implementation might reasonably use an object with a higher version number than the implementation understands? Editorial/Nits: The title is misleading. It makes it sound like the document is just registering media types; in fact it defines SenML. §1, first paragraph: "This format was defined...": The antecedent of "this" is unclear, since the fact the document defines SenML has not yet been mentioned. §4.3, table 1: What do the asterisks mean? §5.1.2, paragraph starting with "Note that...": I'm surprised to find normative requirements buried in a note in an example. §10, first paragraph: " the an integrated sum...": competing articles. §14: "Sensor data can range from information with almost no security considerations..." s/security/privacy
I agree with Ben's DISCUSS. Additionally, I have serious reservations about introducing the concept of "base fields" that apply to subsequent array elemnets unless overridden. It seems to violate an abstraction barrier for at least some of the serialization formats, and prevents snippets from being composable and commutable absent the resolution/normalization process. It does not seem like the markup language and the document contain suffient safeguards against misuse to prevent security holes (both sensor data and commands could be misinterpreted). It seems that some substantially expanded text should be added on the hazards of the non-resolved format and giving guidance on when resolution/normalization must be performed in order to avoid correctness and security issues. There also seem to be sizeable risks associated with the semantics for time values. In particular, both with the use of an implicit-"now-ish", and with positive and negative values being interpreted with respect to a different absolute time base. (The involvement of base time is a further complication -- I do not remember any discussion of the interaction of a (positive) base time and a negative regular time, for example. I also do not remember any discussion of how the "now-ish" semantics make it actively harmful to do things like store-and-forward or archive SenML data (again, absent normalization), or what sort of granularity the "now-ish" semantics are expected to adhere to. (Is "yesterday" still considered "roughly now"?) I understand the desire for this sort of semantics, but the current specification seems to leave many potential problems exposed.
Section 4.4 Just "Considerations" is an unusual subject title. Having no Unit and no Base Unit is allowed, but you don't say what the semantics are in that case (presumably just a dimensionless counter for integers, with units not really being applicable to non-numeric types). Interestingly, Section 5.1.7 deems it fit to use "/" for the unit for a boolean value, even though "/" is supposed to be a (continuous/floating-point) ratio. Section 4.5 Just to double-check: you really do want to privilege this specification's version for eternity, for the purpose of being omitted from resolved records? Section 12.1 is there not some other units registry we can use? I fear begetting https://xkcd.com/927/ . Also, how is/should the table be sorted? Also in Section 12.1, number 9, is the need for case sensitivity in Units (or otherwise?) normatively covered anywhere? If not, should it? Section 12 Are Base fields supposed to get negative CBOR labels (and not other fields)? Is this mentioned explicitly somewhere? (Yes, I know that the intent is for no more CBOR lablels to be allocated, but that is only a SHOULD-level requirement.) In Extensions that are mandatory to understand to correctly process the Pack MUST have a label name that ends with the '_' character. should that say something about "mandatory to understand but not defined in this document"? (Also in 12.3.1 et seq?) Section 13 Why are we talking about "executable content" at all? It seems quite unrelated to the rest of the document.
Thanks to everyone who contributed to this document. --------------------------------------------------------------------------- §9 defines a URI fragment identification scheme that is intended to apply to senml+xml / sensml+xml. Since this uses the "+xml" structured syntax suffix, it has to comply with the fragment identifier considerations associated with that suffix. See: https://www.iana.org/assignments/media-type-structured-suffix/media-type-structured-suffix.xhtml In particular, +xml has requirements around citing section 5 of RFC 7303 (which this document doesn't), as well as requiring support for element() fragments; e.g.: coap://example.com/temp#element(/1/3) must be allowed as an alias for coap://example.com/temp#rec=3 If you want to restrict other aspects of XPointerFramework fragment identifiers, I believe you'll have to say so explicitly.
I share Benjamin's concerns about the ambiguity of time handling, and Ben's concerns about the security implications of writing to devices. I also have concerns about the notion of "now" and relative times with the streaming formats: is it relative to the time the stream was opened? Or relative to the time the record was received? Given that the document highlights time precisions down to the sub-microsecond level, and given that the record sizes are likely to be much smaller than the TCP maximum segment size, this presumably needs to take into consideration possible buffering effects due to Nagle's algorithm. --------------------------------------------------------------------------- §4.3: > | Data Value | vd | 8 | String (*) | string (*) | I find nowhere in the document that explains what these "(*)" notations mean. --------------------------------------------------------------------------- §8: > 8. EXI Representation (application/senml-exi) All the other MIME types here use the structured syntax format, which makes this one stick out as unnecessarily different. Given that the barrier for registering +exi as a suffix is "expert review," and the only real requirement that expert is going to check is a reference suitable for normatively citing (which EXI is by virtue of its appearance in the "Normative References" section of this document), it seems that the correct (and easy) thing to do here is simply go ahead and register "+exi". As an example: we just did this for +gzip; see the RFC Editor Note at https://datatracker.ietf.org/doc/draft-ietf-uta-smtp-tlsrpt/writeup/
Thank you for doing this work. It's impressive.
Authors also need to reply to the IANA review from Klaus Hartke. He has rejected some CoAP registrations as they currently stand (IANA ticket #1055261), and he hasn't heard back from the authors yet.