Hi Thomas, Great, going to reply on the github issues directly (if needed clarification). Thank you! On Wed, Apr 23, 2025 at 4:57 PM Thomas Fossati <thomas.fossati@xxxxxxxxxx> wrote: > > 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
