Summary

  • RFC 9876 repairs a real registration-process gap by checking the semantic combination of Media Type, parameters and optional Content Coding, while assigning different review policies to scarce, general, documentation and experimental ranges.
  • Approval creates a stable registry mapping. It does not test deployed payload bytes, parser behavior, negotiation, downgrade handling, security limits or producer-consumer agreement.
  • A defensible system keeps an allocation receipt and a deployment receipt joined but distinct, so a registry row is never made to carry claims outside the authority that created it.

A sensor sends the integer 293. The receiver looks it up and finds a CoAP Content-Format. The exchange is efficient precisely because the wire does not repeat a long Media Type, its parameters and any Content Coding. A compact number stands in for that tuple.

That economy invites an attractive but false inference. If IANA assigned the number, the format must be interoperable. If a designated expert approved it, the payload must be safe to process. If two vendors use the same identifier, their implementations must mean the same thing.

RFC 9876 supports none of those conclusions. Its achievement is narrower and essential: it improves the public coordination record from which implementations begin.

Why one number needs several registries

CoAP was built for constrained nodes and networks where bytes, energy and fragmentation matter. RFC 7252 therefore gives a numeric Content-Format identifier to a representation. RFC 9876 clarifies what the registry row must bind: the Content Type, an optional Content Coding, the base Media Type, the numeric identifier and a reference that explains the payload semantics.

These are not interchangeable labels. A Media Type names a format family. Parameters can select a profile or other meaning inside that family. A Content Coding transforms the representation. CoAP does not carry the coding in a separate field, so application/example and the same type under a registered coding need different Content-Format identifiers.

The old procedure did not explicitly require somebody to validate whether that combination was semantically legitimate. A request could look syntactically plausible while naming an unknown Media Type, inventing a parameter, using a forbidden parameter value, citing an unregistered coding or duplicating an existing meaning under a different spelling. RFC 9876 says that this cross-document judgment should not be left solely to the registrar. Most ranges now bring in designated experts with an explicit checklist.

This is registry governance at its best: the institution notices that clerical validity and semantic validity are different jobs, and it assigns the second job to reviewers equipped to perform it.

The ranges are policy, not decoration

The identifier space runs from 0 to 65535, but it is not one undifferentiated pool. The first 256 values can fit in one byte and are scarce. They now require Expert Review, with an instruction to consider whether a request deserves that compact space. Values 256–9999 require IETF Review plus Expert Review, or IESG Approval plus Expert Review. Values 10000–19999 and 33000–64997 also require Expert Review.

The 20000–32999 range keeps a narrow First Come First Served path. It works only when the request has no parameters, no Content Coding, uses a registered or approved Media Type not already present in the CoAP registry and otherwise fits the rule. Convenience is bounded rather than abolished.

Two values, 64998 and 64999, are reserved for documentation. The 65000–65535 range is for experiments and RFC 9876 repeats that it is not for operational deployment. Those boundaries prevent examples and experiments from quietly acquiring production authority.

A low number is not a property right or a quality badge. It is a scarce coordination resource whose allocation costs must be visible. A high number is not inherently inferior. The range tells an operator which decision process governed the row; it does not rank the software that uses it.

The expert checklist closes several false doors

The review begins by checking that the requested Content-Type and Content Coding combination is not already present. It then verifies that the base Media Type is registered, approved, or—within permitted ranges—listed provisionally. Optional parameter names and values must be defined for that Media Type. A named Content Coding must exist or have been approved in the HTTP Content Coding registry. The Content Type is normalized into a preferred textual form.

Normalization matters because registries must distinguish presentation from meaning. Lowercasing case-insensitive elements, removing unnecessary quotes and using a consistent semicolon do not create a new protocol. They reduce accidental difference. RFC 9876’s examples go further: an explicit default can duplicate an omitted default; identity coding can duplicate no coding; two differently cased URNs can be semantically identical when the relevant component is case-insensitive.

The checklist is strong because it asks reviewers to follow meaning across registry boundaries. It is still not a laboratory. The expert does not run every encoder, feed malicious payloads to every parser or certify memory limits on a constrained device. Registration answers, “Is this tuple fit to enter the shared namespace under this policy?” Interoperability asks, “Do these particular implementations exchange and process it correctly under defined conditions?”

Collapsing those questions does harm in both directions. It burdens IANA and experts with a product-assurance role they do not have, while allowing vendors to substitute an allocation for evidence they alone can produce.

Temporary is a lifecycle state

RFC 9876 also makes temporary registration legible. A provisional Media Type can support early work, and its linked Content-Format remains temporary. When the required process succeeds and the Media Type becomes permanent, IANA can remove the temporary marker. If the required process fails or the provisional type is abandoned, the entry can be removed and the number returned to Unassigned.

The current IANA registry makes this visible. At the time of this review it includes temporary entries such as IDs 293 and 294 linked to provisional Media Types, alongside permanent rows, unassigned ranges, documentation reservations and experimental space. That snapshot is evidence of state, not of adoption. It neither condemns the temporary formats nor proves that any particular device supports them.

Temporary must therefore travel with a clock and an owner. An implementation that ships a temporary identifier needs to know which draft and media-type record it follows, when the allocation expires or changes, how a permanent transition will be handled and what happens if the number returns to the pool. Persisting only the integer destroys the history needed to interpret it later.

There is a subtle exception worth retaining. In ranges that do not require completion of a standards process or a registering document, abandonment of a document does not automatically remove the entry. Lifecycle follows the actual range policy, not a generic belief that every draft expiry revokes every number.

Two receipts prevent authority laundering

The allocation receipt should preserve the exact normalized Content Type, base Media Type registration, parameters, Content Coding, requested and assigned range, review policy, expert or standards decision, semantic reference, temporary or permanent state, allocation date, expiry or review condition, and the reason a scarce code point was justified. It should also record rejected equivalents so that a later spelling change does not recreate a duplicate meaning.

The deployment receipt answers a different set of questions. Which encoder and decoder versions were tested? Which parameter combinations were exercised? Were bytes inspected before and after Content Coding? How did negotiation select the format? What happened on an unknown, expired or reassigned identifier? Were size, recursion and resource limits tested on constrained hardware? Did gateways preserve the tuple when translating between CoAP and HTTP? Which test vectors, failures and rollback decisions support the release?

The two receipts join on the identifier and exact tuple. They must not merge. The first is public coordination provenance. The second is implementation and operational evidence. A procurement system may require both; an incident responder may discover that the allocation remains valid while a particular decoder is wrong.

This two-receipt model is an editorial and operational recommendation. It is not a field in RFC 9876, an IANA requirement or a claim about a known deployment.

The registry must remain a truthful mirror

Lu Heng’s Minimum Initial Specification provides the right institutional scale. The shared layer should be just large enough to make independent action possible: a stable identifier, an exact tuple, a semantic reference and an auditable allocation process. It need not centralize every product release, parser or bilateral test.

The Policy Mirror supplies the limit. A registry row can truthfully reflect that an allocation decision was made under a stated policy. It cannot reflect that every device implements the decision, that deployment is safe, that adoption is broad or that two endpoints will interoperate. Those claims belong to other authorities and other evidence.

RFC 9876 improves the mirror by making the row harder to populate with nonsense or accidental duplicates. The next responsibility belongs to implementers and operators: preserve the difference between a number that was properly allocated and a system that was actually proved to work.

Sources