Resumo

  • O RFC 1740, publicado em dezembro de 1994, descreveu como encapsular arquivos Macintosh em mensagens MIME. AppleSingle reunia o arquivo em um fluxo; AppleDouble separava o cabeçalho com informações específicas do Mac da parte de dados.
  • Para a maior parte dos arquivos que precisavam desse tratamento, o formato recomendado era multipart/appledouble, com um componente application/applefile e outro componente de dados identificado por seu próprio tipo MIME.

Dois garfos, um envelope

Em muitos sistemas, um arquivo é uma sequência de bytes e pronto. No Macintosh clássico, o arquivo tinha um data fork e um resource fork. O primeiro continha dados que outro computador em geral podia usar. O segundo podia guardar segmentos de programa, ícones e outros atributos. O Finder ainda registrava informação adicional. Mandar esse conjunto por uma rede de máquinas diferentes exigia um inventário: quais peças são dados acessíveis a todos, e quais são partes necessárias para que o Mac reconheça o objeto como foi criado?

O RFC 1740, assinado por Patrik Faltstrom, Dave Crocker e Erik E. Fair, aproveitou as capacidades do MIME definido no RFC 1521. O corpo de uma mensagem podia ser multipartes, com tipos de conteúdo próprios. Esse mecanismo criava uma saída para o dilema do anexo: preservar os detalhes do Macintosh e, ao mesmo tempo, apresentar os dados num formato que um destinatário de outro sistema pudesse abrir.

AppleSingle era a mala única. Conteúdo e atributos viravam um fluxo contínuo, enviado como application/applefile. A integridade do pacote ficava organizada sob uma única tampa. Para aproveitar apenas a parte de dados, porém, o leitor precisava entender o invólucro AppleSingle. Quem só tinha pedido uma fotografia recebia também a chave de uma caixa específica do Mac.

AppleDouble trocou a caixa por duas divisórias. O cabeçalho levava o resource fork e as informações de desktop; o data fork seguia separado. O MIME externo era multipart/appledouble, com exatamente duas subpartes. A primeira usava application/applefile. A segunda recebia um tipo que descrevesse os dados: image/gif no exemplo do RFC ou application/octet-stream quando faltasse um tipo registrado adequado. Um programa fora do Mac conseguia trabalhar com essa segunda parte. Um programa Mac encontrava as duas e reconstruía o arquivo com seus detalhes.

A recomendação tinha limites úteis. Se um documento possuía tipo MIME conhecido e resource fork inexistente ou trivial, podia seguir como uma parte MIME comum. Se não havia data fork, AppleSingle era o formato necessário. Nos outros casos, sobretudo com recursos relevantes ou dados sem tipo MIME estabelecido, AppleDouble era a escolha normal. A regra acompanha o conteúdo concreto do arquivo. Não obrigava uma imagem simples a passar pelo mesmo ritual de um documento carregado de recursos.

O velho transporte de correio ainda aparecia nas bordas. O fluxo binário do AppleSingle e o cabeçalho binário do AppleDouble podiam exigir codificação de transferência; Base64 era apresentado como a alternativa mais segura para canais restritivos. O RFC recomendava também o parâmetro name para indicar o nome do arquivo ao destinatário. A sintaxe de MIME mantinha esse valor preso ao US-ASCII de sete bits. Era possível transportar o corpo inteiro do arquivo e ainda esbarrar numa etiqueta de bagagem com pouco espaço para escrever.

Esse desenho distribuiu o trabalho de compatibilidade. O destinatário Mac preservava os elementos que seu sistema entendia; o destinatário de outra máquina recebia os dados como componente MIME autônomo. Separar as partes não as tornava rivais. O mesmo envelope conservava tanto a especificidade do objeto quanto a possibilidade de uso em outro ambiente.

O RFC 1740 tratava de tipos de conteúdo, cabeçalhos e codificação. Seu efeito editorial é mais fácil de ver na cena cotidiana de abrir um anexo. A boa embalagem deixava a fotografia ao alcance da mão e guardava ícones e recursos no bolso certo. O correio continuava com um envelope; o arquivo não precisava fingir que tinha uma única peça.