Summary

  • A CoAP Content-Format identifier stands for a particular Content Type and optional Content Coding; the number is not meaningful without that semantic registration.
  • RFC 9876 narrows the First Come First Served path and puts most identifier ranges behind a defined expert checklist.
  • Temporary registrations now have an explicit lifecycle, while identifiers 64998 and 64999 are reserved for documentation and 65000-65535 remain experimental rather than operational.
  • The control objective is to stop invalid parameters, unknown codings and logically duplicate entries from becoming compact but misleading protocol facts.

In CoAP, a Content-Format identifier stands for the combination of a media type and, when present, a content coding. The registry therefore carries the information needed to interpret that integer. If the registered combination is invalid, duplicated or ambiguous, the identifier no longer points to a single dependable protocol meaning.

RFC 9876 updates the registration procedures created by RFC 7252. The motivation is not a shortage of forms. The earlier rules did not explicitly require a semantic check of the requested Content-Type and Content Coding combination, even though that check can require knowledge spread across media-type, parameter and HTTP coding registries. A registrar can verify that fields are present; deciding whether they describe a valid and distinct payload is a different task. The new procedure makes that distinction operational.

The allocation table now expresses scarcity and review cost more carefully. The one-byte range, 0-255, requires Expert Review. Identifiers 256-9999 require IETF Review or IESG Approval together with Expert Review. The ranges 10000-19999 and 33000-64997 also require Expert Review. Only 20000-32999 retains a First Come First Served path, and even there the request must be unusually simple: a registered or approved Media Type, no parameters, no Content Coding, and no prior use of that Media Type in the CoAP registry.

A request that falls outside those boundaries moves to an expert-reviewed range rather than stretching FCFS into a substitute for judgement.

The expert checklist is deliberately semantic. It asks whether the Content-Type and Content Coding pair already exists, whether the Media Type is registered or eligible, whether its parameter names and values are permitted, whether the string uses the preferred format, and whether any Content Coding exists in the HTTP registry. These tests catch more than typographical errors. Two different strings can denote the same logical entry when one merely states a default parameter or the identity coding. Conversely, a plausible-looking string can name a media type, parameter or coding that has no registration behind it.

RFC 9876 also gives provisional work a cleaner lifecycle. Temporary registrations can exist within 0-64997, including early allocations and entries tied to provisional media types. Qualifying temporary status is removed once the required procedure completes and the media type becomes permanent. If the necessary process fails or an eligible provisional media type is abandoned, IANA can remove the entry and return the identifier to Unassigned. The RFC preserves an important exception for parts of the higher range whose registration does not depend on completing a standards process.

The remaining boundaries are explicit. The registry gains a Media Type column linking the compact entry to its base registration. Identifiers 64998 and 64999 are documentation examples, not operational allocations. The 65000-65535 range is experimental and must not be used in operational deployments. Together these rules separate durable protocol meaning, temporary coordination, examples and experiments instead of allowing one numeric namespace to blur them.

Sources