Planteamiento y escenario
Su equipo necesita intercambiar pistas hápticas mediante descargas, medios en vivo y transferencias de dispositivo a dispositivo. Los tipos existentes de audio, video y application solo expresan parcialmente la semántica. Utilizando RFC 9694, evalúe si se justifica un nuevo tipo de medio de nivel superior haptics y aborde subtipos, negociación de contenido, implementaciones desconocidas, evolución y límites de seguridad.
Qué evalúa el entrevistador
- Si distingue entre un tipo de nivel superior, un subtipo concreto, un parámetro y un formato de archivo en lugar de tratar una cadena MIME como un protocolo completo.
- Si aplica un alcance claro, al menos un subtipo significativo, una especificación pública, interoperabilidad y los requisitos de registro de IANA.
- Si diseña rutas de degradación (downgrade) para tipos desconocidos, clientes antiguos, proxies, cachés y negociación de contenido.
- Si identifica riesgos de intérprete, accionamiento de hardware, agotamiento de recursos, privacidad y seguridad física en lugar de discutir únicamente el registro.
Preguntas de aclaración para hacer primero
Confirme si los datos representan un medio sensorial independiente, si ya existen múltiples formatos interoperables, si deben sincronizarse con audio o video y si los clientes pueden ignorar de forma segura las capacidades desconocidas. Pregunte sobre el transporte, la encapsulación de archivos, la latencia, el almacenamiento en caché, el descubrimiento de capacidades del dispositivo y la experiencia de usuario ante fallas. Si solo existe un formato privado para una única aplicación, prefiera un subtipo de application o un registro privado en lugar de crear un tipo de nivel superior.
Estructura de respuesta de 30 segundos
Primero demostraría que los tipos de nivel superior existentes no pueden expresar la semántica con precisión y verificaría la presencia de múltiples subtipos interoperables y necesidades reales de despliegue. RFC 9694 exige un alcance claro y criterios de subtipos, al menos un subtipo descrito y consideraciones de seguridad completas. Si la evidencia se sostiene, propondría haptics manteniendo al mismo tiempo una ruta de compatibilidad en contenedores existentes. Definiría la negociación, el comportamiento ante subtipos desconocidos, el registro de parámetros y el rollback. Las implementaciones rechazarían capacidades peligrosas de manera predeterminada, separarían el análisis sintáctico (parsing) del renderizado en hardware y limitarían los parámetros de energía, duración e intensidad.
Análisis detallado paso a paso
1. Decidir primero el nivel de tipo
Un tipo de nivel superior expresa la semántica del contenido a través de diferentes formatos; un subtipo identifica una codificación o formato de intercambio concreto; los parámetros añaden información de negociación. No solicite un tipo de nivel superior para cada nueva extensión de archivo. Verifique si el contenido encaja en la semántica de audio, video, image o application y si cuenta con capacidades compartidas entre diferentes implementaciones.
2. Poner a prueba el umbral de RFC 9694
La propuesta debe establecer qué pertenece al tipo y qué queda explícitamente fuera, de modo que los límites de los subtipos futuros permanezcan claros. Necesita al menos un subtipo útil; un nombre de nivel superior vacío no tiene valor de interoperabilidad. Incluya una especificación revisable públicamente, detalles de codificación e interoperabilidad, y consideraciones de seguridad que cubran cada subtipo o riesgo común importante.
3. Utilizar haptics como caso de estudio
RFC 9695 define haptics como un tipo de medio sensorial independiente y registra subtipos como ivs, hjif y hmpg. Los datos hápticos pueden ser autónomos o sincronizarse con audio y video; ubicarlos bajo application perdería la semántica de medios. El caso también muestra que un tipo de nivel superior describe la clase de contenido, mientras que cada subtipo define cómo se interpreta una codificación.
4. Diseñar la negociación y el fallback
El emisor selecciona un subtipo a partir de Accept y de las capacidades del dispositivo; el servidor declara las dimensiones Vary pertinentes para evitar la contaminación de la caché. Cuando un cliente antiguo no puede entender el nuevo tipo, proporcione un contenedor de audio o video, una alternativa estática o un estado de no disponibilidad explícito. Los subtipos desconocidos no son código ejecutable; los analizadores rechazan los parámetros no admitidos y registran el motivo.
5. Delimitar el análisis sintáctico y el hardware
Separe la decodificación, las comprobaciones de políticas y el renderizado en hardware. Limite el tamaño de archivo, la duración, la frecuencia de muestreo, la amplitud y los trabajos concurrentes para evitar el agotamiento de recursos. Los datos hápticos pueden controlar actuadores, por lo que deben ejecutarse dentro del consentimiento del usuario, la capacidad del dispositivo y los límites de seguridad. El servidor no debe tratar Content-Type como un límite de confianza.
6. Planificar el registro y la evolución
Prepare la plantilla de IANA, las reglas de nomenclatura de subtipos, los parámetros y la sección de seguridad, incluyendo la versión estable de la especificación y el controlador de cambios. Defina un comportamiento retrocompatible para los nuevos parámetros; los parámetros desconocidos se ignoran o se rechazan según la especificación. Monitoree las fallas de negociación, la tasa de fallback, los errores de análisis sintáctico, los aciertos de caché (cache hits) y los rechazos por seguridad del dispositivo antes de expandir el despliegue.
Respuesta de ejemplo de alta calidad
Construiría tres tablas: semántica, ecosistema y riesgo. Si los datos son una codificación privada para una sola aplicación, utilice un subtipo de application. Si es un medio sensorial independiente con múltiples formatos interoperables y necesidades de intercambio entre archivos, transmisiones en vivo y dispositivos, utilice RFC 9694 para justificar un tipo de nivel superior. La propuesta necesita límites claros, al menos un subtipo útil, una especificación pública, detalles de interoperabilidad y consideraciones de seguridad para riesgos compartidos. El caso de haptics en RFC 9695 muestra que el tipo de nivel superior transporta la semántica del medio mientras que ivs, hjif y hmpg definen codificaciones concretas. El servidor negocia un subtipo, ofrece a los clientes antiguos un contenedor compatible o un fallback explícito, y varía las cachés según las dimensiones reales de negociación. El análisis sintáctico, las comprobaciones de políticas y el renderizado en hardware están separados; el tamaño, la duración, la intensidad y la concurrencia están delimitados, y se requieren la capacidad del dispositivo y el consentimiento del usuario. Los subtipos desconocidos o parámetros peligrosos se rechazan por defecto. Content-Type no es un límite de confianza. Después del lanzamiento, rastrearía fallas de negociación, fallbacks, errores de análisis sintáctico y rechazos de seguridad antes de hacer crecer el ecosistema.
Errores comunes
- Crear un tipo de medio de nivel superior para cada nuevo formato de archivo.
- Escribir solo un nombre de IANA sin alcance, reglas de subtipos o una especificación pública.
- Tratar el tipo de nivel superior como un formato de codificación y mezclar las responsabilidades de parámetros e interoperabilidad.
- Permitir que clientes desconocidos traten los datos como contenido ejecutable o ignorar las diferencias de proxies y cachés.
- Validar únicamente Content-Type dejando sin límites los recursos de análisis sintáctico, la capacidad de hardware y el consentimiento del usuario.
Preguntas de seguimiento y respuestas
¿Cuándo es mejor un subtipo de application?
Úselo cuando la estructura sea específica de la aplicación, no tenga semántica de medios independiente y cuente con una o pocas codificaciones estrictamente controladas. Reconsidere un tipo de nivel superior cuando aparezcan formatos entre múltiples proveedores, negociación independiente y capacidades compartidas estables.
¿Cómo evitar romper clientes antiguos?
Haga que el emisor ofrezca un contenedor compatible o una representación alternativa, y negocie a partir de Accept y de la capacidad del dispositivo. Los clientes antiguos reciben un estado explícito de no disponible o una representación que pueden renderizar. Incluya las dimensiones reales de negociación en las claves de caché.
¿Cuál es el límite de seguridad para los datos hápticos?
El analizador delimita el tamaño, la duración, la frecuencia y la intensidad; el renderizador recorta según los límites de seguridad del dispositivo. Exija el consentimiento del usuario y comprobaciones de capacidad. La autenticación, la autorización y la validación de contenido se mantienen independientes del tipo de medio; un valor haptics no hace que una carga útil sea confiable.