Resumo

  • A RFC 1107 propôs três etapas para um serviço White Pages da Internet e do National Research Network. Ela afirma expressamente que o plano não era uma atividade de pesquisa comprometida pela comunidade.
  • A primeira etapa compararia arquiteturas em testes limitados; a segunda partiria dos resultados para implementar o serviço; a terceira prepararia a implantação ampla. Qualidade dos dados, controle do espaço de nomes, permissões e clientes continuavam como tarefas centrais.

Encontrar um nome numa lista telefônica é simples quando alguém já cuidou de coletar, conferir e atualizar as informações. O diretório “White Pages” imaginado pela RFC 1107 levaria essa obrigação para as redes de pesquisa: permitiria localizar pessoas e dados úteis para contatá-las, como caixas de correio eletrônico, calendários ou servidores de arquivos. “Yellow Pages” designava outra busca, por recursos da rede identificados por atributos. A proposta, portanto, não era apenas adicionar pessoas à lista de nomes de máquinas.

Karen Sollins publicou “A Plan for Internet Directory Services” em julho de 1989, relatando uma reunião de dois dias realizada em fevereiro. Um grupo pequeno reuniu perspectivas acadêmicas, comerciais e governamentais. Os participantes consideraram possível oferecer o serviço em três anos, desde que houvesse financiamento e estímulo suficientes. O status da RFC delimita essa conclusão: era uma proposta para debate, sem compromisso de pesquisa da comunidade da Internet. O calendário não comprova aprovação de orçamento, início do projeto nem entrega de um diretório.

Por isso, o plano começava sem escolher definitivamente a arquitetura. X.500 parecia o candidato mais provável por sua semântica rica e pela expectativa de se tornar um padrão internacional. Mas o texto via lacunas na especificação e receava a rigidez de uma hierarquia única. A primeira fase deveria comparar pelo menos uma implementação X.500 — Quipu era a opção considerada madura o suficiente naquele momento — com Profile e DNANS, serviço de nomes da DEC. Profile permitia nomes descritivos numa estrutura não hierárquica; DNANS havia projetado soluções para controle de acesso, replicação e cache.

Uma segunda implementação X.500 ajudaria a descobrir se um problema estava no padrão ou em um programa específico.

Os ensaios precisariam de uma base comum. A RFC sugeria um formato único para os dados de entrada e ferramentas compartilhadas de gestão, permitindo executar serviços diferentes sobre registros comparáveis. O experimento deveria tratar de coleta e correção das informações, distribuição e replicação, permissões de leitura e escrita, integridade, carga, interfaces e suporte a várias pilhas de protocolos. O plano favorecia uma comunidade inicial menor e familiarizada com o assunto; para DNANS, indicava um ambiente que já usaria DECnet. Essa cautela podia gerar aprendizado sem pressupor que todas as organizações aceitariam as mesmas regras.

As projeções de escala mostram a distância entre um protótipo e um serviço nacional. O documento estimava dez milhões de usuários em ciência e pesquisa, dez buscas semanais por pessoa, 10^8 buscas por semana — cerca de 170 por segundo em média, com picos bem maiores — e capacidade para pelo menos 10^7 entradas. São hipóteses de planejamento, não métricas de operação. A RFC via uma solução distribuída com vários servidores como necessária para lidar com picos e crescimento. Também alertava que buscas amplas poderiam ficar mais caras à medida que o sistema crescesse.

Cache, distribuição dos registros e ritmo das atualizações mudariam a carga; contatos desatualizados tornariam o diretório inútil, ainda que o sistema respondesse corretamente.

O cronograma reservava aproximadamente o primeiro ano aos testes, o segundo à implementação e o terceiro à implantação ampla. As etapas, contudo, deveriam começar o quanto antes e correr em paralelo. A implementação poderia escolher uma das arquiteturas ou combinar seus pontos fortes, além de criar servidores confiáveis e interfaces para pessoas e programas em equipamentos diversos. A reunião não detalhou a terceira fase.

Para implantar, ainda seria preciso reunir e manter informações, posicionar servidores, distribuir e ensinar o uso dos clientes, administrar o serviço e delegar autoridade sobre partes do espaço de nomes e sobre o conteúdo ali guardado.

Esse trabalho de gestão não era um apêndice. Quem poderia criar uma ramificação para uma organização? Quem controlaria o servidor responsável, corrigiria uma ficha ou restringiria a leitura de dados de funcionários? A RFC reconhece que algumas organizações não aceitariam delegar a terceiros a autoridade sobre seus nomes, e que pessoas ou empregadores poderiam limitar o acesso a informações pessoais. Ao mesmo tempo, o valor do diretório dependia de encontrar pessoas além da própria instituição. A interoperabilidade pedia coordenação; a confiança exigia registros atualizados e controle local sobre dados sensíveis.

A RFC 1107 registra uma proposta de planejamento, não a prova de uma entrega. Sua contribuição foi organizar a incerteza em etapas e tratar coleta de dados e autoridade sobre nomes como parte do projeto técnico. O horizonte de três anos só faria sentido se houvesse responsáveis, recursos e resultados de avaliação para cada fase. O documento não apresenta esse histórico de execução.

Fontes