Résumé

  • RFC 9695 crée une famille de médias destinée à un sous-système physique, mais le rabattement d’un sous-type inconnu et sa transmission éventuelle au moteur haptique sont deux décisions différentes.
  • La preuve utile doit relier l’objet d’origine à chaque valeur ignorée, chaque adaptation de dispositif, chaque limite de sécurité, les commandes d’actionneur et le retour confirmé à l’état neutre.

Le cas difficile n’est pas celui d’un fichier manifestement corrompu. C’est celui d’un objet assez bien classé pour atteindre la bonne famille, mais pas assez bien compris pour garantir ce qu’il deviendra. RFC 9695 inscrit haptics au premier niveau des types de médias, à côté de familles telles que l’audio et la vidéo. Le type indique qu’un contenu requiert un sous-système haptique et du matériel associé ; le sous-type identifie le format précis.

Cette division organise le trafic. Elle ne certifie ni le décodeur, ni les capacités du dispositif, ni la conservation des effets. Un en-tête correct peut amener un objet au bon guichet tout en laissant ouvertes toutes les questions décisives : le guichet connaît-il IVS, HJIF ou HMPG ? Quels paramètres retiendra-t-il ? Que fera-t-il d’une modalité absente ? Quelle énergie commandera-t-il au matériel ?

Le rabattement ne ferme pas nécessairement la porte physique

Pour un sous-type non reconnu, le RFC recommande le traitement générique application/octet-stream. La règle héritée de RFC 2046 évite qu’un nom de famille suffise à inventer un interpréteur. L’objet devient, au niveau MIME, une suite d’octets sans sémantique locale connue.

Mais RFC 9695 autorise aussi une implémentation à transmettre un sous-type haptique inconnu au sous-système haptique et au matériel associé. Cette possibilité protège l’extensibilité : une couche amont peut ignorer un format qu’un module spécialisé ou un équipement plus récent sait interpréter. Elle crée également une bifurcation d’audit. Le statut générique d’un objet ne prouve pas qu’il est resté loin des actionneurs.

Il faut donc consigner deux résultats. Le premier appartient à la reconnaissance de média : type, sous-type, version du registre, branche de rabattement. Le second appartient à la politique d’application : stockage, téléchargement, recherche de greffon, remise au service haptique, interdiction d’actionner avant identification. Les résumer par « format non pris en charge » efface la décision qui compte physiquement.

RFC 6838 encadre l’enregistrement des types ; RFC 9694 explique la rareté et les obligations d’un nouveau nom à gauche de la barre oblique. Leur sujet est l’espace de noms partagé. Ici, le sujet commence quand cet espace de noms a correctement routé l’objet et que la politique locale reprend le pouvoir.

Continuer après avoir oublié une valeur

Les paramètres extensibles ajoutent une seconde ambiguïté. RFC 9695 prévoit qu’un paramètre puisse contenir plusieurs sous-valeurs séparées par des virgules. Un processeur qui ne connaît pas l’une d’elles doit l’ignorer et poursuivre avec celles qu’il reconnaît.

Ce choix évite qu’une extension future bloque tous les anciens récepteurs. Il ne préserve pas automatiquement l’intention. Si la valeur inconnue nomme une capacité, une zone corporelle, une modalité ou une contrainte de dispositif, sa disparition peut transformer l’expérience tout en laissant l’appel réussir. La compatibilité syntaxique devient alors une dégradation sémantique.

Un accusé de traitement doit exposer cette contraction. Il relie la valeur brute aux éléments reconnus, ignorés et remplacés par défaut. Il nomme la configuration de décodage qui en résulte. Il ne dit pas seulement « paramètres valides », car cette formule confond l’acceptation complète avec l’acceptation d’un sous-ensemble.

La distinction vaut aussi dans le temps. Une mise à jour peut commencer à reconnaître une sous-valeur, ou cesser de la reconnaître après le retrait d’un module. Le même fichier, sur le même appareil physique, ne produit plus le même chemin. Sans version du logiciel, table des valeurs et trace de décision, l’écart devient inexplicable.

L’indépendance du dispositif n’est pas l’équivalence des dispositifs

IVS est présenté comme un format XML indépendant du dispositif. Le RFC précise pourtant que tous les appareils ne peuvent pas rendre tous les effets. L’indépendance signifie que la description n’est pas attachée à un modèle unique ; elle ne fournit pas les actionneurs manquants.

