Resumo

  • RFC 1959 reuniu em uma URL a localização do servidor LDAP, o nome distinto, os atributos pedidos, o escopo e o filtro; a omissão de campos ativava valores padrão de construção.
  • O host podia faltar e não havia campo para credenciais. A mesma URL podia chegar a servidores, sessões e políticas de acesso diferentes.
  • A string orientava uma busca, mas não provava o servidor escolhido, os dados autorizados, o término correto do resultado nem a ação do sistema consumidor.

A pergunta ganhou uma embalagem portátil

Em 1996, LDAP era apresentado como acesso leve ao diretório X.500. RFC 1959 procurou dar acesso direto ao protocolo a clientes da Internet e declarou que o formato também serviria a servidores LDAP independentes. A URL conectava um meio de transporte conhecido a um sistema de diretório que mantinha suas próprias regras.

A ordem dos componentes era fixa: ldap://, host e porta opcionais, uma barra com o nome distinto e, depois, campos de atributos, escopo e filtro separados por pontos de interrogação. O host localizava um servidor; o nome distinto escolhia a base; os atributos expressavam o que retornar; o escopo delimitava base, um nível ou subárvore; o filtro selecionava entradas.

O filtro já tem sua própria história em RFC 1558, como predicado legível e executável. Aqui o objeto é outro: o envelope que levava esse filtro junto com os demais parâmetros. O filtro não decidia o servidor nem o acesso, e a URL não eliminava a gramática interna do filtro.

Campos vazios executavam padrões

Sem porta, RFC 1959 usava TCP 389. Sem atributos, o cliente pedia todos. Sem escopo, buscava o objeto base. Sem filtro, aplicava (objectClass=*). Esses padrões completavam a pergunta; não descreviam o estado do diretório.

Pedir todos os atributos não afirmava que todos existiam ou eram públicos. O filtro padrão não confirmava identidade, atualidade ou permissão. A base informada podia não existir. O servidor ainda precisava processar a solicitação e aplicar suas regras.

O exemplo de subárvore da Universidade de Michigan mantinha o campo de atributos vazio com dois pontos de interrogação consecutivos. A ausência era proposital para que sub e o filtro ocupassem as posições seguintes. Logo, uma trilha de auditoria precisa registrar tanto o que estava escrito quanto os padrões ativados pelo que não estava.

O nome distinto e o filtro também preservavam sintaxes internas, enquanto caracteres impróprios para URL eram codificados conforme RFC 1738. A errata verificada 528 corrige a referência do DN para RFC 1779. A codificação percentual permitia transporte; não tornava o nome canônico, o filtro seguro ou o valor verdadeiro.

A falta de host mantinha a escolha fora da string

Uma URL iniciada por ldap:/// não nomeava servidor. RFC 1959 dizia que, se a entrada pertencesse ao espaço X.500, o cliente poderia consultar qualquer servidor LDAP com acesso de retaguarda a X.500.

A referência ficava menos presa a uma máquina, mas não documentava qual máquina foi escolhida, qual réplica ou visão ela ofereceu, se estava acessível ou em que instante respondeu. “Qualquer” não era “todos” nem um selo de autoridade global.

RFC 2255 tornou a divisão mais explícita em 1997. Sem host, o cliente precisava conhecer de antemão um servidor apropriado. Ele podia abrir ou reutilizar uma conexão, escolher segurança e autenticação e preencher campos ausentes da URL, inclusive limites de tamanho e tempo e política de alias.

Essas explicações posteriores não devem ser projetadas para dentro de RFC 1959. O formato de 1996 não carregava algoritmo de seleção, histórico da conexão, limites de execução ou decisão sobre aliases.

A URL não continha credenciais

RFC 1959 não oferecia forma de indicar credenciais e, por isso, esperava consultas não autenticadas. Uma busca anônima pode ser deliberadamente permitida para dados públicos. Isso não equivale a um direito de receber tudo o que foi solicitado.

O padrão de todos os atributos descrevia a seleção do cliente. O servidor continuava aplicando controle de acesso e restrições administrativas. RFC 4511 explicaria mais tarde que uma entrada retornada pode conter poucos atributos ou até nenhum valor.

Duas pessoas com a mesma URL também não passam a ter a mesma identidade. Uma sessão anônima, outra autenticada e uma política alterada podem gerar visão pública, visão ampliada ou erro. A divergência pertence ao contexto de execução.

O resultado vinha depois da pergunta

RFC 4511 descreve zero ou mais entradas e referências, seguidas por SearchResultDone com sucesso ou erro. RFC 1959 não transformou essa sequência em parte da URL nem congelou um retrato do diretório.

Guardar a URL prova a pergunta pretendida. Não prova que os mesmos dados foram avaliados mais tarde, que limites não interromperam a busca, que referências foram seguidas ou que a resposta final chegou com sucesso.

Uma entrada recebida também não prova totalidade. Ela registra o que um servidor entregou a um cliente num ponto da sequência. O sistema consumidor ainda decide se aquilo basta, se uma ausência é significativa, se deve seguir referências e qual ação é justificável.

RFC 4516, norma atual para LDAPv3, ressalta que nem todos os parâmetros de SearchRequest cabem no formato. A URL continua menor que a operação e muito menor que a decisão.

Pela lente da especificação inicial mínima de Heng Lu, essa modéstia é uma virtude: uma superfície comum pequena pode facilitar coordenação sem adquirir poder permanente. Running-Code Primacy exige evidência distinta para a string, interpretação, conexão, mensagens e ação.

RFC 1959 fez a pergunta viajar. Não tornou a pergunta soberana.

Fontes e limites

A identidade do documento está no IETF Datatracker e na página informativa do RFC Editor. O texto original aparece em HTML e texto simples; a errata 528 corrige a referência do DN. O contexto vem de RFC 1777, RFC 1558 e RFC 1738. Os limites posteriores estão em RFC 2255, RFC 4511 e RFC 4516.

A leitura editorial usa Running-Code Primacy, Minimum Initial Specification e Reality Layers de Heng Lu. Esses ensaios não são prova de implantação LDAP.

As fontes demonstram as especificações e seus limites declarados, não adoção atual, conformidade de produto, conteúdo real de diretório, incidente, política de acesso ou decisão de aplicativo.