Hi Renzo, On Fri, 18 Apr 2025 at 18:08, Renzo Navas via Datatracker <noreply@xxxxxxxx> wrote: > > Document: draft-ietf-core-cf-reg-update > Title: Update to the IANA CoAP Content-Formats Registration Procedures > Reviewer: Renzo Navas > Review result: Ready with Nits > > Disclaimer: I have not been following this document, so I do not have any > context that leads to his current state. > > I categorize my review as “Ready w/nits”, because even if I am being too > verbose, most of my comments are about clarification of some terms (lowercase / > capitalisation), and some hints that can lead to clarification of some > sentences. Other than these “nits” with terms; the document is clear, > “negative” examples (section 3) are useful to exemplify what can go wrong, and, > most importantly, the new procedure (Section 4) is quite clear! Thank you for > this work. > > ------------------ > COMMENTS BEGIN > ------------------- > > Section 2. Lowercase terms seem ok (also used this way in RFC9193), except for > the “content-type” term that is defined and used as “Content-Type” in RFC9193. > Do we want all lowercase terms ? (This term in particular is used only once > later in the document). In any case, the passage > “term->term_rfc9193->definition” can be done unambiguously so not a problem. > > Section 3.3, How do we determine if a parameter’s value is valid ? (given an > existing media type parameter)? (We have to track the values on the “Reference” > column on the Media Type register? E.g., for “cose;cose-type=”, I could not > find it on IANA https://www.iana.org/assignments/media-types/application/cose , > but have to read RFC9052). OK after reading the document, all these cases > (invalid or unknown stuff) will need an “Expert Review” . SUGGESTION: maybe put > a small disclaimer at the beginning of the section? For example: "Unknown or > Invalid values will be detected by a Expert Review". > > Section 4. I think we should erase the word "virtual" (unless it has a specific > meaning, which in that case is not clear what that meaning is). > > Section 4.3: Commenting just to say: amazing QoL addition! > > Section 4.4. In item 1 the term “content coding” is used , but on item 5 the > term “Content Coding” is used, are those different terms or the same? As > defined in Section 2 those terms were all lowercase... if this is the same term > (thus, same meaning) I suggest you should be consistent throughout the document > with the capitalization. If this is a different term.. Well, that is a bit > confusing, and these other terms will need another definition. You can also say > that you are case insensitive in Section 2 (but in any case, I suggest being > consistent with capitalization to avoid all this). > > After carefully reading things, I think the term in item 5 is referring to the > “Content Coding” Column in the CoAP Content-Formats IANA Registry, so maybe > explicitly say "If a Content Coding registry value"... I left my initial > comments/doubts about terms with/without capitalization just to make the point > that maybe where there is that subtlety, the text can help the reader with a > bit of signposting (e.g., add "registry value" in the case I mentioned). (Also, > we are not case insensitive, because in this excerpt the term upper/lower-case > made a difference; so explicitly say the terms are case sensitive in Section > 2?). Thanks very much for your thorough review. We are tracking your comments using the following issues: https://github.com/core-wg/cf-reg-update/issues/72 https://github.com/core-wg/cf-reg-update/issues/73 https://github.com/core-wg/cf-reg-update/issues/74 https://github.com/core-wg/cf-reg-update/issues/75 https://github.com/core-wg/cf-reg-update/issues/76 We'll be back to you as soon as we start processing them. cheers! -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
