Resumo

  • A RFC 784 descreveu um distribuidor de mensagens para TOPS20 que escolhia a saída de acordo com a capacidade do host: MTP por TCP, MTP por NCP, FTP por NCP ou uma rota especial.
  • A RFC 785 definiu dois arquivos para cada mensagem: um com o texto e outro com remetente, destinos e a referência ao texto. O segundo podia ser alterado conforme cada destinatário saísse da fila ou precisasse esperar.

Mandar a mesma carta para quatro pessoas exige uma carta e quatro endereços. Sistemas de correio mais antigos às vezes criavam quatro cópias do texto. Suzanne Sluizer e Jon Postel propuseram outro método em julho de 1981. Na RFC 784 sobre a implementação de MTP no TOPS20 do ISI, a mensagem ficava em um arquivo e o trabalho de distribuí-la em outro. A carta permanecia legível; a ficha ao lado levava as rasuras da viagem.

O ambiente tinha várias estradas. A implementação em construção, escrita em BLISS-10, usaria TCP e o NCP anterior para enviar e receber, além de conversar com outros sistemas de correio. Programas de composição e receptores de rede criavam arquivos nos diretórios de usuário. Um distribuidor em segundo plano escolhia os canais de saída; uma versão acionada pelo próprio usuário podia tentar a entrega imediata quando o canal estivesse disponível. A tabela de capacidades registrava se o destino aceitava MTP por TCP, MTP por NCP ou o método antigo de FTP por NCP.

Outra tabela tratava casos especiais, como o sistema feito pela UCL para encaminhar mensagens a hosts na Inglaterra.

Um destinatário podia avançar enquanto outro esperava. O arquivo de controle guardava as informações de entrega e apontava para o arquivo de dados, que continha a mensagem com o cabeçalho RFC 733. Ao servir uma pessoa, o distribuidor podia marcá-la ou retirá-la da lista no controle. Se outro canal estivesse indisponível, o destino correspondente continuava pendente. O texto era lido nas tentativas e acabaria renomeado ou removido ao fim do processamento local. O que mudava a cada passo era a tarefa do distribuidor. Fazia sentido guardar essa tarefa numa folha separada.

A RFC 785, que definiu os arquivos, mostrou a folha linha por linha. FILE: indicava o nome completo do arquivo de texto; FROM: trazia o caminho do remetente; cada TO: acrescentava um caminho de destino. No outro arquivo ficavam cabeçalho e corpo. Os autores compararam o par com programas anteriores que produziam N cópias do texto para N nomes em To, Cc e Bcc. A interface nova começava com dois arquivos independentemente do tamanho da lista. Endereço no cabeçalho e trabalho de entrega tinham empregos diferentes.

Havia também a fronteira com outro sistema. A RFC 786 explicou a troca de arquivos entre MTP e NIMAIL e deu exemplos da conversão entre endereços com sinais de porcentagem e caminhos MTP. Uma mensagem atravessava tanto modos de transporte quanto convenções de endereço. O distribuidor precisava saber por onde sair e como escrever o destino para a próxima máquina.

Sluizer e Postel contaram quais peças estavam construindo, quais esperavam ver adaptadas por outros programas e quais tabelas ainda criariam. A RFC 784 registrava um plano concreto de implementação; a RFC 785 detalhava seu contrato entre arquivos. O ganho proposto é fácil de visualizar: o andamento de cada destinatário passa a ter sua própria linha. Uma estrada fechada não exige que todos voltem ao início.

É uma cena de agência postal. Uma carta está sobre a mesa; ao lado, uma ficha indica nomes, rotas e quem ainda aguarda. Em 1981, as portas tinham nomes como TCP, NCP e FTP por NCP. Se uma não abria, sua linha permanecia na ficha enquanto as outras podiam seguir. Dois arquivos faziam o trabalho de uma mesa de triagem muito cuidadosa.