Resumo

  • O RFC 1049 propôs Content-Type para corpos estruturados, como PostScript, TeX e TROFF. O texto continuaria dentro dos limites ASCII do correio da época; o leitor poderia escolher o processador de exibição.
  • A etiqueta admitia versão e referência a recursos auxiliares. Sem descoberta automática das capacidades do destino, o remetente guardaria sua própria lista de pessoas equipadas. O RFC 2045 depois generalizou o campo no MIME.

Uma entrega impecável pode terminar num desastre de leitura. Num correio eletrônico de 1988, um documento PostScript atravessava a rede com os caracteres intactos e aparecia na tela como instruções para uma impressora. O autor pensara em fórmulas e tipografia; o amigo recebeu o manual de montagem do espetáculo. O RFC 1049, publicado por Martin Sirbu em março daquele ano, tratou desse desencontro com uma proposta simples: o corpo deveria anunciar como queria ser interpretado.

O formato de mensagem do RFC 822 tinha cabeçalhos definidos e corpo em caracteres ASCII. Já circulavam nesse corpo TROFF, TeX, Scribe, SGML, DVI e PostScript. Eles cabiam nas regras de transporte, mas precisavam de processamento extra para virar a página pretendida. O novo Content-Type daria ao programa leitor um nome para escolher a ferramenta certa. O trajeto do e-mail transportaria os mesmos caracteres; a escolha da apresentação ficaria com quem abre a mensagem.

Sirbu imaginou uma etiqueta com detalhes úteis. O primeiro valor indicava o tipo, como POSTSCRIPT ou TROFF, e havia espaço para acordos privados sob X-. Em seguida podiam vir um número de versão, uma referência a recursos de interpretação e um comentário. O RFC citava versões do LaserPrep para PostScript e eqn, tbl e me para TROFF. Reconhecer o prato ajuda, mas a cozinha também precisa dos utensílios. A referência ao recurso deixava essa dependência visível no próprio envelope técnico da mensagem.

O custo escondido aparecia na ponta de chegada. Um leitor sem o interpretador ainda recebia o e-mail ASCII; sua tela podia simplesmente mostrar comandos crus. Como o remetente saberia quais pessoas tinham o equipamento certo? O RFC examinou três soluções. Sistemas emissores poderiam manter bases de capacidades remotas. O SMTP poderia negociar e transformar antes da entrega. Um diretório poderia publicar as capacidades dos destinos. A base exigia manutenção permanente; a negociação mexia em implementações existentes e encontrava limites nas rotas entre redes; o diretório puxava mais trabalho para o envio e o serviço de nomes.

Para experimentar logo, Sirbu escolheu a saída mais humana: cada remetente manteria uma lista particular dos formatos que seus correspondentes conseguiam ler. A mensagem ganharia um campo padronizado; a pessoa que a enviava ainda cuidaria da lista de convidados. O RFC também deixou ao software leitor a decisão sobre o que fazer com um campo válido. Identificar o formato, possuir o processador e mostrar a página eram etapas separadas.

O vínculo posterior está escrito no RFC 2045: o Content-Type do MIME generalizou o campo do RFC 1049. Vieram tipo e subtipo de mídia, parâmetros e companheiros como MIME-Version e Content-Transfer-Encoding. O texto de 1996 descreveu a sintaxe antiga como mais simples e amplamente compatível. O episódio de 1988 tem sua própria graça: o correio aprendeu a dizer o que carregava antes de aprender a perguntar se o destinatário podia aproveitá-lo.

A etiqueta poupou o leitor de adivinhar o formato olhando para uma tela cheia de instruções. A pergunta maior ficou à vista: quem possui o interpretador, a versão e o pacote de recursos? Por algum tempo, a base de compatibilidade mais importante morou na cabeça de quem apertava “Enviar”.