Zusammenfassung

  • RFC 9694 verlangt Standards Action, klare Zugehörigkeitsgrenzen, gemeinsame Sicherheitsanalyse und mindestens einen realen Subtyp.
  • Der Name links vom Schrägstrich kann type/*-Dispatch, Symbol und Anwendung beeinflussen; ein Registereintrag erzeugt daher Implementierungsarbeit.
  • Definition, Registerstatus, Subtyp, Emission, Weitergabe, exaktes Parsing, Fallback, Validierung, lokale Freigabe und Ergebnis sind getrennte Nachweise.

Das richtige Symbol kommt vor dem richtigen Verständnis

Ein Dateimanager kennt haptics/hjif nicht, aber haptics/*. Er kann ein Tastmedien-Symbol anzeigen oder eine allgemeine Anwendung anbieten. Der exakte Subtyp ist noch unverstanden, die Bytes sind ungeprüft und kein Gerät darf einen physischen Effekt auslösen. Dennoch hat der Top-Level-Name Dispatch und Erwartung bereits verändert.

Darum behandelt RFC 9694, im März 2025 als BCP 13 veröffentlicht, einen neuen Namen links vom Schrägstrich als Ausnahme. Er aktualisiert RFC 6838. Die meisten Formate gehören unter bestehende Typen; application bleibt für diskrete Daten ohne passendere Familie. Eine neue Kategorie verlangt von Produzenten, Vermittlern, Betriebssystemen, Bibliotheken und User Agents, eine neue Familiengrenze zu erkennen.

Nötig sind ein Standards-Track-RFC, eine IANA-Anweisung, klare Ein- und Ausschlusskriterien, Sicherheitsfragen für alle oder viele künftige Subtypen und mindestens ein Subtyp. Eine leere Kategorie hat keinen Betriebszweck.

Das IANA-Register der Top-Level-Medientypen nutzt Standards Action. Neben den MIME-Familien aus RFC 2046 stehen model, example, font und haptics. Diese Tabelle belegt Name und definierenden RFC, nicht korrekte Emission, unveränderte Weitergabe oder sichere Verarbeitung in einem Produkt.

Eine Grenze muss reale Formate tragen

Eine Oberkategorie ist sinnvoll, wenn sie über mehrere Subtypen etwas Dauerhaftes vorhersagt. Klare Regeln ermöglichen die Zuordnung und Prüfung einer Registrierung. Lässt sich die Grenze nicht erklären, ist die Unschärfe ein Zeichen gegen den Top-Level-Status.

RFC 9694 schließt Abkürzungen aus: kein Spiegel eines anderen Registers, keine Rückabbildung von Dateiendungen oder URI-Schemata und kein Ersatz für Programmiersprachen- oder Ontologie-Typsysteme. Alias-Namen für etablierte Formate sind zu vermeiden; X- macht lokale Praxis nicht offiziell. So bleibt der gemeinsame Namespace frei von produktspezifischen Bedeutungen.

Breite inoffizielle Nutzung kann Bedarf zeigen, ersetzt aber nicht das Verfahren. Ebenso wenig beweist eine abstrakte Kategorie ohne echte Formate ihren Bedarf. Initiale Subtypen sollen die Grenze praktisch prüfen.

haptics war der Parallelfall. RFC 9695 definiert die Familie, das IANA-Medientypregister führt haptics/ivs, haptics/hjif und haptics/hmpg. Das sind Standardisierungs- und Registerfakten, keine Aussage über Browser, Mailclients, Gateways oder Geräte. Auch RFC 9993 macht aus haptics/hmpg kein universelles Deployment.

Generischer Dispatch vergrößert auch Fehler

Medientypen weisen Formate Anwendungscode zu. Normalerweise entscheiden voller Typ, Subtyp und Parameter. Der Top-Level-Name kann vorläufig zu einer breit zuständigen Anwendung führen. Bild, Audio und Video nutzen das; HTML-Elemente und Symbole können ebenfalls davon abhängen.

Eine gestartete Anwendung belegt nur einen Kandidaten. Ein passendes Symbol belegt eine Darstellungsregel. Beides sagt nichts über Subtyp-Unterstützung, Parameter, Byte-Inhalt, Isolation aktiver Daten oder Nutzerabsicht. Die Deklaration kann außerdem unter Kontrolle eines Angreifers stehen.

Eine sichere Kette erhält Typ und Parameter, prüft die Subtypdefinition, wendet Protokollgrenzen und Inhaltsvalidierung an, entscheidet über Fallback, hält Rendering oder Ausführung hinter lokaler Policy und erfasst das Ergebnis. Sniffing kann Widersprüche finden; stilles Ersetzen der Deklaration durch Vermutung schafft jedoch eine neue Autoritätslücke.

Ein belastbares Deployment trennt zehn Belege: Standards Track, IANA-Obertyp, Subtyp, Emission, Weitergabe, exakte Erkennung, Fallback, Validierung, lokale Freigabe, beobachtetes Ergebnis. Jede Stufe kann erfolgreich sein, während die nächste scheitert. Auch Kosten verteilen sich: Migration beim Produzenten, Normalisierung im Vermittler, Handlerpflege, neue Sicherheitsfläche und Support, wenn das Symbol stimmt, aber der Inhalt nicht.

RFC 8126 beschreibt Standards Action. IETF Datatracker und RFC-Editor-Info belegen Status und Geschichte, nicht Nutzung. Dafür braucht es Konfigurationen, Traces, Vermittlertests, Handlerinventare, Prüfergebnisse und beobachtetes Verhalten.

Lu Hengs Text zur minimalen Anfangsspezifikation dient nur als offengelegte redaktionelle Linse: Gemeinsam soll nur sein, was Interoperabilität braucht; spätere Entscheidungen bleiben nahe am Betreiber. Das ist weder IETF-Vorgabe noch Deployment-Beleg.

Quellen