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
