Summary

  • RFC 9694 makes a new top-level media type a Standards Action: the category needs clear membership boundaries, common security analysis and at least one real subtype.
  • The name left of the slash can influence generic type/* dispatch, default icons and application choice, so registration creates ecosystem work beyond adding a row to IANA.
  • Leadership needs separate evidence for definition, registry state, subtype registration, producer emission, intermediary preservation, exact parsing, fallback policy, validation, authorization and observed outcome.

One registry row, many obligations

Imagine a file manager that does not recognize haptics/hjif but does recognize haptics/*. It may choose a broad haptics handler, display a tactile-media icon or offer an application associated with the category. The full subtype still has not been understood. No payload has been validated. No device has been authorized to create an effect. Yet the top-level name has already changed dispatch and presentation.

That is why RFC 9694 treats a new name to the left of the slash as exceptional. Published in March 2025 as Best Current Practice 13, it updates RFC 6838, the broader media-type registration procedure. Most new formats belong under an existing type. application remains available for discrete data that fits nowhere more specific. A new top-level category is not a decorative taxonomy choice; it asks producers, intermediaries, operating systems, libraries, gateways and user agents to recognize a new family boundary.

RFC 9694 therefore demands more than a plausible noun. The type must be defined in a Standards Track RFC. Its IANA Considerations must request addition to the top-level registry. The definition must say clearly what belongs below the category and what does not. It must document security issues shared by all or a significant subset of future subtypes. At least one subtype must exist, because an empty category has no operational purpose.

The live IANA Top-Level Media Types registry makes that scarcity visible. Its registration policy is Standards Action. Alongside the seven early MIME families described by RFC 2046, it lists later additions such as model, example, font and haptics. The table is authoritative evidence that a top-level name and defining RFC exist. It is not evidence that a particular producer emits the right value or that a particular consumer handles it correctly.

The boundary must earn its place

A top-level category is useful only when it predicts something durable across multiple subtypes. Clear membership criteria help reviewers decide whether a proposed subtype belongs and whether its registration supplies the right information. If the boundary cannot be explained, RFC 9694 treats that ambiguity as evidence that the subject is not suitable for a top-level type.

The document also rejects several shortcuts. A top-level type cannot merely mirror another registry, map file extensions or URI schemes, or turn a programming-language or ontology type system into media types. It should not manufacture aliases for established formats, and an X- prefix cannot turn a private experiment into a registrable category. These limits protect the shared namespace from becoming a collection of convenience labels whose semantics depend on one product or local environment.

Existing unofficial use may demonstrate demand, but it does not excuse the standards path. Conversely, a Standards Track document without actual subtype pressure would describe a category before proving there is anything to categorize. RFC 9694 recommends including initial subtype registrations so reviewers can test the boundary against real formats.

The parallel haptics work shows the method. RFC 9695 defines the top-level family, while the live IANA Media Types registry lists haptics/ivs, haptics/hjif and haptics/hmpg. That proves standards and registry facts. It does not establish that a mail client, browser, collaboration service, content gateway or physical device recognizes any of them. It does not turn the RFC 9993 RTP treatment of haptics/hmpg into universal deployment.

Generic dispatch is useful—and dangerous

RFC 9694 says the main job of media types is to dispatch data formats to application code. Usually the full type, subtype and sometimes parameters select the handler. The top-level type can provide a tentative fallback for applications that cover a broad family. Image, audio and video software already uses this pattern. Web generators may choose different elements; desktop software may choose different icons.

The convenience creates an evidence trap. A recognizable icon proves only that some presentation rule fired. A launched application proves only that dispatch found a candidate. Neither proves that the exact subtype was supported, that parameters were honored, that the bytes match the declaration, that active content was contained, or that the user intended the resulting action. RFC 9694 explicitly warns that the declared media type may be controlled by an attacker.

The safe sequence is therefore conditional. Preserve the declared full type and parameters. Check whether the subtype has a registered definition. Apply protocol-specific restrictions and content validation. Decide whether generic fallback is allowed for this context. Keep rendering, execution and physical output behind local policy. Record what the user or downstream system actually observed. Sniffing may discover a mismatch, but silently replacing one authority claim with another can create its own ambiguity.

A deployment needs ten receipts

A defensible rollout should distinguish ten states: a Standards Track definition; an IANA top-level entry; a registered subtype; producer emission; intermediary preservation; exact parser recognition; generic fallback selection; content validation; local authorization to render or execute; and observed outcome. Each state can be true while the next is false.

This hierarchy matters commercially. Producers bear migration and testing costs. Intermediaries may normalize or strip values. Consumer vendors decide whether a new family deserves a generic handler. Security teams inherit a new classification edge. Support teams inherit cases in which the icon looked right but the content failed. A standards success can coexist with a deployment failure because the institutions that define the name do not operate every implementation that consumes it.

RFC 8126 explains the Standards Action policy used for high-scrutiny registry changes. The IETF Datatracker record and RFC Editor information page establish the document’s status and history. None is a usage census. Deployment evidence must come from producers, protocol traces, intermediary tests, handler inventories, validation results and observed behavior.

Lu Heng’s minimum-initial-specification argument is useful here only as a disclosed editorial lens: standardize the smallest common layer that interoperability truly requires, then leave later choices close to operators and implementations. It is not an IETF requirement. Applied to RFC 9694, the lens helps separate a justified shared category from the many local decisions that registration cannot make.

Sources