Resumo

  • O RFC 9695 distingue o fallback de um subtipo desconhecido para application/octet-stream da decisão local de ainda entregá-lo ao subsistema háptico; nenhuma delas, isoladamente, descreve o resultado físico.
  • A evidência operacional precisa registrar reconhecimento, valores ignorados, adaptação ao dispositivo, políticas, limitadores, comandos e retorno ao estado neutro, em vez de resumir tudo como reprodução concluída.

O nome genérico application/octet-stream costuma sugerir repouso: armazenar, baixar, não interpretar. Para a família háptica, essa impressão é insuficiente. RFC 9695 cria haptics como tipo de mídia de nível superior, registra inicialmente IVS, HJIF e HMPG e afirma que o conteúdo dessa família requer um subsistema háptico e hardware associado.

O rótulo resolve uma questão de encaminhamento. Ele não informa se o receptor entende o subtipo, se conhece todos os parâmetros, se possui os atuadores necessários, se adaptou o efeito ou se comandou energia ao corpo. Entre a classificação e a sensação existe uma sequência de decisões locais, e cada uma precisa do próprio recibo.

O fallback e o encaminhamento são decisões independentes

Quando o subtipo não é reconhecido, o RFC diz que ele deve ser tratado como application/octet-stream. A regra segue a prudência de RFC 2046: bytes de formato desconhecido não recebem uma semântica específica só porque o tipo principal é familiar.

O mesmo RFC permite que uma implementação passe o subtipo háptico desconhecido ao subsistema e ao hardware relacionados. Há uma razão legítima: a camada de aplicação talvez não conheça uma extensão que um plug-in, serviço do sistema ou equipamento mais novo compreenda. Extensibilidade exige algum caminho de descoberta.

Mas o registro de auditoria não pode dizer apenas “fallback aplicado”. Ele deve mostrar se o objeto foi armazenado, oferecido para download, submetido à busca de um decodificador, entregue ao serviço háptico ou bloqueado antes de qualquer saída. O fallback MIME não é, por si, uma barreira de atuação.

Também não basta dizer “entregue ao motor”. A entrega não prova que o formato foi identificado, que o parser terminou nem que o hardware recebeu comandos. O recibo precisa ligar a decisão da camada de mídia à decisão da aplicação e ao mecanismo de descoberta usado.

RFC 6838 define procedimentos para registrar tipos de mídia. RFC 9694 trata das exigências para um novo nome antes da barra. Esse é o problema do espaço de nomes. Aqui, o espaço de nomes já funcionou; a pergunta é o que aconteceu depois da entrega.

Continuar pode significar perder uma condição

Os parâmetros de RFC 9695 podem ter listas de subvalores separadas por vírgulas. Se um processador reconhece o parâmetro, mas não um dos subvalores, deve ignorar o desconhecido e prosseguir com os conhecidos. A regra permite que receptores antigos aproveitem partes de extensões novas.

O custo é a ambiguidade do sucesso. O emissor pode considerar a lista um conjunto inseparável de requisitos. O receptor pode tratá-la como alternativas. Se o valor descartado descrevia um tipo de dispositivo, uma parte do corpo, uma modalidade ou uma restrição, o processamento continua com uma intenção reduzida.

Um recibo de parâmetros deve reter o texto original, cada valor reconhecido e ignorado, os padrões aplicados e a configuração efetiva do decodificador. Deve também incluir a versão do software. Uma atualização pode passar a entender um valor antigo; a remoção de um componente pode fazer o contrário. O mesmo hash de arquivo, então, produz outro caminho sem que o conteúdo tenha mudado.

Independência de dispositivo é uma promessa de portabilidade, não de equivalência

IVS é um formato XML independente de dispositivo, mas o RFC adverte que nem todo equipamento consegue renderizar todos os efeitos. A descrição viaja entre produtos; capacidades físicas não viajam com ela.

