Resumo

  • RFC 1523 limitou de propósito o text/enriched: dados ASCII ou compatíveis deveriam tolerar exibição bruta, e um leitor mínimo poderia retirar comandos para produzir prosa legível.
  • O resultado degradado não era uma cópia fiel. Efeitos desconhecidos, parâmetros ocultos, escolhas locais de renderização e outra representação em multipart/alternative podiam desaparecer enquanto as palavras permaneciam.

Quem compunha pagava a conta primeiro

Publicado em setembro de 1993 com status Informational, RFC 1523 refinou o text/richtext do RFC 1341 com o nome text/enriched. Em vez de tentar reproduzir um editor completo, limitou o vocabulário ao que o processador de texto principal de um usuário provavelmente conseguiria mostrar.

A restrição reduzia o que podia ser enviado, mas aumentava a chance de exibição correta. Um sistema orientado a teletipo deveria conseguir retirar a marcação e manter texto compreensível. Se o conjunto fosse ASCII ou um superconjunto de oito bits, até um leitor sem MIME deveria encontrar dados brutos razoavelmente legíveis.

Os comandos eram nomes ASCII sem diferença entre maiúsculas e minúsculas, dentro de sinais de menor e maior, com no máximo 60 caracteres. << representava um < literal. Os ambientes precisavam fechar, permanecer balanceados e formar aninhamento correto.

Essa obrigação tornava o compositor mais complexo. O retorno vinha no destinatário: um leitor podia empilhar estados na abertura e restaurá-los no fechamento. O RFC sugeria tratamento razoável para estrutura malformada, mas não transformava cruzamentos inválidos em semântica confiável.

A quebra física não era necessariamente parágrafo

Um CRLF isolado virava espaço. Uma série de N CRLF resultava em N−1 quebras visíveis. Assim, um salto inserido para transportar uma linha longa não precisava alterar o parágrafo escrito, enquanto uma linha vazia continuava expressiva.

A regra também mostra por que o arquivo recebido não é a tela. Bytes, linhas físicas, texto reconstruído e disposição visual são registros diferentes. Se somente a renderização sobreviver, não será possível atribuir a mudança ao autor, ao gateway ou ao parser.

Comandos desconhecidos deviam ser no-ops. O conteúdo interno passava; o efeito sumia. Nomes X- atendiam extensões privadas, e extensões formais exigiam outro documento Internet. Um leitor antigo ganhava continuidade, mas podia transformar um aviso visual novo em prosa sem destaque.

O ambiente <param> separava ainda mais texto público e estado de extensão. Seu conteúdo podia ser interpretado ou ignorado, mas não exibido. A implementação mínima removia comandos e parâmetros. Uma mensagem gramaticalmente legível podia, portanto, não carregar na tela o valor que orientava o recurso novo.

Até o leitor mínimo precisava conhecer estados

nofill suspendia o preenchimento de linhas e o tratamento usual de CRLF, mantendo outras funções enriched. verbatim também suspendia justificação e interpretação de comandos internos até seu encerramento. Apagar tudo entre ângulos sem saber o contexto não constituía um conversor correto.

O mínimo conformante reconhecia o delimitador literal e os ambientes relevantes, eliminava marcação e parâmetros e aplicava a reconstrução de quebras. Isso produzia texto legível. Não comprovava equivalência de fontes, recuos, ênfase ou intenção.

O receptor completava a aparência. Largura de linha, fontes, incremento de indentação, justificação e combinações dependiam da capacidade local. Quando não pudesse combinar comandos, o leitor poderia favorecer o mais interno que reconhecesse. Duas telas distintas podiam ser válidas.

Para um documento mais rico, multipart/alternative permitia oferecer text/enriched ao lado de ODA ou outra representação. Um cliente escolhia alcance; outro, riqueza. Ambos recebiam o mesmo conjunto, mas não necessariamente liam a mesma parte.

O próprio RFC declarou não haver problemas de segurança nesse mecanismo. Trata-se da avaliação histórica do documento, não de uma prova sobre extensões posteriores, parsers, manipuladores MIME ou aplicações atuais. RFC 1563 tornou RFC 1523 obsoleto; RFC 1896 depois substituiu RFC 1563. A linhagem não prova retirada simultânea das implementações.

O conjunto de fontes não identifica nenhum leitor, implantação ou mensagem específica; também não mede adoção, resposta de usuários nem o resultado observado de uma entrada malformada. Ele documenta as regras e a linhagem, não o comportamento de uma instalação determinada.

Uma trilha responsável guarda bytes e charset, CRLF físicos, pilha analisada, decisões para comandos conhecidos e desconhecidos, parâmetros ocultos, alternativa escolhida, renderização e interpretação humana. A queda legível funcionava porque tornava certas perdas suportáveis, não porque eliminava a perda.

Fontes