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?).