Summary

  • A RFC 769 descreveu um arquivo para dados de fax Rapicom 450, permitindo a organizações com equipamentos compatíveis trocar páginas armazenadas por transferência de arquivos e outros protocolos.
  • O arquivo separava preparação, dados e fim. Os blocos de 585 bits permaneciam codificados pelo aparelho, e reconstruir a imagem exigia conhecer seu procedimento de decodificação.

Uma folha entra no aparelho de fax, sai como dados e começa a viajar pela rede. Em setembro de 1980, essa sequência precisava de instruções bem mais concretas do que «anexe o documento». Algumas organizações da comunidade ARPA Internet já tinham máquinas Rapicom 450 ligadas a computadores. Jon Postel registrou na RFC 769 como guardar as páginas em arquivos para que outras instituições com dispositivos compatíveis participassem da troca.

O arquivo era a ponte, não o tradutor. A máquina produzia blocos codificados de 585 bits por meio de um esquema próprio. O computador podia armazenar e transmitir esses blocos. Para transformar o conteúdo em imagem, o receptor ainda precisava do método de codificação e decodificação usado pelo Rapicom 450. A RFC foi direta nesse ponto: os blocos não eram um mapa de bits pronto para qualquer programa. A encomenda chegava à porta; o desenho dentro dela falava a língua do equipamento.

Postel especificou a parte compartilhável dessa encomenda. Cada registro começava com um byte de comprimento, depois um byte de comando, seguido dos dados. O comprimento incluía os dois primeiros bytes. Três comandos bastavam para marcar o caminho: 56 para SET-UP, 57 para DATA e 58 para END. O END final podia conter somente os dois bytes do cabeçalho. Assim, mesmo antes de decodificar a página, um programa podia reconhecer preparação, corpo e término do arquivo.

A preparação trazia uma economia curiosa. Em operação, o aparelho transmitia ou recebia várias cópias idênticas do bloco SET-UP. No arquivo, uma cópia era suficiente. O formato não reproduzia todos os gestos da máquina; guardava a representação necessária para outra máquina compatível. Repetição no dispositivo e conteúdo persistente no arquivo tinham tarefas diferentes.

Havia ainda uma conta que não fechava de primeira: 73 bytes contêm 584 bits, um a menos que o bloco do Rapicom. Por isso o campo de dados ocupava 74 bytes. Somados os bytes de comprimento e comando, o registro comum tinha 76 bytes. Nos arquivos trocados até então, segundo a RFC, cada registro trazia um bloco; SET-UP vinha primeiro, DATA no meio, END no fim. Uma diferença de um bit parece mínima até deslocar todo o restante da página. A engenharia de documentos também vive de aritmética miúda.

O texto anotava uma marca de sincronização de 24 bits no começo do bloco e dois bits de sequência que percorriam quatro valores nos blocos DATA. Essas marcas ajudavam a conservar e reconhecer a estrutura vinda do aparelho. Não substituíam o decodificador da imagem. O protocolo de rede movia o arquivo; o leitor do arquivo encontrava os registros; o Rapicom convertia os blocos codificados em algo que pudesse voltar ao papel. Cada etapa tinha uma chave diferente.

O convite de 1980 era para quem possuía equipamento compatível. Anos depois, a RFC 1314 de 1992 documentou TIFF-B como formato autônomo para imagens semelhantes a fax trocadas pela Internet. O contraste é revelador: a primeira proposta organizava os dados de uma família de dispositivos; a segunda buscava uma linguagem de imagem mais geral. A evolução do objetivo mostra exatamente onde terminava a ponte construída por Postel.

O episódio é uma boa lembrança da Internet quando «mandar a página» ainda envolvia várias profissões. O fax capturava, o computador empacotava, a rede transportava, o equipamento do outro lado interpretava. A conquista foi fazer a folha viajar como dados. O detalhe prático, que qualquer recepcionista perceberia, era ter a máquina certa esperando na outra sala.