Hi Thomas, Thank you for your reply. We have updated the document accordingly. Please review and let us know if any further updats are needed or if you approve the document in its current form. We will await approvals from each author prior to moving forward in the publication process.
--Files-- Note that it may be necessary for you to refresh your browser to view the most recent version. Please review the document carefully to ensure satisfaction as we do not make changes once it has been published as an RFC. Updated XML file: https://www.rfc-editor.org/authors/rfc9876.xml Updated output files: https://www.rfc-editor.org/authors/rfc9876.txt https://www.rfc-editor.org/authors/rfc9876.pdf https://www.rfc-editor.org/authors/rfc9876.html Diff files showing all changes made during AUTH48: https://www.rfc-editor.org/authors/rfc9876-auth48diff.html https://www.rfc-editor.org/authors/rfc9876-auth48rfcdiff.html (side by side) Diff files showing all changes: https://www.rfc-editor.org/authors/rfc9876-diff.html https://www.rfc-editor.org/authors/rfc9876-rfcdiff.html (side by side) For the AUTH48 status of this document, please see: https://www.rfc-editor.org/auth48/rfc9876 Best regards, Karen Moore RFC Production Center > On Oct 6, 2025, at 12:09 PM, Thomas Fossati <[email protected]> wrote: > > Hi, all, > > Firstly, Esko noticed the following on a re-read: > > In Section 4.1.2: > > This new column is placed directly to the right of the existing > "Content Type" column > > We suggest removing the word "directly", as IANA has placed it one > position further to the right. > > On Sat, 4 Oct 2025 at 04:02, <[email protected]> wrote: >> >> Authors, >> >> While reviewing this document during AUTH48, please resolve (as >> necessary) the following questions, which are also in the source file. >> >> >> 1) <!--[rfced] Please note that the title has been updated as >> follows. The abbreviation has been expanded per Section 3.6 of >> RFC 7322 ("RFC Style Guide"), and we have rephrased the wording >> for readability. >> >> Note that we also updated the short title that spans the header >> of the PDF as shown below. Please review. >> >> Original (document title): >> Update to the IANA CoAP Content-Formats Registration Procedures >> >> Current: >> Updates to the IANA Registration Procedures for Constrained >> Application Protocol (CoAP) Content-Formats >> >> ... >> Original (short title): >> CoAP Content-Format Registrations Update >> >> Current: >> CoAP Content-Format Registration Updates >> --> > > OK > >> 2) <!--[rfced] In the sentence below, should the First Come First Served >> range be updated from "10000-64999" to "20000-32999" per the >> "CoAP Content-Formats" registry at >> <https://www.iana.org/assignments/core-parameters>? >> >> Original: >> In particular, it defines the rules for obtaining CoAP Content-Format >> identifiers from the "IETF Review or IESG Approval" range of the >> registry (256-9999) as well as from the First Come First Served (FCFS) >> range of the registry (10000-64999). >> >> Perhaps: >> In particular, it defines the rules for obtaining Constrained Application >> Protocol (CoAP) Content-Format identifiers from the "IETF Review or >> IESG Approval" range of the registry (256-9999) as well as from the First >> Come First Served (FCFS) range of the registry (20000-32999). >> --> > > No, the original is correct. This bit refers to §12.3 or RFC7252, and > those were the ranges defined in that context. > >> 3) <!--[rfced] Please clarify "hardens" in the sentence below. Do either of >> the >> suggestion below convey the intended meaning more clearly or do you >> prefer otherwise? >> >> Original: >> This document hardens the registration procedures of CoAP >> Content-Formats in ways that reduce the chances of malicious >> manipulation of the associated registry. >> >> Perhaps: >> This document updates the registration procedures of CoAP >> Content-Formats to reduce the chances >> of malicious manipulation of the associated registry. > > Yes, this one, please. > >> Or: >> This document makes the registration procedures of CoAP >> Content-Formats more concise and thus reduces the chances >> of malicious manipulation of the associated registry. >> --> > > No, not this one; This document is the opposite of "concise" :-) > >> 4) <!-- [rfced] Because the original Section 4.2 was removed from the >> document, >> we also removed the text about Section 4.2 in the following sentence. >> Let us know any concerns. >> >> Original: >> It also removes a note that was added to the registry as a temporary >> patch (Section 4.2), adds a new note concerning temporary >> registrations (Section 4.3) and reserves Content-Format IDs 64998 and >> 64999 for documentation (Section 4.4). >> >> Updated: >> It also adds a new note concerning temporary registrations >> (Section 4.2) and reserves Content-Format IDs 64998 and >> 64999 for documentation (Section 4.3). >> --> > > Perfect. > >> 5) <!-- [rfced] Should "Content Type" be added to the list in the sentence >> below? >> All the other columns in the "CoAP Content-Formats" registry at >> <https://www.iana.org/assignments/core-parameters> are included in this >> list. >> >> Also, should "(if any)" be added after "Content Coding"? We ask because "(if >> any)" is used in the paragraph after this and many of the current entries in >> the registry have an empty Content Coding. > > Yes, please. > >> Last, would it be helpful to list these in the order of the columns in the >> registry? >> >> Original: >> Each entry in the registry must include the Media Type registered >> with IANA, the numeric identifier in the range 0-65535 to be used for >> that Media Type in CoAP, the Content Coding associated with this >> identifier, and a reference to a document describing what a payload >> with that Media Type means semantically. >> >> Perhaps: >> Each entry in the registry must include the Media Type registered >> with IANA, the numeric identifier in the range 0-65535 to be used for >> that Media Type in CoAP, the Content Coding (if any) and Content Type >> associated with this >> identifier, and a reference to a document describing what a payload >> with that Media Type means semantically. >> >> Or (in order of columns in registry): >> Each entry in the registry must include the Content Type, the Content >> Coding (if any), the Media Type registered >> with IANA, the numeric identifier in the range 0-65535 to be used for >> that Media Type in CoAP, and a reference to a document describing what a >> payload >> with that Media Type means semantically. >> --> > > The proposed "Or" is good. > >> 6) <!--[rfced] Table 1 (Section 4.1). FYI: We made the following updates to >> match >> the "CoAP Content-Formats" registry at >> <https://www.iana.org/assignments/core-parameters/>. >> >> a) For the range 64998-64999, we moved "Reserved for Documentation" from the >> "Note" column to the "Registration Procedures" column. >> >> b) For the range 20000-32999, we removed the bullets in the "Note" column. >> --> > > OK > >> 7) <!--[rfced] Should "64998" be "64997" in the following two instances >> since the "Reserved for Documentation" range is "64998-64999"? >> >> Original: >> This section clarifies that the "CoAP Content-Formats" registry >> allows temporary registrations within the 0-64998 range. >> >> Perhaps: >> This section clarifies that the "CoAP Content-Formats" registry >> allows temporary registrations within the 0-64997 range. >> >> ... >> Original: >> Note that in the 10000-64998 range the abandonment of a document >> requesting a Content-Format ID does not cause an entry to be removed. >> >> Perhaps: >> Note that in the 10000-64997 range, the abandonment of a document >> requesting a Content-Format ID does not cause an entry to be removed. >> --> > > Yes, great catch, thank you! > >> 8) <!-- [rfced] FYI: We updated this text as follows. >> >> Original: >> Note that the registration request procedure remains unchanged. A >> requester does not need to fill out the "Media Type" field >> separately, as the necessary information is already provided in the >> "Content Type" field of the request. >> >> Updated: >> In a registration request, the requester does not need to fill out >> the "Media Type" field separately, as the necessary information is >> already provided in the "Content Type" field of the request. >> --> > > OK > >> 9) <!-- [rfced] Please confirm that "IETF Review or IESG Approval" is correct >> here. Or does this apply to all ranges that require "Expert Review"? >> >> Original: >> For each of the following example registration requests, one can >> create a similar instance where the requested registration is for a >> CoAP Content-Format identifier within the "IETF Review or IESG >> Approval" range. >> >> Perhaps: >> For each of the following example registration requests, one can >> create a similar instance where the requested registration is for a >> CoAP Content-Format identifier within all the ranges that require "Expert >> Review". >> --> > > Unfortunately, none of the above is entirely correct. Thank you very > much for your attempts, though! > We have also tried reformulating it a few times, but without success. > We are now reasonably sure that this paragraph could be removed > without any loss of information. It doesn't provide any meaningful > information, and it could cause slight confusion. > It's a remnant from a previous incarnation of the section and no > longer fits cleanly with the surrounding context. > >> 10) <!-- [rfced] Abbreviations >> >> a) FYI - We have added an expansion for the following abbreviation >> per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review >> as well as each expansion in the document to ensure correctness. >> >> Constrained Application Protocol (CoAP) >> >> b) Per the Web Portion of the Style Guide >> <https://www.rfc-editor.org/styleguide/part2/>, once an abbreviation >> has been introduced, the abbreviated form should be used thereafter. >> Given this, would you like to use "DE" in place of "designated expert" >> after the first expansion? >> >> designated expert -> DE >> --> > > Ideally, we would prefer to always fully expand DE to "designated > expert" and eliminate the acronym altogether. > >> 11) <!--[rfced] We note "Content-Type" vs. "Content Type". Should any of >> the instances below be made consistent? The first two instances contain >> hyphens and the latter three instances do not. >> >> Current: >> The combination of Content-Type and Content Coding for which the >> registration is requested must not be already present in the >> "CoAP Content-Formats" registry. >> >> Unfortunately, the rules do not explicitly require checking that the >> combination of Content-Type (i.e., Media Type with optional >> parameters) and Content Coding associated with the requested CoAP >> Content-Format is semantically valid. > > These two look good as they are. > This is "Content-Type" in the sense of §2 of RFC9193. > >> The Content Type must be in the preferred format defined in >> Section 4.1.4. >> >> This section defines the preferred string format for including a >> requested Content Type in the "CoAP Content-Formats" registry. >> >> During the review process, the designated expert(s) or IANA may >> rewrite a requested Content Type into this preferred string format >> before approval. >> --> > > These three look good as they are. > This is the "Content Type" column in the registry, as defined in Errata 4954. > >> 12) <!-- [rfced] Please review the "Inclusive Language" portion of the >> online >> Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language> >> and let us know if any changes are needed. Updates of this nature typically >> result in more precise language, which is helpful for readers. >> >> Note that our script did not flag any words in particular, but this should >> still be reviewed as a best practice. >> --> > > We have reread the document, and nothing special caught our eye. > > Thank you very much for your great work, Karen and Rebecca! > > Thomas & Esko > -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
