Resumo

  • A RFC 2987 submeteu charset e language à mesma comparação por igualdade, mas descreveu a primeira como capacidade usual e a segunda como preferência usual.
  • Nome principal de charset e comparação da etiqueta linguística inteira reduziam ambiguidade sem provar decodificação, renderização, voz ou compreensão.
  • Um peso q classificava predicados numa decisão local; não era comprovante de existência da variante, satisfação do usuário ou êxito do serviço.

Duas fichas lado a lado

Publicada em novembro de 2000 como Proposed Standard, a RFC 2987 é composta principalmente de duas fichas de registro. charset recebeu o OID 1.3.6.1.8.1.31; language, o 1.3.6.1.8.1.32. O registro atual da IANA ainda mantém os nomes como itens 31 e 32 da árvore IETF de características de mídia.

A RFC 2506 havia criado um espaço de nomes neutro em relação a transporte e protocolo. Uma aplicação poderia descrever recursos de apresentação sem inventar uma gramática própria. A RFC 2533 ofereceu a sintaxe para combinar predicados e atribuir valores de qualidade. O ganho era interoperabilidade de vocabulário.

As duas fichas pareciam simétricas. Os valores eram tokens registrados; a única comparação era igualdade; a caixa não importava; exemplos usavam uma alternativa OR com pesos q.

O próprio texto, porém, rompeu a simetria semântica.

Para a maioria dos dispositivos, charset era normalmente uma capacidade. Um equipamento não consegue processar de forma inteligente texto num conjunto de caracteres que desconhece. language, em contraste, era normalmente uma preferência, não uma exigência. A palavra “exibir” frequentemente significaria fala gerada por computador, mas a distinção é mais geral: desejar um idioma não é o mesmo que a máquina ser incapaz de processar os demais.

A estrutura comum levava dois tipos de restrição.

Charset é uma condição para executar

O exemplo classificava utf-8, iso-8859-1 e utf-16 com valores 1,0, 0,9 e 0,5. Os números não transformavam decodificadores ausentes em alternativas disponíveis.

Uma coincidência com charset=utf-8 não demonstra que os bytes recebidos sejam UTF-8. Não demonstra que o decodificador esteja instalado ou correto. Depois da conversão, a fonte ainda pode não ter os glifos. Uma tela tecnicamente correta ainda pode ser incompreensível para quem a lê. O token abre uma cadeia de verificação; não a encerra.

A RFC 2913 registrou type separadamente. Um dispositivo poderia tratar text/plain e, ainda assim, não conhecer todas as codificações possíveis de texto. Tipo de mídia e regra de transformação dos bytes eram declarações próximas, mas independentes.

Os aliases criavam outro risco. A RFC 2978 permitia vários nomes para o mesmo charset, exigia um nome principal e impedia que um nome identificasse mais de um conjunto. A RFC 2987 desaconselhava aliases em expressões, pois ferramentas poderiam convertê-los para o nome principal durante a manipulação.

Usar o nome principal em minúsculas eliminava diferenças ortográficas evitáveis. Não validava a tabela de conversão nem o código em execução. Canonicalizar um nome não produz capacidade.

O documento também dizia que a capacidade charset deveria acompanhar qualquer capacidade de tratar dados textuais. Declarar apenas “texto” omitiria justamente a condição que transforma octetos em caracteres.

Idioma organiza uma escolha, não um circuito

O segundo exemplo classificava no-nynorsk, no-bokmaal e i-sami-no. A operação continuava sendo igualdade, mas uma desigualdade não representava necessariamente impossibilidade.

A RFC 1766 formava etiquetas de língua com uma parte principal e subetiquetas. Ao mesmo tempo, instruía aplicações a tratar a etiqueta inteira como um único token. As subetiquetas tinham função administrativa. Não eram uma árvore universal de inteligibilidade, e um prefixo compartilhado não provava compreensão mútua.

A RFC 2987 preservou a regra: comparar o token completo, sem considerar caixa e sem usar subetiquetas na comparação. A estrutura da string não podia inventar conhecimento sobre uma pessoa.

Por ser preferência, uma alternativa linguística poderia ser aceita quando a primeira escolha faltasse. Ou poderia ser inútil para aquele usuário. A decisão dependia das variantes existentes, das prioridades declaradas e da política local de fallback.

Transformar toda preferência em requisito elimina conteúdo aproveitável. Tratar toda preferência como dispensável elimina o usuário da negociação. O padrão tornava os dados comparáveis, não fixava uma decisão mundial.

Peso de qualidade não é qualidade medida

Na RFC 2533, o valor de qualidade qualifica um predicado e assume 1 quando não é informado. O documento não determina uma fórmula universal para combinar preferências. Candidatos e consequências variam entre aplicações.

Assim, q=1.0 prova apenas que um perfil classificou aquele predicado naquele contexto. Não prova que o perfil esteja atual, que haja conteúdo na língua, que a fala seja natural, que o rótulo corresponda aos bytes ou que o usuário conclua a tarefa.

No caso do charset, a fronteira é mais rígida, mas o peso continua incapaz de instalar o decodificador, confirmar a preservação dos bytes ou certificar a renderização.

Uma decisão auditável guarda o conjunto recebido, a normalização, a versão do avaliador, a política, os candidatos, a escolha, o recurso usado e o resultado. “Negociação bem-sucedida” não responde a todas essas perguntas.

O registro dá nome ao problema

A permanência das entradas da IANA mostra a utilidade do trabalho de coordenação. Implementações independentes conseguem referenciar os mesmos nomes e a mesma semântica de igualdade. Isso não cria um avaliador central.

Quem produz o perfil controla o que anuncia. O fornecedor controla as representações disponíveis. O receptor controla normalização, ranking e fallback. O usuário recebe o efeito. Nenhum desses atores domina toda a cadeia.

A ideia de Especificação Inicial Mínima de Lu Heng ajuda a situar o desenho: padronizam-se os nomes, os domínios de valor e as comparações necessários à interoperabilidade; decisões futuras ficam locais. Não existe autoridade global para escolher preferências.

Mas escolha local exige evidência local. Se uma implementação endurece uma preferência ou amolece uma capacidade, ela controla a interpretação decisiva. Precisa registrar a regra e a consequência, sem atribuir sua política ao registro.

A Primazia do Código em Execução oferece o teste seguinte. A publicação demonstra que a especificação existe. Não demonstra que o aparelho possui decodificador, fonte, voz, variante ou perfil atual. O fato operacional é o que o código comparou, escolheu e apresentou.

As camadas são registro, expressão, normalização, avaliação, seleção, capacidade, execução, percepção e resultado. Uma camada verdadeira não recebe procuração para falar pelas seguintes.

A pequena advertência de segurança

As duas fichas observavam que, se houver uma falha conhecida ao exibir certo charset ou idioma num ambiente, revelar que o dispositivo o aceita pode ajudar um atacante em pequena medida. A RFC não indicava produto nem incidente.

Ainda assim, a observação mostra que uma declaração de capacidade é dado operacional. Ela dirige escolhas e pode revelar superfície de ataque. O sistema deve expor apenas o necessário e nunca interpretar “aceito” como “seguro”.

O mérito histórico da RFC 2987 foi permitir que duas declarações viajassem na mesma engrenagem sem fazê-las dizer a mesma coisa.

Uma geralmente respondia ao que a máquina podia fazer. A outra, ao que a pessoa preferia. Igualdade e pesos coordenavam as respostas; não igualavam sua força.

Fontes