Resumo

  • A RFC 1556 descreveu três arranjos de responsabilidade: no modo visual, o programa de composição preparava a ordem; no implícito, o visualizador calculava; no explícito, sequências de controle dentro do texto orientavam a exibição.
  • O MIME podia preservar caracteres não ASCII sem provar que o destinatário reconstruiria a ordem de leitura pretendida. Charset, modo de direção, controles e contexto do renderizador exigiam comprovantes separados.
  • O documento de dezembro de 1993 era Informational, não um Internet Standard. HTML, Unicode e correio UTF-8 posteriores mostram a persistência da fronteira, mas não comprovam linhagem direta nem adoção dos sufixos propostos.

O recibo de entrega respondia à pergunta errada

Imagine uma mensagem histórica cuja cópia arquivada tem o mesmo hash da origem. O MIME é decodificado sem erro; cada caractere esperado está presente. Mesmo assim, um nome latino aparece de um lado do número em um leitor e do outro lado em outro. Ao copiar a linha, a pontuação muda novamente.

O recibo de transporte não é falso. Ele só encerra uma etapa anterior. Depois da entrega, alguém ainda precisa definir a direção-base do parágrafo, resolver trechos de sentidos opostos, posicionar caracteres neutros e aplicar tudo isso às linhas resultantes da quebra de texto.

Esse foi o campo da RFC 1556, Handling of Bi-directional Texts in MIME. Hank Nussbacher publicou o memo em dezembro de 1993. O registro do RFC Editor e a ficha do IETF o classificam como Informational; o próprio texto declara que não especifica nenhum padrão da Internet.

A proposta era estreita: descrever uma convenção direction para textos MIME bidirecionais. A divisão operacional que revelou era maior. Representação preservada e apresentação correta não eram a mesma evidência.

O MIME ampliou primeiro o que o correio conseguia carregar

A RFC 1521 permitiu que corpos de mensagem declarassem tipos e charsets além do ASCII simples. Base64 e Quoted-Printable protegiam os valores ao atravessar infraestrutura com limitações antigas. Sua página de informação registra o papel histórico do MIME Part One.

A RFC 1522 levou texto não ASCII a partes determinadas dos cabeçalhos. O compositor produzia um encoded-word; um leitor compatível o reconhecia, revertia a codificação e exibia o texto no charset indicado. O registro correspondente delimita essa extensão.

Um charset informa quais caracteres os valores representam. O transfer encoding informa como preservar esses valores no caminho. Quando ISO-8859-6 árabe ou ISO-8859-8 hebraico aparece na mesma linha que texto latino, nenhuma dessas respostas fixa sozinha a relação visual.

A RFC 1556 não contestava o êxito do MIME. Começava no ponto em que um decodificador podia terminar corretamente e um leitor ainda falhar.

A RFC hebraica vizinha mostrou a pré-ordenação

A RFC 1555, de Nussbacher e Yehavi Bourvine, tratou no mesmo mês de correio hebraico com MIME e ISO-8859-8. Sua página no RFC Editor também a classifica como Informational.

O padrão era direção visual. O usuário digitava hebraico da direita para a esquerda, mas o programa o codificava numa ordem da esquerda para a direita e o MIME o transmitia assim. O visualizador não precisava compreender a direção do conteúdo; recebia uma fileira já preparada para a tela esperada.

Essa compatibilidade cobrava seu preço do emissor. A sequência armazenada só funcionava enquanto outro software não a reinterpretasse como ordem lógica. Uma engine implícita aplicada a dados visuais podia ordenar pela segunda vez o que já tinha sido ordenado.

A RFC 1555 também descreveu perda concreta de contexto. Algumas configurações do Listserv distribuíam cabeçalhos abreviados, e arquivos automáticos podiam omitir a informação MIME. O conteúdo codificado permanecia, mas a orientação necessária para interpretá-lo sumia.

Mesmo o futuro correio transparente de oito bits apenas tornaria a codificação de transporte parcialmente obsoleta. Content-Type e directionality continuariam necessários. Um canal mais largo não escolhe a leitura.