HJIF, fondé sur JSON, et HMPG, binaire, peuvent décrire des effets dans le temps et l’espace, les associer à des parties du corps et inclure un dispositif de référence. Le logiciel de rendu peut alors adapter l’effet au matériel réel. Cette adaptation est une opération éditoriale sur le signal : elle choisit ce qui sera fusionné, déplacé, réduit, omis ou borné.

Supposons que le dispositif de référence dispose de huit actionneurs répartis sur une surface, tandis que le récepteur n’en possède que deux. Une vague spatiale peut devenir deux impulsions, une vibration unique ou aucun effet. Si une modalité thermique manque, le rendu peut l’écarter. Si l’enveloppe de force est plus faible, le moteur peut écrêter l’amplitude. Dans chaque cas, le format peut être correctement analysé alors que le résultat physique diffère.

La documentation officielle Core Haptics d’Apple illustre ce niveau local : événements transitoires et continus, paramètres, lecteurs de motifs et moteur relié au serveur haptique. La préparation d’une application exige aussi de tester les capacités matérielles. Les fichiers AHAP montrent enfin que l’absence d’un paramètre peut déclencher une valeur par défaut. Ces exemples ne prouvent aucune compatibilité avec RFC 9695 ; ils montrent pourquoi le nom du matériel, du moteur et des valeurs par défaut appartient à la preuve.

« Média » ne veut pas dire « inoffensif »

Les enregistrements indiquent que les formats sont des médias, non du code exécutable. Cette catégorie guide le traitement, mais elle ne supprime pas l’exposition logicielle. Les structures XML et JSON doivent être analysées. Des composants en espace utilisateur ou dans des chemins noyau peuvent traiter les données descriptives. Un contenu hostile peut viser les défauts de ces composants sans devenir, par nature, un programme déclaré.

Le risque physique est distinct. La vibration, la force kinesthésique et la température sont des sorties énergétiques. RFC 9695 avertit qu’un contrôle insuffisant des dispositifs thermiques ou kinesthésiques peut blesser. Une limite de taille de fichier ne remplace donc pas une limite d’amplitude, de force, de température, de durée, de pente et de répétition.

Deux dossiers d’assurance doivent coexister. Le premier porte sur l’analyse : validation de structure, mémoire, isolement, codecs et pilotes. Le second porte sur l’actuation : profil de capacité, consentement, limites locales, arrêt d’urgence, état neutre et exposition cumulée. La réussite du premier ne valide pas le second.

L’API Vibration du W3C offre un exemple de décision contextuelle : l’agent utilisateur peut conditionner l’effet à la visibilité du document et à Permissions Policy. Il ne s’agit pas des formats de RFC 9695. L’enseignement est la séparation des couches : une demande valide peut être refusée par une politique locale, et ce refus doit rester visible au lieu d’être confondu avec une panne du décodeur.

Un reçu de rendu plutôt qu’un voyant vert

La chaîne probante commence par le hash de l’objet, son type, son sous-type et ses paramètres. Elle enregistre ensuite le registre consulté, le décodeur choisi, les valeurs ignorées, le résultat de l’analyse, le profil du dispositif réel et la description du dispositif de référence. Après adaptation, elle liste les effets conservés, fusionnés, déplacés, écrêtés ou supprimés.

Viennent ensuite les décisions de consentement, de politique applicative, de système d’exploitation et de sécurité matérielle. Les commandes adressées aux actionneurs doivent être rattachées aux limites actives. La fin n’est pas « lecture terminée », mais l’arrêt constaté et le retour à une position, une température ou une sortie neutre.

Même cette trace ne prouve pas automatiquement la sensation. Une commande n’est pas une mesure de déplacement ou de force ; une mesure n’est pas une perception. Les observations physiques et les comptes rendus d’utilisateur ont leur propre protocole. La discipline consiste à ne jamais emprunter leur autorité à la couche précédente.

RFC 9993 ajoute le transport RTP des données haptiques MPEG-I, la fragmentation, l’agrégation et les paramètres SDP, et met à jour haptics/hmpg. Il possède la question de la reconstruction du flux. Le présent dossier possède celle du passage d’un objet reconstruit à une sortie physique locale. Recevoir tous les paquets ne garantit ni l’adaptation ni l’actuation.

La doctrine de spécification initiale minimale de Lu Heng éclaire le partage des responsabilités. Le commun doit rester précis : famille, sous-types, syntaxe des paramètres, règle de rabattement. Les capacités, les choix futurs, le consentement et les limites demeurent locaux, mais doivent être observables. La discipline des couches de réalité sépare inscription IANA, en-tête, analyse, transformation, commande et sensation. La primauté du code en fonctionnement place enfin la trace de cet appareil au-dessus d’une déduction tirée du seul registre.

Sources