Resumo

  • O CLDAP reduziu o custo de conexão para consultas pequenas a diretórios com UDP e um conjunto limitado de operações, mas deixou confiabilidade, tentativas e atualidade das respostas nas mãos de cada implantação.
  • A RFC 3352 não apontou uma causa única: registrou um conjunto de razões prováveis — sobretudo a falta de integridade e confidencialidade — e recomendou mover a RFC 1798 para Historic enquanto a experimentação continuava.

Uma consulta mais rápida, uma promessa mais estreita

A RFC 1798 partiu de uma pergunta prática: por que estabelecer uma conexão e uma sessão completas para ler poucos atributos de uma única entrada? O CLDAP reutilizou estruturas de mensagem do LDAP, mas transportou mensagens por UDP ou outro meio sem conexão e ofereceu um conjunto menor de operações. O exemplo do RFC descreve uma consulta em quatro pacotes, reduzida a dois em algumas condições locais ou com cache. É uma sequência ilustrativa, não um benchmark.

O documento descreveu o CLDAP como complemento a DAP e LDAP, não como substituto geral. Como datagramas podem se perder, o cliente precisava escolher seus próprios tempos de espera e tentativas. A RFC não impôs um algoritmo único. O servidor podia usar cache para reduzir a demora, mas o caminho via DAP não tinha protocolo de invalidação de cache nem o controle dontUseCopy. A rapidez transferia decisões de confiabilidade e de quanto dado antigo era aceitável para implementações e operadores. RFC 1798

A fronteira de segurança era ainda mais direta: o CLDAP não fornecia autenticação das solicitações. Uma nota editorial na RFC 1798 registra que se discutiu adicionar credenciais, mas o custo poderia anular a vantagem do modo sem conexão. O texto conclui que uma aplicação que exige acesso autenticado ao diretório não deve usar CLDAP. O compromisso estava explícito desde a primeira especificação; não foi uma descoberta posterior.

O que a RFC 3352 registrou

Publicada em março de 2003, a RFC 3352 revisitou a RFC 1798, de junho de 1995. Ela afirmou que o CLDAP não havia se disseminado amplamente na Internet durante os sete anos seguintes. Essa é a avaliação contemporânea do autor do RFC, não um censo de instalações, a prova de que não existia implementação alguma ou uma medição da utilização atual.

A lista apresenta razões prováveis, não uma ordem causal comprovada: acesso anônimo e somente de leitura, resultados pequenos, ausência de proteção de integridade e confidencialidade, internacionalização inadequada, extensibilidade insuficiente e falta de múltiplas implementações independentes. As limitações se acumulam. Uma consulta simples pode ter valor, mas uma interface difícil de proteger, ampliar e interoperar tem menos chance de sustentar um contrato compartilhado. A RFC não demonstra qual falha pesou mais nem se todas afetaram cada implantação. RFC 3352

Havia também um problema de manutenção documental. A RFC 3352 observa referências normativas a especificações obsoletas, entre elas textos antigos do X.500 e a RFC 1487. Sem atualização, essas referências impediam a RFC 1798 de continuar no Standards Track. O grupo LDAP Extensions, criado em 1997, estava encerrando sem atualizar o CLDAP; naquele momento não restava um esforço de padronização para fazê-lo.

A recomendação foi mover a RFC 1798 para Historic, não publicar um protocolo sucessor. A RFC 3352 reconhece interesse contínuo no acesso sem conexão, mas diz que a experiência operacional apontava para a necessidade de novos experimentos, especialmente em segurança. Menciona um rascunho de LDAP sobre UDP como trabalho em andamento, não como padrão substituto. A mudança de status do LDAPv2, especificado na RFC 1777, foi uma ação separada, registrada na RFC 3494. A RFC 3352 trata de CLDAP, não de aposentar todo o LDAP. Documentos posteriores de LDAPv3 fornecem outro contexto técnico, mas não provam o que os produtos CLDAP executavam.

Historic não é comando para apagar código

Historic descreve a posição de um documento no registro de padrões. Por si só, não desinstala um servidor, não invalida uma instalação local antiga nem prova que todos os operadores deixaram de usar a interface. A RFC 3352 recomenda uma mudança de status e afirma que a retirada não afetaria a segurança da Internet. Essa última frase é a avaliação de seu autor, não prova de que o CLDAP fosse seguro ou de que nenhum uso local tivesse riscos.

O episódio é sobre ciclo de vida, não apenas sobre um protocolo antigo. O CLDAP reduziu um custo visível — abrir uma conexão — mas deixou em aberto proteção, perda, atualidade, tamanho dos resultados e evolução. O registro da época não apontou um caminho viável de revisão nem uma base suficiente de implementações independentes para sustentar o padrão. A mudança de status tornou esse limite legível, sem transformar recomendação em adoção ou ordem universal de desligamento.

As ideias de Heng Lu sobre especificação inicial mínima e primazia do código em execução aparecem aqui como lente editorial declarada, não como conclusão do IETF. Elas ajudam a separar o que a RFC 1798 especificou, o que a RFC 3352 disse que a comunidade havia aprendido e o que um operador específico talvez continuasse executando. O material não informa número de instalações, comportamento de produtos ou datas de migração; não cabe inventá-los.

Fontes

Registro principal: RFC 3352, RFC Editor e Datatracker; protocolo original e contexto: RFC 1798, RFC Editor, RFC 1777, RFC 3377, RFC 3494, RFC 4510, RFC 4511, RFC 4513 e RFC 2026. Lentes editoriais atribuídas: Heng Lu, Note 64 e Note 65.