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
-->
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).
-->
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.
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.
-->
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).
-->
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.
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.
-->
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.
-->
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.
-->
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.
-->
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".
-->
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
-->
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.
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.
-->
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.
-->
Thank you.
Karen Moore and Rebecca VanRheenen
RFC Production Center
On Oct 3, 2025, at 9:56 PM, [email protected] wrote:
*****IMPORTANT*****
Updated 2025/10/03
RFC Author(s):
--------------
Instructions for Completing AUTH48
Your document has now entered AUTH48. Once it has been reviewed and
approved by you and all coauthors, it will be published as an RFC.
If an author is no longer available, there are several remedies
available as listed in the FAQ (https://www.rfc-editor.org/faq/).
You and you coauthors are responsible for engaging other parties
(e.g., Contributors or Working Group) as necessary before providing
your approval.
Planning your review
---------------------
Please review the following aspects of your document:
* RFC Editor questions
Please review and resolve any questions raised by the RFC Editor
that have been included in the XML file as comments marked as
follows:
<!-- [rfced] ... -->
These questions will also be sent in a subsequent email.
* Changes submitted by coauthors
Please ensure that you review any changes submitted by your
coauthors. We assume that if you do not speak up that you
agree to changes submitted by your coauthors.
* Content
Please review the full content of the document, as this cannot
change once the RFC is published. Please pay particular attention to:
- IANA considerations updates (if applicable)
- contact information
- references
* Copyright notices and legends
Please review the copyright notice and legends as defined in
RFC 5378 and the Trust Legal Provisions
(TLP – https://trustee.ietf.org/license-info).
* Semantic markup
Please review the markup in the XML file to ensure that elements of
content are correctly tagged. For example, ensure that <sourcecode>
and <artwork> are set correctly. See details at
<https://authors.ietf.org/rfcxml-vocabulary>.
* Formatted output
Please review the PDF, HTML, and TXT files to ensure that the
formatted output, as generated from the markup in the XML file, is
reasonable. Please note that the TXT will have formatting
limitations compared to the PDF and HTML.
Submitting changes
------------------
To submit changes, please reply to this email using ‘REPLY ALL’ as all
the parties CCed on this message need to see your changes. The parties
include:
* your coauthors
* [email protected] (the RPC team)
* other document participants, depending on the stream (e.g.,
IETF Stream participants are your working group chairs, the
responsible ADs, and the document shepherd).
* [email protected], which is a new archival mailing list
to preserve AUTH48 conversations; it is not an active discussion
list:
* More info:
https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc
* The archive itself:
https://mailarchive.ietf.org/arch/browse/auth48archive/
* Note: If only absolutely necessary, you may temporarily opt out
of the archiving of messages (e.g., to discuss a sensitive matter).
If needed, please add a note at the top of the message that you
have dropped the address. When the discussion is concluded,
[email protected] will be re-added to the CC list and
its addition will be noted at the top of the message.
You may submit your changes in one of two ways:
An update to the provided XML file
— OR —
An explicit list of changes in this format
Section # (or indicate Global)
OLD:
old text
NEW:
new text
You do not need to reply with both an updated XML file and an explicit
list of changes, as either form is sufficient.
We will ask a stream manager to review and approve any changes that seem
beyond editorial in nature, e.g., addition of new text, deletion of text,
and technical changes. Information about stream managers can be found in
the FAQ. Editorial changes do not require approval from a stream manager.
Approving for publication
--------------------------
To approve your RFC for publication, please reply to this email stating
that you approve this RFC for publication. Please use ‘REPLY ALL’,
as all the parties CCed on this message need to see your approval.
Files
-----
The files are available here:
https://www.rfc-editor.org/authors/rfc9876.xml
https://www.rfc-editor.org/authors/rfc9876.html
https://www.rfc-editor.org/authors/rfc9876.pdf
https://www.rfc-editor.org/authors/rfc9876.txt
Diff file of the text:
https://www.rfc-editor.org/authors/rfc9876-diff.html
https://www.rfc-editor.org/authors/rfc9876-rfcdiff.html (side by side)
Diff of the XML:
https://www.rfc-editor.org/authors/rfc9876-xmldiff1.html
Tracking progress
-----------------
The details of the AUTH48 status of your document are here:
https://www.rfc-editor.org/auth48/rfc9876
Please let us know if you have any questions.
Thank you for your cooperation,
RFC Editor
--------------------------------------
RFC9876 (draft-ietf-core-cf-reg-update-09)
Title : Update to the IANA CoAP Content-Formats Registration
Procedures
Author(s) : T. Fossati, E. Dijk
WG Chair(s) : Jaime Jimenez, Marco Tiloca
Area Director(s) : Gorry Fairhurst, Mike Bishop
--
auth48archive mailing list -- [email protected]
To unsubscribe send an email to [email protected]
