RFC 9876

Updates to the IANA Registration Procedures for Constrained Application Protocol (CoAP) Content-Formats

📅 published November 2025, from ietf

RFC 9876 💖 Updates to the IANA Registration Procedures for CoAP Content-Formats

📜 Title: Updates to the IANA Registration Procedures for Constrained Application Protocol (CoAP) Content-Formats 👩‍💻 Authors: T. Fossati (Linaro) and E. Dijk (IoTconsultancy.nl) 🏷️ Category: Standards Track 📅 Date: November 2025 🔢 ISSN: 2070-1721 🔁 Updates: RFC 7252 🚫 Obsoletes: not listed in the header

Abstract ✨

Okay so this doc is basically a glow-up for [RFC7252]. It changes the registration rules for the "CoAP Content-Formats" IANA registry, which lives inside the "Constrained RESTful Environments (CoRE) Parameters" registry group 🧚. It also adds a brand new "Media Type" column to that registry, and it reserves Content-Format identifiers 64998 and 64999 for documentation use only 🎀.

Status of This Memo 📝

This is an Internet Standards Track document.

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9876.

Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.

Table of Contents 🗂️

1.  Introduction
2.  Conventions and Definitions
3.  Security Considerations
4.  IANA Considerations
  4.1.  CoAP Content-Formats Registry
    4.1.1.  Temporary Content-Format Registrations
    4.1.2.  Addition of the Media Type Column to the Registry
    4.1.3.  Expert Review Procedure
    4.1.4.  Preferred Format for the Content Type Field
    4.1.5.  Examples of Invalid Registration Requests
  4.2.  New Note and Reference Additions
  4.3.  Reserving Content-Format Identifiers 64998 and 64999 for
        Documentation
5.  References
  5.1.  Normative References
  5.2.  Informative References
Acknowledgments
Authors' Addresses

1. Introduction 🌸

Okay, so [RFC7252] has this whole section 12.3 that explains how people register CoAP Content-Formats in the "CoAP Content-Formats" registry. That registry lives in the "Constrained RESTful Environments (CoRE) Parameters" group [IANA.core-params]. (Fun fact: the columns of this registry got revised per [Err4954], so the table you see now is a little different from the original one 👀.) The rules hand out identifiers from two ranges. There's "IETF Review or IESG Approval" (256-9999) and "First Come First Served" (FCFS, 10000-64999). For the FCFS range, there's no designated expert involved at all. IANA personnel handle the whole thing by themselves to finalize the registration 💅.

Here's the tea ☕: the rules never explicitly say you have to check that the Content-Type (that's the Media Type plus any optional parameters) and the Content Coding attached to the requested CoAP Content-Format actually make semantic sense together. That check is honestly hard. It needs knowledge from multiple documents and technologies, and it shouldn't be dumped entirely on the registrar 😭. Without guidance, both the registering party and the registrar can get confused, and that has already caused some wrong registrations 💀.

So this document updates [RFC7252] by changing the registration procedures for the "CoAP Content-Formats" registry, which cuts down the risk of unintentional or malicious errors 🛡️. It amends the different ranges of the registry, introduces a review procedure that applies to most ranges, and lets people register temporary Content-Format identifiers ⏳. It also adds the "Media Type" column, and reserves Content-Format identifiers 64998 and 64999 for use in documentation 🦋.

2. Conventions and Definitions 📚

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

This document uses the terms "Media Type", "Content Coding", "Content-Type", and "Content Format" as defined in Section 2 of [RFC9193]. In this document, those terms are fully capitalized 🔠.

3. Security Considerations 🔐

This document updates the registration procedures of CoAP Content-Formats to reduce the chances of malicious manipulation of the associated registry. Its whole job is basically locking the registry down 🔒.

Otherwise, it does not change the Security Considerations of [RFC7252]. So those original security notes still apply, no plot twist there 💁‍♀️.

4. IANA Considerations 🎀

This document updates the IANA procedures defined in [RFC7252] for registering CoAP Content-Formats, as described in Section 4.1. It also adds a new note about temporary registrations (Section 4.2), and it reserves Content-Format IDs 64998 and 64999 for documentation (Section 4.3) 🧚.

More of the IANA stuff (the good details in 4.1 through 4.3) is coming up in part 2 💜.

4.1. CoAP Content-Formats Registry 💖

okay so this section and its subsections replace Section 12.3 of [RFC7252] 🎀