Visual: a composição já havia tomado a decisão

Na RFC 1556, visual era o modo padrão e usava o nome ISO-8859 comum, sem sufixo. A aplicação de exibição seguia uma única direção primária, da esquerda para a direita, e tratava o material como texto unidirecional. O compositor precisava preparar os caracteres na sequência capaz de produzir a imagem correta. Não havia controles nem algoritmo de reordenação no destino.

A vantagem era compatibilidade com um terminal simples. A desvantagem era transformar a ignorância do viewer em parte do contrato. O compositor executava todo o trabalho e o destinatário precisava evitar executá-lo de novo.

Edição, busca e redimensionamento expunham a fragilidade. Mover o cursor, inserir uma palavra latina, quebrar a linha em outro ponto ou copiar o conteúdo manipulava uma ordem feita para uma disposição específica, não necessariamente a estrutura lógica da frase.

Visual não removia a direção. Antecipava a decisão e atribuía sua responsabilidade ao programa de origem.

Implicit: o contexto virou entrada de execução

Os nomes ISO-8859-6-i e ISO-8859-8-i representavam implicit. Um algoritmo determinava a apresentação segundo o tipo de cada caractere, sua posição em relação aos vizinhos e uma direção primária. A RFC 1556 remetia à ECMA TR/53 porque o procedimento completo era complexo.

O compositor podia conservar uma sequência mais lógica, mas o receptor assumia outras obrigações. Precisava reconhecer o modo, usar propriedades direcionais compatíveis e conhecer a base e os limites do parágrafo. Números, sinais e caracteres neutros dependem do entorno; a quebra de linha também altera a unidade de cálculo.

Um algoritmo comum reduz arbitrariedade, mas seu resultado não está contido no hash da mensagem. Duas engines podem receber a mesma decoded sequence e divergir por versão, direção-base, limite de markup ou segmentação.

O comprovante passou a incluir não apenas a carga, mas o ambiente que decidiu sua ordem visual.

Explicit: instruções invisíveis precisavam de dois guardiões

ISO-8859-6-e e ISO-8859-8-e indicavam explicit. Sequências de controle intercaladas no texto declaravam a direção. O emissor podia abrir ou alterar um contexto sem depender exclusivamente da inferência do leitor.

Ser explícito não garantia sobreviver. Um sanitizador podia apagar controles não imprimíveis, um conversor podia mantê-los como valores opacos e um escopo mal fechado podia atingir trechos não pretendidos. Comparar apenas as letras visíveis não detectaria a perda decisiva.

Segundo a RFC 1556, o ECMA TR/53 introduziu três funções de controle e alterou 22 funções existentes da ECMA-48. Não era um único marcador de direita para esquerda. A direção afetava posições ativas, movimentos e a relação entre componente de dados e componente de apresentação.

O emissor era responsável por inserir as instruções; o receptor, por preservá-las e executar seu estado. Os dois lados pertenciam à cadeia probatória.

A posição nos dados não era a posição na imagem

O modelo do ECMA TR/53 descrevia um dispositivo que recebia caracteres gráficos e funções de controle e produzia uma imagem legível segundo convenções de escrita. Ele separava data component e presentation component, com posições ativas capazes de se mover de modos diferentes.

Isso explica por que a questão não se resume à fonte. A fonte desenha um glifo. O modelo de apresentação decide ao lado de qual glifo ele aparece, como o cursor avança e em qual posição atuam backspace ou carriage return.

A RFC 1556 condensou essa arquitetura numa escolha MIME. O receptor precisava saber se recebera uma fileira visual pronta, uma sequência ainda sujeita a cálculo implícito ou um fluxo guiado por comandos explícitos. Perder a escolha era enviar dados corretos à máquina de apresentação errada.

Quatro falhas sem perder uma letra

A primeira é a perda de metadados. Um gateway transforma ISO-8859-8-i em ISO-8859-8, ou um arquivo descarta Content-Type. Os caracteres ficam; o modo desaparece.

