Skip to main content

SenML Data Value Content-Format Indication
draft-ietf-core-senml-data-ct-07

Yes

Francesca Palombini

No Objection

Alvaro Retana
Erik Kline
John Scudder
Martin Duke
Warren Kumari
(Martin Vigoureux)

Note: This ballot was opened for revision 05 and is now closed.

Francesca Palombini Yes

Alvaro Retana No Objection

Erik Kline No Objection

John Scudder No Objection

Lars Eggert No Objection

Comment (2021-09-20 for -05)
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

Martin Duke No Objection

Murray Kucherawy (was Discuss) No Objection

Comment (2021-09-22 for -06)
Thanks to Bron Gondwana for the ARTART review.

Robert Wilton No Objection

Comment (2021-09-21 for -05)
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

Roman Danyliw No Objection

Comment (2021-09-18 for -05)
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?

Warren Kumari No Objection

(Benjamin Kaduk; former steering group member) (was Discuss) No Objection

No Objection (2021-10-13 for -06)
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.

(Martin Vigoureux; former steering group member) No Objection

No Objection (for -05)