Internet Media Types are labelled with a string, like "application/xml" [RFC2046] 💅. To keep the overhead of using Media Types to say what a payload is nice and small, [RFC7252] made a registry for a subset of Internet Media Types to use in CoAP. Each one got a numeric identifier paired with a Content Coding 🧚. The registry is called "CoAP Content-Formats", and it lives in the "Constrained RESTful Environments (CoRE) Parameters" registry group ✨.

Every entry has to include the Content Type, the Content Coding (if there is one), the Media Type registered with IANA, the numeric identifier in the range 0-65535 that gets used for that Media Type in CoAP, and a reference to a document explaining what a payload with that Media Type means semantically 📚.

CoAP doesn't have a separate way to send Content Coding info with a request or response, so the Content Coding (if any) gets specified for each identifier 🫶. If you're going to use multiple Content Codings with one Media Type, you register a separate Content-Format identifier for each one. Other parameters related to an Internet Media Type can also be defined for a CoAP Content-Format entry, iykyk 🌈.

The registration procedures for CoAP Content-Formats are in Table 1, and honestly it's giving organized 🦋.

+=============+===============+=====================================+
| Range       | Registration  | Note                                |
|             | Procedures    |                                     |
+=============+===============+=====================================+
| 0-255       | Expert Review | Review procedure described in       |
|             |               | RFC 9876, Section 4.1.3.            |
+-------------+---------------+-------------------------------------+
| 256-9999    | IETF Review   | Review procedure described in       |
|             | with Expert   | RFC 9876, Section 4.1.3.            |
|             | Review or     |                                     |
|             | IESG Approval |                                     |
|             | with Expert   |                                     |
|             | Review        |                                     |
+-------------+---------------+-------------------------------------+
| 10000-19999 | Expert Review | Review procedure described in       |
|             |               | RFC 9876, Section 4.1.3.            |
+-------------+---------------+-------------------------------------+
| 20000-32999 | First Come    | FCFS is allowed if the              |
|             | First Served  | registration has no parameters,     |
|             |               | the registration has an empty       |
|             |               | Content Coding, the Media Type is   |
|             |               | not yet used in this registry,      |
|             |               | and the Media Type is registered    |
|             |               | (or approved for registration) in   |
|             |               | the "Media Types" registry          |
|             |               | [IANA.media-types].                 |
+-------------+---------------+-------------------------------------+
| 33000-64997 | Expert Review | Review procedure described in       |
|             |               | RFC 9876, Section 4.1.3.            |
+-------------+---------------+-------------------------------------+
| 64998-64999 | Reserved for  |                                     |
|             | Documentation |                                     |
+-------------+---------------+-------------------------------------+
| 65000-65535 | Experimental  | No operational use                  |
|             | Use           |                                     |
+-------------+---------------+-------------------------------------+

         Table 1: Registration Procedures for CoAP Content-Formats

Because the namespace of single-byte identifiers is so tiny, IANA's policy for additions in the range 0-255 inclusive is "Expert Review", as described in Section 4.5 of RFC 8126 [BCP26] 🔥. For handling temporary allocations within the 0-255 range, also check Section 4.1.1, Paragraph 6.

The 256-9999 range has registration procedures that require "IETF Review with Expert Review" or "IESG Approval with Expert Review". Here's the tea:

  • All assignments under "IETF Review with Expert Review" are made on an "IETF Review" basis per Section 4.8 of RFC 8126 [BCP26], with "Expert Review" also required per Section 4.5 of RFC 8126 [BCP26].

The procedure for early IANA allocation of Standards Track code points defined in [RFC7120] also applies 🧁. When that procedure is used, IANA asks the designated expert(s) to approve the early allocation before registration. Working group chairs are also encouraged to consult the expert(s) early, during the process outlined in Section 3.1 of [RFC7120] 🌸.

  • All assignments under "IESG Approval with Expert Review" are made on an "IESG Approval" basis per Section 4.10 of RFC 8126 [BCP26], with "Expert Review" also required per Section 4.5 of RFC 8126 [BCP26].

The registration policy for the 10000-19999 and 33000-64997 ranges is "Expert Review", following the procedure described in Section 4.1.3 💜.

The registration policy for the 20000-32999 range is FCFS 🍓. A registration request for this range must consist solely of a registered Media Type name in the "Content Type" field, without any parameter names or "Content Coding", and the Media Type must not have been used in this registry yet. If those criteria don't apply, you can request a registration for a different range instead, which requires "Expert Review" 🙈.