A segunda é o duplo reordenamento. O compositor preparou visual order, mas o leitor pressupõe logical order e executa implicit. Cada peça obedece ao seu contrato local, e a combinação produz erro.

A terceira é a remoção de controles. Uma política de segurança retém os caracteres imprimíveis e elimina comandos explícitos invisíveis. Uma comparação superficial relata equivalência.

A quarta é a deriva de contexto. Engines implícitas usam outra direção-base, quebra de linha, limite de estilo ou revisão do algoritmo. A decoded sequence é uma; a visual sequence não.

Números, pontuação e identificadores tornam o efeito operacional. Um sinal pode se associar ao valor errado; uma identificação pode parecer correta e ser copiada em outra ordem. A presença de todos os caracteres não prova a preservação das relações entre eles.

As ferramentas posteriores preservaram a fronteira, não uma genealogia automática

Em 1997, a RFC 2070 acrescentou ao HTML recursos como o atributo DIR e o elemento de override BDO. Seu registro pertence ao markup da Web; não comprova implantação direta dos sufixos da RFC 1556.

Uma versão inicial do Unicode Bidirectional Algorithm distinguiu ordem lógica na memória de ordem exibida e explicou que códigos direcionais atuavam na apresentação. A UAX #9 atual evoluiu muito e também delimita como protocolos de nível superior podem fornecer contexto.

Em 2012, a RFC 6532 permitiu UTF-8 direto em valores de cabeçalho num ambiente de correio compatível de ponta a ponta. Sua página de informação registra esse contrato separado. Ampliar e simplificar o repertório transportável não fundiu a ordem armazenada com a ordem visível.

As fontes demonstram a persistência do limite. Não demonstram adoção de -i e -e, nem uma linha única da RFC 1556 até Unicode, HTML ou SMTPUTF8.

Uma captura de tela não basta

O recibo de transporte deve manter octetos originais, hash, codificação de transferência e sequência decodificada. Ele responde se a representação mudou no caminho.

O recibo de interpretação guarda Content-Type, charset, modo, controles explícitos, direção-base, markup e style superiores, renderer e versão do algoritmo. Ele explica quais regras o receptor acreditou aplicar.

O recibo de apresentação conserva quebras de linha, visual order resolvida, captura e resultado de copiar, colar ou fazer round trip. Ele registra o que apareceu numa condição específica.

Uma tela sem entrada prova uma imagem; um hash sem saída prova uma sequência. Os testes devem misturar árabe ou hebraico, latim, números, sinais, neutros, contextos aninhados e larguras diferentes. Numa migração, resultados antigo e novo devem permanecer até que a diferença seja explicada.

Publicação não era realidade operacional

A Running-Code Primacy de Heng Lu oferece uma disciplina atual: documento coordena; implementação, operação e uso determinam a realidade. A publicação da RFC 1556 comprova uma convenção documentada, não quais programas a executaram.

Minimum Initial Specification, Localized Future Decision e Voluntary Adoption perguntam quais regras comuns são mínimas, determinísticas e verificáveis localmente. A igualdade dos caracteres transportados era um invariante fraco demais; modo, contexto e procedimento de apresentação também precisavam de prova.

A disciplina das camadas de realidade impede o recibo de transporte de falar pela tela. É uma lente posterior, não evidência da intenção de Nussbacher ou da ECMA; ela limita o que nossa história pode afirmar.

A questão era quem já havia agido

No visual, o compositor já tinha ordenado. No implicit, o renderer ainda ordenaria. No explicit, o emissor enviara comandos para o receptor executar. Sem saber qual situação recebeu, um sistema podia seguir perfeitamente sua regra local e trair a mensagem.

A história da RFC 1556 não é a incapacidade do MIME de carregar hebraico ou árabe. O MIME tornou a viagem possível. O pequeno memo recusou transformar o recibo da viagem em certificado de leitura.

Sequência idêntica prova chegada intacta. Modo e controles preservados provam contexto de interpretação. Renderer identificado e testado prova um resultado visível. Só os três juntos fazem “chegou corretamente” significar mais que “os bytes estão aqui”.

Fontes