Ballot for draft-ietf-core-senml-data-ct
Yes
No Objection
Note: This ballot was opened for revision 05 and is now closed.
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