Resumo

  • Para a RFC 1431, localizar a entrada desejada, evitar outras correspondências e gastar poucas operações eram resultados independentes.
  • SearchStones davam pesos a Bind, Read, List e Search, mas os próprios pesos traziam marcas de Quipu, da replicação e da topologia observada.
  • Uso operacional e avaliação externa pública eram evidências separadas; a pontuação de uma consulta não autorizava conclusões sobre adoção ou superioridade geral.

A ficha certa não encerrava a auditoria

Paul Barker apareceu na tela. Para quem procurava seu contato, a tarefa podia ter terminado. Para quem avaliava o Directory User Agent, três perguntas apenas começavam: a entrada correta veio? Quantas outras vieram junto? Que trabalho o diretório realizou para produzir a resposta?

Essa decomposição está no centro da RFC 1431, “DUA Metrics”, publicada em fevereiro de 1993. O texto propunha critérios para agentes e interfaces de diretório, sobretudo no uso de páginas brancas. Pressupunha que a engrenagem protocolar estivesse correta e examinava o instrumento apresentado ao usuário.

Também rejeitava a ideia de um vencedor absoluto. Ferramentas diferentes atendiam públicos e finalidades diferentes. Uma interface textual, um cliente gráfico e um programa apoiado em acesso simplificado podiam cumprir promessas distintas. A palavra “melhor” precisava de complemento: melhor para qual pessoa, tarefa, conjunto de dados e ponto de partida?

O primeiro indicador da consulta era binário: o alvo foi encontrado. O segundo media seletividade pelo número de outras entradas retornadas. O terceiro abria a caixa da infraestrutura e contava as operações subjacentes. Um cliente que localizava Barker sozinho não equivalia a outro que o colocava no meio de dezenas de candidatos; tampouco duas telas iguais implicavam o mesmo custo distribuído.

SearchStones: uma contabilidade declarada

A RFC 1431 atribuiu cinco SearchStones a Bind, um a Read, dois a List, três a uma busca de nível único e cinco a uma busca de subárvore. Somar as operações ponderadas dava ao avaliador uma visão compacta do caminho escondido.

O total deveria aparecer mesmo quando a consulta falhasse. Essa orientação é decisiva: um resultado vazio não significa trabalho zero. Preservar o custo do fracasso permite distinguir uma tentativa curta e inteligível de uma exploração cara que não encontra o alvo.

Mas os pesos não eram leis naturais. O documento observava que o valor da busca de nível único devia algo à replicação generalizada entre irmãos na implementação Quipu. O ambiente já estava dentro da unidade. SearchStone era uma convenção útil e discutível, não um segundo, uma moeda ou uma propriedade universal da operação.

Por isso a correlação com tempo era apenas aproximada. Uma pontuação baixa costumava acompanhar resposta rápida, porém não de modo consistente. O número contava tipos de operação; não absorvia todos os fatores que determinavam duração ou experiência humana.

Dez testes, um homem, um servidor

O banco de provas continha dez variações de consulta, das diretas às mais difíceis, todas destinadas a achar a entrada do autor. A instrução sugeria conexão direta ao DSA cn=Vicuna,c=GB.

Há rigor nessa escolha. Um alvo conhecido permite confirmar o acerto. Alterar os indícios em torno da mesma identidade isola o comportamento do cliente diante de informação incompleta. Fixar o DSA reduz variação entre execuções.

O rigor não transforma a amostra em mundo. Uma pessoa não representa todos os nomes, escritas, organizações ou posições na árvore. A ligação direta ao DSA alvo não reproduz todo percurso de usuário. As dez consultas eram sondas controladas, não evidência estatística de desempenho global.

Quando o total sai do relatório, a aparência de precisão pode ocultar essas fronteiras. Para manter seu significado, ele precisa levar consigo o alvo, a expressão da consulta, os filtros, o ponto de conexão, os dados e a configuração de réplicas.

O chão se movia sob a métrica

O Directory Information Tree não tinha profundidade uniforme. Implementações de DSA apresentavam perfis diferentes, e a combinação delas mudava. Domínios adotavam estratégias de replicação com efeitos profundos. Além disso, os pesos não distinguiam complexidade de filtros nem combinações booleanas.

Cada condição age por um mecanismo próprio. Profundidade altera percurso. Implementação altera o esforço interno de uma operação nominalmente igual. Replicação aproxima ou afasta dados. O filtro altera computação sem necessariamente trocar o nome da operação. A rede acrescenta latência.

Assim, pontuações iguais podem produzir tempos distintos, e a menor pontuação pode não ser a resposta mais rápida. Uma estratégia otimizada para uma árvore com forte replicação pode perder vantagem em outra. A leitura honesta é: este cliente gerou esta sequência, com estes pesos, neste diretório.

Adoção não era consequência do placar

O questionário perguntava em outra parte quantas organizações usavam o produto operacionalmente. Também perguntava se alguém fora da comunidade de desenvolvedores ou fornecedores o havia avaliado e se essa avaliação era pública.

Essa separação bloqueava inferências indevidas. Um cliente pode ir bem no teste e não ter usuários reais. Pode ser muito usado e operar de forma cara. Uma análise do fornecedor não é independente por ser detalhada. Uma avaliação externa não é verificável se o método não está disponível.

A RFC 1430 colocava o problema numa escala maior: imaginava um diretório X.500 global, com atenção inicial a páginas brancas, X.509 e pilotos. Ao mesmo tempo, reconhecia que mapear dados existentes para uma estrutura coerente exigia mais trabalho operacional do que instalar servidores ou agentes. A infraestrutura social de coleta, delegação e manutenção era parte do sistema.

RFC 1202 e RFC 1249 registravam caminhos distintos de acesso por um serviço textual e por DIXIE; RFC 1274 fornecia o contexto de esquema. O DUA era a borda humana de um arranjo que incluía modelos de dados, servidores, réplicas e instituições.

Do teste à decisão, degrau por degrau

Primeiro alguém escolhe uma identidade e formula a consulta. O cliente parte de um local declarado e constrói filtros. DSAs e réplicas executam operações numa árvore específica. O alvo aparece ou não. Entradas extras vêm ou não. As operações recebem pesos. Mede-se o tempo. Uma pessoa avalia usabilidade. Organizações adotam. Terceiros examinam e talvez publiquem o método.

Nenhum degrau prova o próximo. Encontrar o alvo não prova precisão do conjunto, baixo custo, velocidade, adequação a outro público, implantação nem validação independente.

O mérito histórico da RFC 1431 é propor uma linguagem comum sem esconder a autoria dessa linguagem. Os pesos eram visíveis. O sujeito do teste tinha nome. O DSA era especificado. As omissões eram confessadas. A métrica não precisava fingir universalidade para ser útil.

Uma medida limitada pode revelar desperdício e apoiar comparação local. Ela se torna enganosa quando o contexto passa a ser rodapé descartável. Guardar consulta, topologia, traço, pesos e falhas permite reavaliar a validade no futuro. Guardar só o total faz um diretório particular falar como se fosse todos.

A RFC 1431 não discutiu segurança, não elegeu produto vencedor e não relatou o destino posterior de X.500. Seu objeto histórico é mais preciso: como tornar o trabalho observável sem deixar que uma conta criada por pessoas apague as condições de sua criação.

Fontes