The identifiers between 65000 and 65535 inclusive are reserved for experiments ⭐. They're not meant for vendor-specific use of any kind, and they MUST NOT be used in operational deployments 💀.

In machine-to-machine (M2M) applications, generic Internet Media Types like text/plain, application/xml, or application/octet-stream are not expected to be useful for real applications in the long term 😭. It is recommended that M2M applications using CoAP request new Internet Media Types from IANA that describe the semantic information about how to create or parse a payload. For example, a Smart Energy application payload carried as Concise Binary Object Representation (CBOR) might request a more specific type like application/se+cbor ✨.

4.1.1. Temporary Content-Format Registrations 🦋

This section clarifies that the "CoAP Content-Formats" registry allows temporary registrations within the 0-64997 range.

A temporary registration can be created, for example, by an IANA early allocation action [RFC7120]. If the referenced Media Type is provisional (meaning it's included in the "Provisional Standard Media Type Registry" [IANA.prov-media-types]), then the created registration is always temporary 🌈.

IANA marks a temporary registration as such in the corresponding registry entry. Once the required registration procedure (defined in Table 1) for the temporary ID has successfully completed, and the referenced Media Type is included in the "Media Types" registry [IANA.media-types], IANA must remove any indication of the temporary nature of the registration, so the entry becomes permanent 🎀.

If a temporary registration doesn't successfully complete the registration procedure, IANA must remove the entry and set the Content-Format ID value back to "Unassigned" 😬. This can happen, for example, when an Internet-Draft requesting a Content-Format ID is abandoned. If a temporary registration (in any range) refers to a provisional Media Type that is abandoned, IANA must remove the entry and set the Content-Format ID value back to "Unassigned" 🥀.

Note that in the 10000-64997 range, abandoning a document that requests a Content-Format ID does not cause an entry to be removed. That's because the required registration procedure for this range doesn't require completion of any standards process, nor does it require a registering document 🧚.

Temporary registrations within the 0-255 range are exempt from the formal renewal process outlined in [RFC7120]. Specifically, IANA won't monitor the removal of registrations in this range. Instead, the designated experts direct IANA to carry out this task 👑.

4.1.2. Addition of the Media Type Column to the Registry 🌸

To help users of the "CoAP Content-Formats" registry find detailed info about the Media Type linked to each CoAP Content-Format, and to make sure a Media Type exists before a new entry can be registered, IANA added a new column called "Media Type" to the registry 💅. This new column sits to the right of the existing "Content Type" column.

The "Media Type" field for each entry lists the (base) Media Type name and provides a hyperlink to the registration info for that Media Type, as recorded by IANA. If the Media Type is provisional, the hyperlink points to the "Provisional Standard Media Type Registry" [IANA.prov-media-types]. If a provisional Media Type becomes permanent, IANA must update the "Media Type" field in the associated registry entries so the hyperlink goes to the registration info for that Media Type ✨.

In a registration request, you don't need to fill out the "Media Type" field separately, because the necessary info is already given in the "Content Type" field of the request 🫶.

4.1.3. Expert Review Procedure 🔥

The designated expert is instructed to perform the "Expert Review", following this checklist 📝:

  1. The combination of Content-Type and Content Coding for which the registration is requested must not already be present in the "CoAP Content-Formats" registry.
  2. The Media Type associated with the requested Content-Format must be either registered in the "Media Types" registry [IANA.media-types] or approved for registration. Alternatively, it may be listed in the "Provisional Standard Media Type Registry" [IANA.prov-media-types]. Provisional standard Media Types are only permitted for Content-Format identifiers within the ranges of 0-255 and 256-9999 🍓.
  3. The optional parameter names must have been defined in association with the Media Type, and any parameter values associated with those names must be as permitted 🙈.
  4. The Content Type must be in the preferred format defined in Section 4.1.4 💜.
  5. If a Content Coding is specified, it must exist (or must have been approved for registration) in the "HTTP Content Coding Registry" within the "Hypertext Transfer Protocol (HTTP) Parameters" registry group [IANA.http-params] 🌈.

For the 0-255 range, in addition to the checks above, the designated expert is also instructed to evaluate the requested code point with regard to the limited availability of the 1-byte code point space 🧁. For the ranges 256-9999, 10000-19999, and 33000-64997, a similar criterion may also apply where combinations of Media Type parameters and Content Coding choices consume a considerable amount of code point space 🦋.

4.1.4. Preferred Format for the Content Type Field ✨

This section sets the preferred string format for putting a requested Content Type into the "CoAP Content-Formats" registry 💅. During review, the designated expert(s) or IANA may rewrite a requested Content Type into this preferred string format before approval 🧚.

The preferred string format is as defined in Section 8.3.1 of [RFC9110] and follows these rules 🎀:

  1. For any case-insensitive elements, lowercase characters are used.
  2. Parameter values are only quoted if the value is such that it requires use of a quoted-string per Section 5.6.6 of [RFC9110]. Otherwise, a parameter value is included unquoted.
  3. A single semicolon character without any adjacent whitespace characters is used as the separator between the Media Type and parameters.

4.1.5. Examples of Invalid Registration Requests 🙈

Okay, this section is full of examples of registration requests for the "CoAP Content-Formats" registry that are invalid 💀. They would still get approved under the procedure defined in Section 12.3 of [RFC7252] 😭. The checklist defined in Section 4.1.3 should prevent any of these attempts from succeeding 🫶. These examples are a representative sample, not an exhaustive one, so the designated expert's eye gets trained on invalid registration attempts 👀.

All the example registration requests use two CoAP Content-Format identifiers: 64998 and 64999 🌸.

4.1.5.1. The Media Type is Unknown

The registrant requests an FCFS Content-Format ID for an unknown Media Type 🫠:

        +==========================+================+=======+
        | Content Type             | Content Coding | ID    |
        +==========================+================+=======+
        | application/unknown+cbor | -              | 64999 |
        +--------------------------+----------------+-------+

            Table 2: Attempt at Registering Content-Format
                      for an Unknown Media Type

4.1.5.2. The Media Type Parameter is Unknown

The registrant requests an FCFS Content-Format ID for an existing Media Type that has an unknown parameter 🤨:

  +======================================+================+=======+
  | Content Type                         | Content Coding | ID    |
  +======================================+================+=======+
  | application/cose;unknown-parameter=1 | -              | 64999 |
  +--------------------------------------+----------------+-------+

      Table 3: Attempt at Registering Content-Format for a Media
                    Type with an Unknown Parameter

4.1.5.3. The Media Type Parameter Value is Invalid

The registrant requests an FCFS Content-Format ID for an existing Media Type with an invalid parameter value 🙃:

   +====================================+================+=======+
   | Content Type                       | Content Coding | ID    |
   +====================================+================+=======+
   | application/cose;cose-type=invalid | -              | 64999 |
   +------------------------------------+----------------+-------+

      Table 4: Attempt at Registering Content-Format for a Media
                 Type with an Invalid Parameter Value

4.1.5.4. The Content Coding is Unknown

The registrant requests an FCFS Content-Format ID for an existing Media Type with an unknown Content Coding 🥴:

         +========================+================+=======+
         | Content Type           | Content Coding | ID    |
         +========================+================+=======+
         | application/senml+cbor | inflate        | 64999 |
         +------------------------+----------------+-------+

            Table 5: Attempt at Registering Content-Format
                     with Unknown Content Coding

4.1.5.5. Duplicate Entry with Default Media Type Parameters

Here the registrant requests an FCFS Content-Format ID for a Media Type that includes a parameter set to its default value 🔁. Meanwhile, a (hypothetical) Content-Format ID 64998 is already registered for this Media Type without that parameter. So this could lead to two separate Content-Format IDs for the same "logical" entry 😵‍💫.

    +==================================+================+=======+
    | Content Type                     | Content Coding | ID    |
    +==================================+================+=======+
    | application/my                   | -              | 64998 |
    +----------------------------------+----------------+-------+
    | application/my;parameter=default | -              | 64999 |
    +----------------------------------+----------------+-------+

        Table 6: Attempt at Registering an Equivalent Logical
             Entry with a Different Content-Format ID (1)

4.1.5.6. Duplicate Entry with Default Content Coding

The registrant requests an FCFS Content-Format ID for the "identity" Content Coding, which is the default coding 🙄. If accepted, this request would duplicate an entry with (hypothetical) Content-Format ID 64998, where the "Content Coding" field is left empty 🍓.

             +================+================+=======+
             | Content Type   | Content Coding | ID    |
             +================+================+=======+
             | application/my | -              | 64998 |
             +----------------+----------------+-------+
             | application/my | identity       | 64999 |
             +----------------+----------------+-------+

                  Table 7: Attempt at Registering an
                   Equivalent Logical Entry with a
                   Different Content-Format ID (2)

4.1.5.7. Duplicate Entry with Equivalent Parameter

The registrant requests an FCFS Content-Format ID for a Media Type that includes a parameter 🦋. The value of this parameter looks distinct from that of a (hypothetical) previously registered Content-Format ID 64998 that also includes this parameter. But the semantics of the parameter value are identical to the existing registration 🤓.

In this example, the eat_profile parameter value (which can be any URI) is set as a Uniform Resource Name (URN) [RFC8141]. Since the Namespace Identifier (example, in this case) for URNs is defined as case insensitive, the two registrations are semantically identical 💜.

  +=====================================+================+=======+
  | Content Type                        | Content Coding | ID    |
  +=====================================+================+=======+
  | application/                        | -              | 64998 |
  | eat+cwt;eat_profile="urn:example:1" |                |       |
  +-------------------------------------+----------------+-------+
  | application/                        | -              | 64999 |
  | eat+cwt;eat_profile="urn:EXAMPLE:1" |                |       |
  +-------------------------------------+----------------+-------+

    Table 8: Attempt at Registering an Equivalent Logical Entry
               with a Different Content-Format ID (3)

4.2. New Note and Reference Additions ✨

IANA has added the following note to the registry 📝:

|  Note: As per RFC 9876, temporary registrations within the 0-255
|  range are approved by designated experts.  These registrations are
|  not subject to the formal renewal process in [RFC7120].

IANA has also listed this document as an additional reference for the registry 📚.

4.3. Reserving Content-Format Identifiers 64998 and 64999 for Documentation 🎀

IANA has reserved Content-Format identifiers 64998 and 64999 for use in documentation 🧸.

5. References 📚

5.1. Normative References

[BCP26] Best Current Practice 26, https://www.rfc-editor.org/info/bcp26. At the time of writing, this BCP comprises the following:

Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, https://www.rfc-editor.org/info/rfc8126.

[IANA.core-params] IANA, "Constrained RESTful Environments (CoRE) Parameters", https://www.iana.org/assignments/core-parameters.

[IANA.http-params] IANA, "Hypertext Transfer Protocol (HTTP) Parameters", https://www.iana.org/assignments/http-parameters.

[IANA.media-types] IANA, "Media Types", https://www.iana.org/assignments/media-types.

[IANA.prov-media-types] IANA, "Provisional Standard Media Type Registry", https://www.iana.org/assignments/provisional-standard-media-types.

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, https://www.rfc-editor.org/info/rfc2119.

[RFC7120] Cotton, M., "Early IANA Allocation of Standards Track Code Points", BCP 100, RFC 7120, DOI 10.17487/RFC7120, January 2014, https://www.rfc-editor.org/info/rfc7120.

[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained Application Protocol (CoAP)", RFC 7252, DOI 10.17487/RFC7252, June 2014, https://www.rfc-editor.org/info/rfc7252.

[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, https://www.rfc-editor.org/info/rfc8174.

[RFC9110] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "HTTP Semantics", STD 97, RFC 9110, DOI 10.17487/RFC9110, June 2022, https://www.rfc-editor.org/info/rfc9110.

[RFC9193] Keränen, A. and C. Bormann, "Sensor Measurement Lists (SenML) Fields for Indicating Data Value Content-Format", RFC 9193, DOI 10.17487/RFC9193, June 2022, https://www.rfc-editor.org/info/rfc9193.

5.2. Informative References

[Err4954] RFC Errata, Erratum ID 4954, RFC 7252, https://www.rfc-editor.org/errata/eid4954.

[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, DOI 10.17487/RFC2046, November 1996, https://www.rfc-editor.org/info/rfc2046.

[RFC8141] Saint-Andre, P. and J. Klensin, "Uniform Resource Names (URNs)", RFC 8141, DOI 10.17487/RFC8141, April 2017, https://www.rfc-editor.org/info/rfc8141.

Acknowledgments 🫶

Thank you Amanda Baber, Carsten Bormann, Christer Holmberg, Éric Vyncke, Francesca Palombini, Ketan Talaulikar, Marco Tiloca, Mohamed Boucadair, Paul Wouters, Renzo Navas, and Rich Salz for your reviews, comments, suggestions, and fixes 💖. You all are literally iconic 👑.

Authors' Addresses 🌈

Thomas Fossati Linaro Email: thomas.fossati@linaro.org

Esko Dijk IoTconsultancy.nl Email: esko.dijk@iotconsultancy.nl

📦 where this page comes from