rfc-9876

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

T. Fossati, E. Dijk
date2025-11 streamIETF areawit wgcore statusPROPOSED STANDARD pages12 canonicalhttps://www.rfc-editor.org/rfc/rfc9876 doi10.17487/RFC9876
This document updates RFC 7252 by modifying the registration procedures for the "CoAP Content-Formats" IANA registry, within the "Constrained RESTful Environments (CoRE) Parameters" registry group. This document also introduces a new column, "Media Type", to the registry. Furthermore, this document reserves Content-Format identifiers 64998 and 64999 for use in documentation.

updates

Extracted elements (25)

design-rationale §4.1

Because the 0-255 namespace is so small (single-byte identifiers), the IANA policy for that range is 'Expert Review' rather than First Come First Served, requiring expert evaluation of code point scarcity before any allocation.

registry

design-rationale §4.1

In M2M applications, generic media types like text/plain or application/xml are not useful long-term. It is recommended that M2M applications using CoAP request specific IANA media types that carry semantic information, such as application/se+cbor for a Smart Energy CBOR payload.

registry

design-rationale §4.1.1

In the 10000-64997 range, abandonment of a document requesting a Content-Format ID does not cause removal of the entry because the registration procedure for this range does not require completion of any standards process or a registering document.

registry

design-rationale §4.1.3

Provisional media types are permitted only for Content-Format identifiers in the 0-255 and 256-9999 ranges because those ranges involve heavier standards review processes (Expert Review and IETF Review/IESG Approval) that can track the provisional status through to permanence.

registry

design-rationale §4.1.2

The new 'Media Type' column was added to help users of the registry find detailed information about the Media Type associated with each CoAP Content-Format and to ensure that a Media Type exists before a new entry can be registered.

registry

design-rationale §1

The update was motivated by the absence of any requirement to check that a requested Content-Type and Content Coding combination is semantically valid. This task is non-trivial, requires multi-document knowledge, and should not be solely demanded from the registrar — the gap had already led to erroneous registrations.

registry

interoperability-note §1

The columns of the CoAP Content-Formats registry have been previously revised per Erratum 4954 on RFC 7252. This document's replacement of Section 12.3 of RFC 7252 accounts for that errata revision.

registry

normative-requirement §4.1 MUST

A registration request for the FCFS range (20000-32999) 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.

registry

normative-requirement §4.1 MUST NOT

Content-Format identifiers between 65000 and 65535 inclusive are reserved for experiments and MUST NOT be used in operational deployments.

registry

normative-requirement §4.1.3 MUST

For the 0-255 range, the designated expert must additionally evaluate the requested code point concerning the limited availability of the 1-byte code point space. A similar criterion may apply for 256-9999, 10000-19999, and 33000-64997 ranges where parameter and coding combinations consume considerable code point space.

registry

normative-requirement §4.1 MUST

For the 256-9999 range, all assignments under 'IETF Review with Expert Review' require both IETF Review per BCP26 Section 4.8 and Expert Review per BCP26 Section 4.5; the early IANA allocation procedure of RFC 7120 also applies, and IANA must ask designated experts to approve early allocations before registration.

registry

normative-requirement §4.1.2 MUST

If a provisional Media Type becomes permanent, IANA must update the 'Media Type' field in all associated registry entries so the hyperlink directs to the registration information in the permanent 'Media Types' registry.

registry

normative-requirement §4.1.1 MUST

If a temporary registration fails to complete its required registration procedure, or if the provisional Media Type it references is abandoned, IANA must remove the entry and set the Content-Format ID back to 'Unassigned'.

registry

normative-requirement §4.1.1 MUST

Once a temporary registration's required procedure is successfully completed and the Media Type is in the permanent 'Media Types' registry, IANA must remove any indication of temporary status so the entry becomes permanent.

registry

normative-requirement §4.1.1 OPTIONAL

Temporary registrations within the 0-255 range are exempt from the formal renewal process in RFC 7120; IANA will not monitor their removal and instead designated experts direct IANA to carry out that task.

registry

normative-requirement §4.1.3 MUST

The Expert Review checklist requires: (1) no duplicate Content-Type+Content Coding combination, (2) the Media Type must be registered or approved in the 'Media Types' registry or listed provisionally (provisional only allowed for 0-9999 ranges), (3) parameter names must be defined for the Media Type with valid values, (4) Content Type must be in preferred format per Section 4.1.4, and (5) any Content Coding must exist or be approved in the 'HTTP Content Coding Registry'.

registry

protocol-element §4.1.1

A temporary Content-Format registration may be created by IANA early allocation (RFC 7120) or when the referenced Media Type is provisional (listed in the Provisional Standard Media Type Registry). Temporary registrations are marked as such by IANA in the registry entry.

registry

protocol-element §4.1

CoAP lacks a separate mechanism to convey Content Coding information; therefore, Content Coding is specified per Content-Format identifier. If multiple Content Codings are used with a Media Type, a separate Content-Format identifier must be registered for each.

registry

protocol-element §4.3

Content-Format identifiers 64998 and 64999 are reserved for use in documentation examples. These identifiers are used throughout Section 4.1.5 to illustrate invalid registration attempts.

registry

protocol-element §4.1

Each entry in the CoAP Content-Formats registry must include: the Content Type, the Content Coding (if any), the Media Type registered with IANA, a numeric identifier in the range 0-65535, and a reference to a document describing the semantic meaning of a payload with that Media Type.

registry

protocol-element §4.1.5

Five categories of invalid FCFS registration requests are identified: (1) unknown Media Type, (2) unknown parameter on a known Media Type, (3) invalid parameter value, (4) unknown Content Coding, and (5) duplicate logical entries via default parameter values, default Content Coding, or semantically equivalent parameter values such as case-insensitive URNs.

registry

protocol-element §4.1.4

The preferred format for the Content Type field follows RFC 9110 Section 8.3.1: (1) case-insensitive elements use lowercase, (2) parameter values are quoted only if required by RFC 9110 Section 5.6.6, and (3) a single semicolon without adjacent whitespace separates the Media Type from parameters.

registry

registry §4.1.2

A new 'Media Type' column has been added to the CoAP Content-Formats registry, placed to the right of the 'Content Type' column. It lists the base Media Type name with a hyperlink to its IANA registration (or to the Provisional Standard Media Type Registry if provisional).

registry

registry §4.1

The 'CoAP Content-Formats' registry within the 'Constrained RESTful Environments (CoRE) Parameters' registry group is updated with new range-based registration procedures: 0-255 (Expert Review), 256-9999 (IETF Review with Expert Review or IESG Approval with Expert Review), 10000-19999 (Expert Review), 20000-32999 (First Come First Served with conditions), 33000-64997 (Expert Review), 64998-64999 (Reserved for Documentation), and 65000-65535 (Experimental Use).

registry

security-consideration §3

This document updates CoAP Content-Format registration procedures to reduce the chances of malicious manipulation of the registry. The introduction of Expert Review for most ranges and a detailed checklist prevents erroneous or deliberately invalid registrations. Otherwise, the security considerations of RFC 7252 remain unchanged.

security, registry