Resumo

  • RFC 2130 separou conjunto de caracteres codificados, esquema de codificação em octetos e sintaxe de transferência das escolhas de idioma, localidade, cultura e apresentação. Uma transmissão correta não atesta que o leitor recebeu o sentido esperado.
  • O relatório recomendou rótulos MIME registrados e padrões ISO 10646/UTF-8 para novos protocolos, mas reconheceu alternativas, negociação e compatibilidade. Era orientação Informational, não um novo protocolo nem um levantamento de adoção.

Duas mensagens no mesmo canal

Uma ordem SMTP e a mensagem de erro dirigida ao usuário podem aparecer no mesmo diálogo. Só a segunda precisa falar a língua de quem lê. RFC 2130 usou o contraste para evitar que uma variante traduzida de MAIL FROM se tornasse parte da maquinaria do protocolo: os programas já existentes dependiam da gramática conhecida. Uma explicação humana, por outro lado, poderia ser localizada por uma extensão que definisse idioma e representação. A fronteira importante não é entre inglês e outros idiomas; é entre um token compartilhado por máquinas e conteúdo destinado a pessoas.

O encontro patrocinado pelo IAB ocorreu em 29 de fevereiro e 1º de março de 1996. Publicado em abril de 1997, seu relatório não especificou um padrão da Internet. Correio, diretórios e Web já lidavam de maneiras diferentes com textos internacionais. Em vez de exigir um único conjunto universal, a oficina organizou as decisões que uma especificação precisava tornar explícitas, sem quebrar práticas instaladas.

O que significa atravessar o fio

No modelo de sete camadas, três dizem respeito principalmente à transmissão. O CCS atribui números a caracteres abstratos; o CES converte os valores em octetos; o TES transforma dados já codificados para caber nas exigências de um meio. ISO 10646, UTF-8 e Base64 ilustram funções diferentes. MIME podia identificar CCS e CES juntos pelo parâmetro charset, ao passo que Content-Transfer-Encoding cuidava da transformação para transporte. O relatório observou que os registros MIME existentes nem sempre separavam as ideias com precisão e recomendou esclarecer os dois primeiros níveis em registros futuros.

Quatro camadas continuam do lado do usuário: idioma, localidade para datas e moeda, convenções culturais e disposição visual, incluindo fontes e quebra de linha. A oficina se concentrou nos requisitos de transmissão e deixou vários problemas de interface fora de escopo. Mesmo assim, notou que o idioma podia ajudar a escolher glifos Han e a indexar documentos multilíngues. Decodificar um caractere não determina a forma adequada de mostrá-lo. Tampouco demonstra que a pessoa entendeu o que viu.

Para descobrir qual CCS, CES ou TES foi empregado, um receptor pode ter uma escolha fixada na norma, um rótulo no envelope, uma indicação dentro do fluxo, um acordo anterior ou negociação em tempo de conexão. Adivinhar pela origem geográfica era a alternativa frágil. Daí a preferência por valores MIME registrados para conjuntos e idiomas, salvo quando um mecanismo já existente determinasse a informação sem palpite. O rótulo precisa descrever a realidade; um cabeçalho convincente não corrige bytes inconsistentes.

O alcance de um identificador

O relatório tratou separadamente a maquinaria, os identificadores e os dados. Citou RFC 1958 ao recomendar ASCII indiferente a maiúsculas para nomes públicos amplamente visíveis, como nomes DNS e elementos textuais do protocolo. Uma pasta privada de caixa postal não tem o mesmo alcance. Uma atualização de protocolos ASCII para UTF-8 deveria negociar versão ou charset e manter uma saída compatível com ASCII; não basta reinterpretar os dados antigos. Texto de mensagens, bancos e HTML, em contraste, exige suporte a múltiplos conjuntos e informação contextual.

O padrão proposto para novos protocolos textuais era ISO 10646 como CCS e UTF-8 como CES. A necessidade de retrocompatibilidade podia preservar o padrão antigo; um caminho de sete bits podia exigir outra transformação. Não se estabeleceu um TES universal, nem se declarou obsoletos os demais conjuntos. RFC 2044 detalhou os bytes UTF-8; RFC 2066, uma negociação Telnet; RFC 2070, a decodificação HTML; RFC 2152, texto Unicode em correio de sete bits. RFC 2130 colocava esses contratos distintos em perspectiva, sem prometer que um substituísse os demais.

Fontes e limites

As notas de Lu Heng sobre realidade e código em execução oferecem uma lente editorial retrospectiva, não evidência da intenção dos autores. O relatório não mede implantação, qualidade de tela ou compreensão de usuários específicos.