Resumen

  • RFC 9695 permite ignorar subvalores desconocidos y seguir procesando; por tanto, una respuesta correcta puede representar una interpretación parcial, no la conservación íntegra de la solicitud.
  • La etiqueta haptics/* encamina contenido hacia una familia física, pero la prueba termina mucho después: en la adaptación documentada, los límites activos, las órdenes al actuador y el regreso confirmado a neutral.

Un parámetro contiene tres subvalores. El receptor reconoce dos, descarta el tercero y devuelve éxito. En muchas interfaces de software, esa conducta es una victoria de compatibilidad. En un sistema háptico, todavía no sabemos si el tercer valor era decorativo, si nombraba un dispositivo ausente o si imponía la condición que evitaba aplicar el efecto al hardware equivocado.

RFC 9695 registra haptics como tipo de nivel superior y crea inicialmente haptics/ivs, haptics/hjif y haptics/hmpg. El tipo anuncia que el contenido requiere un subsistema háptico y hardware asociado. El subtipo identifica la representación exacta. Esa arquitectura hace posible el encaminamiento común, pero no puede describir todas las decisiones que un equipo toma entre el archivo y el cuerpo.

La semántica parcial se parece demasiado al éxito

El RFC contempla parámetros con listas de subvalores separadas por comas. Si un procesador entiende el parámetro pero no uno de sus subvalores, debe ignorar el desconocido y continuar con los conocidos. La regla evita que una extensión futura convierta todo el objeto en ilegible para software anterior.

Sin embargo, “continuar” es una instrucción de interoperabilidad, no una afirmación de equivalencia. El emisor puede haber pensado la lista como un conjunto de condiciones concurrentes. El receptor puede interpretarla como opciones independientes. La sintaxis sobrevive mientras la intención se contrae.

La diferencia solo aparece si el recibo enumera el valor original, el subconjunto reconocido, lo ignorado y cualquier valor predeterminado. También debe conservar la versión de la implementación y la configuración final del decodificador. Un campo booleano processed=true no permite saber si se ejecutó la petición, una aproximación o una versión vacía.

Hay además una dimensión temporal. Tras una actualización, un receptor puede empezar a comprender el subvalor omitido; después de retirar un componente, puede dejar de hacerlo. El mismo hash de entrada producirá otra ruta. La reproducibilidad exige ligar el objeto no solo al dispositivo, sino al conjunto de capacidades y reglas vigente en ese instante.

El subtipo desconocido tiene dos destinos posibles

RFC 9695 indica que un subtipo háptico no reconocido debería tratarse como application/octet-stream. El principio de RFC 2046 es prudente: unos bytes desconocidos no adquieren semántica ejecutable por llevar un nombre de familia familiar.

El documento permite, al mismo tiempo, que una implementación entregue un subtipo desconocido al subsistema háptico y al hardware asociado. Es una puerta de extensión: una aplicación puede no conocer el formato que un complemento o servicio de dispositivo sí conoce. También obliga a separar dos afirmaciones que suelen mezclarse. La capa MIME puede no haber reconocido el formato; la política local aún puede haber decidido explorarlo.

Por eso “cayó a octet-stream” no demuestra aislamiento físico, y “se envió al motor háptico” no demuestra decodificación válida. El registro operativo debe identificar la rama MIME y la rama de aplicación, el mecanismo de descubrimiento de decodificadores, el aislamiento aplicado y la condición exacta que habilita la actuación.

RFC 6838 y RFC 9694 explican cómo se gobierna el espacio de tipos y por qué un nuevo nombre de nivel superior es excepcional. Ese no es el objeto de este informe. Aquí el nombre ya existe y funciona; la cuestión es qué autoridad conserva cuando los bytes entran en capas locales.

Un formato independiente no produce dispositivos equivalentes

IVS es un formato XML independiente del dispositivo. RFC 9695 advierte que no todos los equipos pueden representar todos sus efectos. La independencia evita fijar el contenido a un producto concreto. No crea motores, actuadores, bandas de frecuencia ni canales térmicos donde no existen.

HJIF, basado en JSON, y HMPG, binario, expresan efectos temporales y espaciales. Pueden asociarlos con partes del cuerpo e incluir la descripción de un dispositivo de referencia. El software usa esa referencia para adaptar el contenido al hardware real. La adaptación es el lugar donde una experiencia ideal se convierte en una selección de posibilidades.

Si la referencia tiene una matriz de actuadores y el equipo real solo uno, un barrido espacial puede reducirse a una vibración global. Si la fuerza máxima es menor, se recorta. Si falta la modalidad, se omite. Si la resolución temporal cambia, se reprograma. Dos receptores conformes pueden aceptar el mismo objeto y emitir salidas físicas sustancialmente distintas.

La documentación oficial de Apple Core Haptics sirve como ejemplo de esa capa local, no como prueba de que Apple implemente RFC 9695. Presenta eventos transitorios y continuos, parámetros, reproductores y un motor. También exige comprobar si el hardware admite háptica. En los archivos AHAP, la ausencia de parámetros activa valores predeterminados. La lección probatoria es concreta: motor, capacidad, defecto y dispositivo forman parte del resultado.

La categoría “medio” no controla energía

Los registros describen estos subtipos como medios, no como código ejecutable. La distinción orienta a las aplicaciones, pero no elimina los parsers. XML, JSON y formatos binarios atraviesan bibliotecas, memoria, procesos de usuario y, según la implementación, caminos cercanos al núcleo y al controlador. Datos descriptivos maliciosos pueden buscar fallos allí sin presentarse como un programa.

El segundo riesgo aparece incluso con un parser perfecto. La salida háptica puede ser vibración, fuerza cinestésica, temperatura u otras sensaciones. RFC 9695 advierte del daño que puede causar un control inadecuado de equipos térmicos o cinestésicos. El límite importante no es el tamaño del archivo, sino la energía, amplitud, fuerza, temperatura, duración, variación y repetición autorizadas.

Conviene mantener dos expedientes. La seguridad de interpretación cubre estructura, memoria, aislamiento y controladores. La seguridad de actuación cubre consentimiento, capacidad real, límites, parada, estado neutral y exposición acumulada. Aprobar uno no aprueba el otro.

La API de vibración del W3C muestra una capa adicional: el agente de usuario puede restringir una solicitud por visibilidad y Permissions Policy. No equivale a IVS, HJIF ni HMPG. Sirve para recordar que una petición válida puede ser denegada localmente, y que esa denegación debe registrarse por separado de un error de formato o de la ausencia de hardware.

La cadena de evidencia termina después del controlador

El primer recibo fija el hash del objeto, el tipo, subtipo y parámetros. El segundo informa qué entrada del registro de IANA conocía el receptor. Después vienen reconocimiento, fallback, parser, valores ignorados y configuración de salida del decodificador.

Una fase de adaptación compara el dispositivo de referencia con el perfil real: número y posición de actuadores, modalidades, rangos, resolución y límites. Debe producir un diferencial de efectos: preservados, fusionados, desplazados, reducidos, recortados u omitidos. La política de aplicación y del sistema operativo decide luego si la actuación está permitida.

Las órdenes al controlador deben llevar los límites activos. La conclusión debe confirmar parada y estado neutral. Incluso entonces, una orden no prueba el movimiento real, y una medida física no prueba una sensación humana. Esas observaciones necesitan sensores o protocolos de usuario propios. El lenguaje “se reprodujo” debe reservarse para una afirmación con sujeto y método explícitos.

RFC 9993 actualiza haptics/hmpg y define transporte RTP, fragmentación, agregación y parámetros SDP para háptica MPEG-I. Reconstruir correctamente una unidad es una prueba de transporte. Este informe empieza después: subtipo, parámetros, adaptación y salida. Un flujo completo puede llegar a un dispositivo incapaz de realizar uno de sus efectos.

La especificación inicial mínima de Lu Heng encaja con esta arquitectura. La capa compartida debe ser pequeña y firme: nombres, sintaxis y conducta base. La elección futura, la capacidad y el riesgo permanecen localizados y voluntarios. La disciplina de capas de realidad impide confundir registro, encabezado, parseo, comando, medida y experiencia. La primacía del código en ejecución coloca el recibo de este endpoint por encima de una inferencia basada solamente en lo que el estándar permite.

Fuentes