Resumo

  • A forma herdada era um Extended Body Part sem parâmetros, com dados OCTET STRING e OID mime-postscript-body; a forma recomendada era um FTAM Body Part identificado por id-mime-ftbp-postscript em sua application-reference.
  • Os dois mapeamentos para application/postscript diziam “sem conversão”. Isso preservava o payload, mas não certificava a identidade do portador, a capacidade do receptor, a adoção de FTAM, a execução segura ou a saída visual.

Uma transportadora pode trocar a embalagem sem tocar no conteúdo. O lacre do documento continua perfeito, mas o depósito de destino talvez não tenha a ferramenta para abrir o novo recipiente. Em sistemas de mensagens, esse detalhe separa integridade de interoperabilidade.

O RFC 2160, publicado em janeiro de 1998, tratou exatamente dessa separação ao ligar PostScript em X.400 e MIME. O documento manteve uma rota antiga e recomendou outra, sem fingir que a base instalada desapareceria no dia da publicação.

Dois portadores para um fluxo

A rota anterior vinha do RFC 1494. Seu Extended Body Part não tinha parâmetros, guardava um OCTET STRING e usava mime-postscript-body sob { mixer-bp-data 2 }. O texto antigo chamava a equivalência com application/postscript de Byte Copy.

No FTAM Body Part, a identidade era expressa em FileTransferParameters.environment.application-reference, com o valor id-mime-ftbp-postscript sob { mixer-bp-data 6 }.

Os identificadores ocupavam superfícies estruturais diferentes. Um receptor podia implementar o mecanismo legado e não o perfil FTAM, ou o contrário. A recomendação de FTAM era uma preferência arquitetônica, não um comprovante de implantação. Continuar documentando o EBP mostrava que a transição precisaria conviver com capacidades desiguais.

O RFC 2157 organiza separadamente Extended Body Parts, FTAM e equivalências MIME. O RFC 2156 estabelece o contexto de MIXER: serviço consistente entre gateways, preservação de informação e reversibilidade quando possível. Esses objetivos orientam implementações; não relatam o que aconteceu em uma mensagem específica.

O alcance exato de “sem conversão”

As duas tabelas do RFC 2160 marcam Conversion Type: No conversion. A justificativa é simples: cada representação contém um único fluxo de octetos, que pode ser copiado diretamente.

Se hashes calculados nos dois lados coincidem, há boa evidência de integridade do conteúdo. Ainda assim, o objeto externo mudou de um body part X.400 para um media type MIME. E, antes disso, o sistema precisava saber qual dos dois body parts X.400 estava presente.

Arquivar apenas o PostScript extraído preserva o programa, mas apaga a identidade do transporte. Sem o objeto original ou seus metadados, fica impossível provar se a passagem usou FTAM, o formato legado ou um fallback.

Conteúdo correto, execução recusada

O RFC 2160 apontava para o RFC 1521. O RFC 2046 explica que application/postscript carrega um programa e recomenda convenções DSC. Sem estrutura adequada, um sistema talvez não consiga prever se o documento funciona naquele ambiente e pode rejeitá-lo.

Há também risco de segurança. PostScript pode acessar arquivos, alterar estado persistente, mudar parâmetros, consumir recursos indefinidamente ou recorrer a extensões não padronizadas. Um leitor seguro pode desativar operações ou não executar o arquivo. Nesse caso, bytes intactos e ausência de saída convivem sem contradição.

O registro do RFC Editor e o registro do Datatracker confirmam a origem do documento. A busca de erratas não mostra correspondências atualmente. Nenhum desses registros comprova comportamento de produto.

A evidência deve subir por degraus

O primeiro degrau é o hash do payload. O segundo é a identidade X.400 observada. O terceiro é a matriz de capacidade dos destinatários. O quarto é a política do interpretador e seus motivos de recusa. O quinto é o resultado: página renderizada, impressão, quarentena ou falha.

A especificação inicial mínima de Heng Lu ajuda a manter identificadores e cópia na camada comum verificável. A primazia do código em execução pede medição daquilo que gateways realmente enviam e aceitam. As camadas da realidade impedem que um rótulo ou hash seja promovido a prova de experiência do usuário.

O mérito do RFC 2160 foi não complicar o payload. A disciplina posterior é não simplificar demais o restante. Igualdade de bytes é uma resposta precisa; suporte, migração, segurança e utilidade continuam sendo perguntas próprias.

Fontes