Sensor Measurement Lists (SenML) Fields for Indicating Data Value Content-Format
draft-ietf-core-senml-data-ct-07

Thanks to Bron Gondwana for the ARTART review.

Is there any generic guidance to provide on expected error handling behavior if:

-- ct (or bct) contains a number outside of the 0-65535 range, or an unregistered value per the CoAP Content-Formats?

-- ct (or bct) contains a text value that is not a registered Content-Format-String?

-- ct (or bct) contains a valid Content-Format-String, but an unregistered  Content-Format?

Or is this application specific?

Thanks for the updates in the -06 and the discussion to get there.
I'm happy with where things ended up, and have just one comment
after reading the diff:

The ABNF comment for the "Cleaned up" entries currently says
"leaving the parameter as mandatory", which is only true in a
very specific sense; "leaving the parameter as mandatory within
the grouping" or "leaving the parameter as mandatory when the
separator is present" might be more clear to a reader not focusing
on the specific context of the statement.

The references to IANA registries could be informative, since RFC7252
is already normatively cited.

-------------------------------------------------------------------------------
All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

Section 4. , paragraph 2, nit:
> t" fields (explanation/comments in parenthesis): * "60" (CoAP Content-Format
>                                 ^^^^^^^^^^^^^^
Did you mean "in parentheses"? "parenthesis" is the singular.

These URLs in the document can probably be converted to HTTPS:
 * http://www.iana.org/assignments/senml
 * http://www.iana.org/assignments/core-parameters
 * http://www.iana.org/assignments/http-parameters
 * http://www.iana.org/assignments/media-types

Thanks for this document.

I have to confess that I am less convinced of the need to have two ways to represent this information, i.e., to also support Content-Format-Strings as opposed to always requiring a entry in the CoAP Content-Formats registry.  The CoAP Content-Formats registry seems to be of reasonable size and have a lot of space available for FCFS allocations which would mean that it should be quite easy to extend if required.  However, I'm willing to defer to the authors & CORE WG expertise here supporting both ways are needed/useful.

Regards,
Rob