HJIF, em JSON, e HMPG, binário, expressam efeitos temporais e espaciais, inclusive ligados a partes do corpo. Eles podem trazer a descrição de um dispositivo de referência para orientar a adaptação ao hardware real. Essa etapa transforma a experiência: escolhe o que combinar, reposicionar, reduzir, limitar ou omitir.

Uma matriz de oito atuadores pode virar duas pulsações em um aparelho menor. Um canal térmico pode desaparecer. Uma faixa de força pode ser comprimida. A resolução temporal pode deslocar eventos. Dois receptores podem aceitar o mesmo objeto, respeitar sua família de mídia e ainda gerar saídas fisicamente diferentes.

A documentação oficial do Apple Core Haptics ilustra essa camada local, sem demonstrar suporte a RFC 9695. Ela expõe eventos transitórios e contínuos, parâmetros e players. A preparação exige consultar capacidades do hardware, e os arquivos AHAP atribuem padrões quando certos parâmetros não aparecem. Motor, capacidade e valor padrão são parte da proveniência do resultado.

Mídia descritiva ainda atravessa software e controla energia

Os registros classificam esses formatos como mídia, não código executável. Isso orienta o tratamento, mas não elimina parsers XML, JSON e binários, alocação de memória, serviços de usuário, drivers ou caminhos próximos ao núcleo. Dados descritivos maliciosos podem explorar uma implementação vulnerável sem se declarar programa.

Há também o risco físico, mesmo quando todo o software se comporta como projetado. Sistemas hápticos podem produzir vibração, força cinestésica, temperatura e textura. RFC 9695 alerta que dispositivos térmicos e cinestésicos sem limites controlados podem causar lesão. A segurança depende de amplitude, força, temperatura, duração, taxa de variação, repetição e contexto do usuário.

São necessários dois casos de segurança. O primeiro cobre estrutura, memória, isolamento, codecs e drivers. O segundo cobre consentimento, perfil real de capacidade, limites locais, desligamento, neutralização e exposição acumulada. Uma classificação “não executável” não aprova nenhum deles automaticamente.

A API de Vibração do W3C mostra outra decisão local: o agente de usuário pode restringir vibração pela visibilidade do documento e por Permissions Policy. A API não equivale aos formatos de RFC 9695. Ela demonstra que uma solicitação válida pode ser negada por contexto, e que essa negação deve ser distinguida de erro de parse ou falta de hardware.

Quatro listas de efeitos, não um único status

A análise defensável começa pelo hash do objeto, tipo, subtipo e parâmetros. Em seguida, registra a versão do cadastro de tipos da IANA, o resultado do reconhecimento, o fallback e o parser. A primeira lista descreve os efeitos solicitados; a segunda, os efetivamente compreendidos.

A terceira lista vem da adaptação ao perfil do dispositivo: efeitos preservados, unidos, deslocados, reduzidos, cortados ou descartados. A quarta surge depois de consentimento, política do aplicativo, política do sistema e limites físicos: os comandos enviados ao driver.

O fim da transação precisa registrar resposta dos atuadores, erros, comando de parada e estado neutro confirmado. Mesmo assim, comando não é medição física, e medição não é sensação humana. Deslocamento, força ou temperatura exigem sensores; experiência exige protocolo de observação. Uma camada não deve tomar emprestada a certeza da seguinte.

RFC 9993 atualiza haptics/hmpg e define payload RTP, fragmentação, agregação e parâmetros SDP para háptica MPEG-I. Ele responde como unidades chegam e são reconstruídas. Este artigo responde o que acontece na passagem da unidade reconstruída para a máquina local. Transporte completo não assegura efeito completo.

A doutrina de especificação inicial mínima de Lu Heng oferece uma fronteira funcional. O comum pode fixar família, subtipos, sintaxe e fallback. Capacidade, adoção futura, consentimento e limites permanecem locais. A disciplina das camadas de realidade mantém separados cadastro, cabeçalho, parse, adaptação, comando, medição e sensação. A primazia do código em execução dá mais peso ao recibo deste endpoint do que a uma inferência sobre aquilo que o padrão permite.

Fontes