Zusammenfassung

  • RFC 9695 schafft mit haptics/* eine gemeinsame Route zu einem physischen Wiedergabesystem; die Gerätebeschreibung und lokale Anpassung entscheiden jedoch erst, welche Effekte tatsächlich befehligt werden.
  • Ein belastbarer Nachweis verbindet den Quellhash mit Erkennung, ignorierten Werten, Geräteabbildung, Zustimmung, Begrenzung, Aktuatorbefehlen und bestätigtem Neutralzustand.

Die Referenzgerätebeschreibung löst ein echtes Problem: Ein Werk soll nicht für jedes Armband, jeden Controller oder jede kinästhetische Vorrichtung neu kodiert werden. Sie verlagert die entscheidende Arbeit aber an den Empfänger. RFC 9695 registriert haptics als Top-Level-Medientyp und zunächst die Untertypen IVS, HJIF und HMPG. Der Typ bezeichnet die Medienfamilie und den Bedarf an einem Haptiksubsystem samt Hardware; der Untertyp bezeichnet das genaue Format.

Damit kann Infrastruktur Inhalte zum richtigen System leiten. Die Registrierung kennt jedoch weder Anzahl und Lage der realen Aktuatoren noch deren Kraft-, Temperatur- oder Frequenzbereich. Nach der Zustellung muss lokale Software aus einer Beschreibung eine physische Möglichkeit machen. Dieser Schritt braucht eine eigene Provenienz.

Die Anpassung ist eine Entscheidungskette

IVS ist ein XML-basiertes, geräteunabhängiges Austauschformat. RFC 9695 stellt zugleich klar, dass nicht jedes Gerät jeden darstellbaren Effekt wiedergeben kann. Geräteunabhängigkeit bedeutet Portabilität der Beschreibung, nicht Gleichheit der Ausstattung.

HJIF auf JSON-Basis und das binäre HMPG können zeitliche und räumliche Haptik sowie Körperorte beschreiben. Beide können Angaben zu einem Referenzgerät tragen, damit Renderingsoftware den Inhalt an die tatsächliche Hardware anpasst. In dieser Anpassung werden Effekte zusammengelegt, verschoben, skaliert, gekappt oder ausgelassen.

Ein Referenzgerät mit acht räumlich verteilten Aktuatoren kann eine wandernde Welle erzeugen. Ein Endgerät mit zwei Aktuatoren muss daraus zwei Impulse, eine globale Vibration oder keinen Effekt machen. Fehlt ein thermischer Kanal, verschwindet die Temperaturkomponente. Ist die Kraftgrenze niedriger, wird die Amplitude reduziert. Zwei Empfänger können dasselbe Objekt korrekt akzeptieren und physisch Verschiedenes ausgeben.

Deshalb braucht die Abbildung einen maschinenlesbaren Effektvergleich. Die erste Menge enthält die angeforderten Effekte. Die zweite enthält, was der Parser verstand. Die dritte enthält, was das reale Gerät nach Anpassung leisten kann. Die vierte enthält, was nach Nutzerentscheidung, Betriebssystempolitik und Sicherheitsbegrenzung tatsächlich an den Treiber ging. Jede Differenz braucht einen Grund.

Die offizielle Dokumentation zu Apple Core Haptics veranschaulicht diese lokale Ebene, ohne eine Unterstützung von RFC 9695 zu belegen. Sie unterscheidet transiente und kontinuierliche Ereignisse, Parameter und Pattern Player. Anwendungen müssen Hardwarefähigkeiten prüfen; bei AHAP-Dateien können fehlende Parameter Standardwerte auslösen. Engine, Fähigkeit und Standardwert gehören deshalb in den Ergebnisnachweis.

Ein unbekannter Untertyp kann trotzdem weitergereicht werden

RFC 9695 empfiehlt, einen nicht erkannten Haptikuntertyp wie application/octet-stream zu behandeln. Das folgt dem konservativen Modell von RFC 2046: Unbekannte Bytes erhalten nicht allein wegen des bekannten Familientyps eine spezifische Bedeutung.

Gleichzeitig darf eine Implementierung den unbekannten Untertyp an das Haptiksubsystem und die zugehörige Hardware weiterreichen. Eine ältere Anwendung könnte ein Format nicht kennen, das ein Plug-in, ein Systemdienst oder ein neueres Gerät versteht. Diese Offenheit ermöglicht Evolution.

Für die Prüfung sind es dennoch zwei Entscheidungen. Die Medienebene protokolliert Registerstand, Erkennung und Fallback. Die Anwendungsebene protokolliert Speichern, Download, Decodersuche, Übergabe an den Haptikdienst und eine Sperre der Aktuation bis zur eindeutigen Erkennung. „Als octet-stream behandelt“ beweist keine physische Isolation; „an den Dienst übergeben“ beweist keine gültige Dekodierung.

RFC 6838 regelt die Registrierung von Medientypen, RFC 9694 die hohen Anforderungen an einen neuen Namen links vom Schrägstrich. Dort geht es um den gemeinsamen Namensraum. Hier geht es um die lokale Kette, nachdem der Namensraum richtig geroutet hat.

Teilweise Interpretation kann vollständig aussehen

Parameter dürfen kommaseparierte Unterwerte enthalten. Erkennt ein Prozessor den Parameter, aber nicht einen Unterwert, soll er den unbekannten Wert ignorieren und mit den bekannten fortfahren. Diese Regel hält ältere Implementierungen für neue Erweiterungen nutzbar.

Sie garantiert nicht, dass die Absicht erhalten bleibt. Der Sender kann mehrere Werte als gemeinsame Bedingung verstehen, der Empfänger als Auswahl. Bezeichnet der verworfene Wert eine Geräteklasse, Körperstelle, Modalität oder Grenze, bleibt die Syntax gültig, während der physische Sinn schrumpft.

Ein Parameterbeleg muss Rohwert, erkannte und ignorierte Unterwerte, Standardwerte und die daraus entstandene Decoderkonfiguration enthalten. Ebenso wichtig ist die Softwareversion. Ein Update kann einen vormals unbekannten Wert erkennen; ein entferntes Modul kann das Gegenteil bewirken. Derselbe Dateihash nimmt dann einen anderen Weg.

„Medieninhalt“ kontrolliert weder Parser noch Energie

Die Registrierungen bezeichnen die Formate als Medien, nicht als ausführbaren Code. Das hilft bei der Auswahl eines Behandlungsmodells, beseitigt aber keine XML-, JSON- oder Binärparser, Speicherverwaltung, Nutzerdienste, Treiber und kernelnahe Pfade. Bösartige Beschreibungsdaten können Schwächen solcher Implementierungen angreifen.

Davon getrennt ist die physische Sicherheit. Haptik kann Vibration, kinästhetische Kraft, Temperatur und Textur erzeugen. RFC 9695 warnt, dass unkontrollierte thermische oder kinästhetische Geräte Verletzungen verursachen können. Eine Dateigrößengrenze ersetzt keine Grenzen für Amplitude, Kraft, Temperatur, Dauer, Änderungsrate und Wiederholung.

Es braucht zwei Sicherheitsnachweise. Der Softwarenachweis behandelt Strukturprüfung, Ressourcen, Isolation, Decoder und Treiber. Der physische Nachweis behandelt Zustimmung, tatsächliche Fähigkeiten, lokale Grenzwerte, Abschaltung, Neutralstellung und kumulierte Exposition. Eine erfolgreiche Medienprüfung unterschreibt nicht für die körperliche Ausgabe.

Die W3C Vibration API zeigt eine weitere lokale Zulassung: Der User Agent kann Vibration anhand der Dokumentsichtbarkeit und Permissions Policy beschränken. Diese API ist nicht mit IVS, HJIF oder HMPG gleichzusetzen. Sie zeigt, dass eine syntaktisch gültige Anforderung kontextbedingt abgelehnt werden kann und dieser Grund getrennt von Parserfehlern oder fehlender Hardware erfasst werden muss.

Der Neutralzustand gehört zum Abschluss

Die Evidenzkette beginnt mit Objekt-Hash, Medientyp, Untertyp und Parametern. Sie bindet diese an den Stand des IANA-Medientypregisters, das Erkennungsergebnis, Fallback und Parser. Es folgt der Vergleich von Referenzgerät und realem Fähigkeitsprofil sowie der Effektdifferenz.

Danach werden Entscheidungen von Anwendung, Betriebssystem, Nutzer und Sicherheitslogik getrennt erfasst. Aktuatorbefehle müssen die aktiven Grenzwerte nennen. Ein Vorgang endet nicht mit „Wiedergabe abgeschlossen“, sondern mit bestätigtem Stopp und neutraler Position, Temperatur oder Ausgangsleistung.

Auch ein Befehlsprotokoll ist noch keine physische Messung. Eine Messung ist wiederum kein Beleg für die menschliche Empfindung. Wer Weg, Kraft, Temperatur oder Erleben behauptet, muss Sensor und Verfahren nennen. Keine Schicht darf die Gewissheit der nächsten vorwegnehmen.

RFC 9993 aktualisiert haptics/hmpg und definiert RTP-Payload, Fragmentierung, Aggregation und SDP-Parameter für MPEG-I-Haptik. Die korrekte Rekonstruktion einer Medieneinheit ist Transportevidenz. Die lokale Anpassung und Aktuation bleiben ein anderer Nachweis.

Lu Hengs Lehre der minimalen Anfangsspezifikation passt zu dieser Trennung. Gemeinsam festgelegt werden Familie, Untertypen, Parametersyntax und grundlegendes Fallback. Fähigkeiten, Einwilligung, Grenzen und künftige Entscheidungen bleiben lokal, müssen aber sichtbar sein. Die Disziplin der Realitätsebenen trennt Register, Header, Parse, Anpassung, Befehl, Messung und Empfindung. Primat des laufenden Codes bedeutet, dass der Beleg dieses Endpunkts stärker wiegt als eine Ableitung aus dem, was der Standard zulässt.

Quellen