Resumo

  • Mary Ann Horton ajudou a organizar o UUCP Mapping Project, no qual administradores declaravam vizinhos, responsáveis regionais corrigiam os dados e cada site calculava suas rotas de correio.
  • O projeto prova que um mapa operacional depende de procedência, incentivos, limites de divulgação e autoridade para encerrar o serviço quando a atualização termina.

O endereço duke!research!ucbvax!user não dizia apenas quem receberia a mensagem. Ele ordenava as máquinas pelas quais o arquivo inteiro deveria passar. Cada ponto de exclamação pressupunha que o próximo computador continuava disponível, sabia encaminhar e estava disposto a telefonar.

O trabalho de Mary Ann Horton tornou esse conhecimento menos dependente da memória individual. Não eliminou os limites da rede discada; transformou-os em dados que uma comunidade podia manter e um programa podia interpretar.

O desenho ficou menor que a rede

Horton contou à USENIX que distribuiu mapas lógicos da Usenet em 1982 e 1983. As pessoas os usaram para endereçar correio, embora a rede de notícias e a malha UUCP de email não fossem idênticas. Uma conexão omitida podia deslocar tráfego para os poucos sites dispostos a retransmitir.

Em 1984, o desenho estava ramificado demais. Horton levou um mapa geográfico; Bill e Karen Shannon produziram uma versão lógica de oito páginas. O aumento do papel deixava claro que a dificuldade era manter a informação entre edições, não escolher uma projeção melhor.

Havia ainda a conta telefônica. Algumas universidades não autorizavam chamadas interurbanas. Centros empresariais conseguiam bancar tráfego alheio. Frequência, velocidade e confiabilidade variavam. Uma aresta existente não representava automaticamente uma rota econômica ou pontual.

Manutenção regional, publicação comum

Uma sessão informal da USENIX em Washington, em janeiro de 1984, organizou o UUCP Mapping Project. Voluntários assumiram regiões, recolheram descrições dos sites, conciliaram inconsistências e publicaram atualizações em comp.mail.maps.

Os números pertencem a fases diferentes. O museu Stargate fala em mais de trinta voluntários recrutados no encontro inicial. A página de realizações de Horton registra uma equipe de cerca de cinquenta. Relatos que abrangem toda a vida do projeto incluem um círculo regional maior. Nenhum deles autoriza um total único.

As memórias também distribuem a liderança de formas distintas. Horton afirma ter convocado a reunião e conduzido a criação. Um rascunho de encerramento de 2000 credita a liderança inicial financiada pela USENIX a Karen Summers-Horton e situa Horton na operação a partir de 1985. A divergência reforça o caráter coletivo e deve permanecer atribuída.

RFC 850 definiu um limite essencial. O pedido senduuname podia reunir nomes de vizinhos para o mapa e permitia que o administrador editasse a resposta. Números telefônicos, senhas e o arquivo privado de discagem não podiam ser publicados. Descoberta exigia adjacência; segurança exigia não confundi-la com credenciais.

O menor custo era uma escolha humana

Steve Bellovin e Peter Honeyman escreveram pathalias. O programa lia um grafo dirigido, atribuía custo não negativo e operador de roteamento a cada ligação e pré-calculava caminhos a partir do site local com uma variação do algoritmo de Dijkstra.

O custo reunia critérios diferentes: tarifa telefônica, frequência das chamadas, velocidade, confiabilidade e preferência de operadores experientes. Uma empresa e uma universidade avaliavam a mesma ligação de modos diferentes. O tempo de estabelecer a chamada e de aguardar o próximo ciclo podia pesar mais que a velocidade nominal.

Os dados também traziam incerteza. O artigo de pathalias relata entradas incompletas, contraditórias e erradas. Mapas inferidos da Usenet subestimavam conexões. O software às vezes deduzia uma aresta de retorno para alcançar um host e aplicava heurísticas a domínios e gateways. Uma otimização podia até apagar o desvio manual usado para contornar uma linha morta.

Assim, a tabela não era uma fotografia universal. O mapa compartilhado fornecia afirmações; cada execução aplicava uma política local de custo. Horton e Adam Buchsbaum trabalharam no smail, que usava essas tabelas para entregar o correio sem obrigar o usuário a decorar todo o bang path.

Um nome estável sobre caminhos mutáveis

Em “What Is a Domain?”, Horton explica que os pontos do domínio não formam um roteiro. O domínio é um nome absoluto numa hierarquia administrativa. Uma tabela, um resolvedor ou um gateway ainda precisa escolher o próximo salto.

RFC 819 associa o domínio à autoridade de nomeação e à responsabilidade de tradução. RFC 920 diz que domínios são entidades administrativas, sem obrigação de compartilhar geografia, topologia, protocolo, hardware ou software.

No relato de Horton, o projeto UUCP participou com BITNET, CSNET e a comunidade ARPANET da adoção do espaço comum em 1986. Sua página de realizações menciona mais de 150 organizações UNIX sem conexão direta atendidas por email .com ou .edu entre 1986 e 1988. É um número retrospectivo da protagonista, não uma contagem independente deste artigo.

RFC 976 mostra a transição sem ruptura. Em vez de criar mais um formato incompatível, adotou padrões de domínio e mensagem existentes, classificou hosts por capacidade e exigiu que gateways entendessem a forma mais completa. O usuário escrevia user@domain; uma tabela continuava a converter o nome em saltos UUCP.

RFC 974 acrescentou a indireção dos registros MX. O administrador podia indicar trocadores preferenciais e alterar o banco para evitar um host defeituoso. O nome simples não aboliu o trabalho: transferiu-o para uma infraestrutura compartilhada.

O fim também precisava ser publicado

O rascunho de conclusão informa que a base foi congelada em agosto de 2000 porque os mapas já não eram amplamente usados. Ele alerta que dados antigos poderiam perder ou entregar incorretamente o correio. Como não virou RFC, vale como registro do próprio projeto, não como padrão aprovado.

Uma cópia preservada não é um registro operacional. A autoridade só continua enquanto pessoas identificadas recebem mudanças, resolvem disputas, indicam a idade dos dados e anunciam quando o mapa não deve mais orientar tráfego.

Sistemas modernos descobrem topologia com outra velocidade. Ainda precisam responder às perguntas que Horton ajudou a institucionalizar: quem afirmou a ligação, quem suporta seu custo e quem tem autoridade para retirar uma visão obsoleta?

Fontes

  1. Wikimedia Commons: retrato de Mary Ann Horton em 2012
  2. Conclusão do UUCP Mapping Project, Internet-Draft
  3. Perfil da UC Berkeley EECS
  4. Mary Ann Horton: realizações
  5. Mary Ann Horton: história da Internet
  6. Stargate Internet Museum: o projeto UUCP
  7. Stargate Internet Museum: UUCP e email
  8. Pathalias: The Care and Feeding of Relative Addresses
  9. Mary Ann Horton: What Is a Domain?
  10. RFC 1036: intercâmbio de mensagens USENET
  11. RFC 819: convenção de nomes de domínio
  12. RFC 850: intercâmbio de mensagens USENET
  13. RFC 920: requisitos de domínios
  14. RFC 974: roteamento de email e o sistema de domínios
  15. RFC 976: formato de intercâmbio do email UUCP
  16. Entrevista da USENIX com Mary Ann Horton