Summary

  • A RFC 2377 propôs componentes dc derivados do DNS e valores uid existentes para evitar outro registro global, mas avisou que um UID parecido com e-mail podia não ser uma caixa válida; era preciso consultar mail.
  • O domínio do UID podia divergir do caminho do DN, DNs iguais podiam existir em servidores independentes e o DN sozinho não localizava nem autenticava um serviço LDAP.

Usar a coordenação que já existia

O X.500 oferecia hierarquia e delegação, mas sua tradição de nomes por país, região, razão social e nome comum criava registros pesados e colisões. Publicada como Informational em 1998, a RFC 2377 sugeriu um plano voluntário: transformar acme.com em dc=acme,dc=com e usar uid ou cn nas folhas.

DNS, números de empregado, handles e identificadores RFC 822 já tinham escopos administrativos. Reutilizá-los evitava uma segunda autoridade mundial. O plano não os convertia em identidade universal nem prometia uma única árvore global.

A arroba não provava entrega

Para pessoas, o memorando considerou conveniente selecionar um endereço “distinguished” como UID. Era reconhecível e podia ser estável. Porém algumas organizações atribuíam esse formato a todos, mesmo quando uma parte não possuía caixa real.

Por isso a regra foi direta: aplicações não deviam presumir que uid era um mailbox; deveriam verificar mail. O UID selecionava uma entrada. mail fazia uma afirmação de contato. SMTP produziria evidência posterior sobre rota e entrega. Autenticação e autorização continuavam separadas.

Os dois domínios podiam se afastar

uid=external-mailbox-shaped-identifier podia aparecer sob dc=mis,dc=acme,dc=com. O DIT poderia refletir controle de acesso ou partição, enquanto o UID preservava um identificador externo. Reorganizar o diretório não obrigaria uma troca de endereço.

Logo, software não podia montar o DN a partir do texto depois de arroba, nem deduzir o mailbox atual pelo DN. Os dc concatenados tinham de formar um domínio registrado para evitar conflitos no plano. Isso não autenticava servidor LDAP, organização ou pessoa.

O DN não era endpoint

A RFC 2247 definiu a conversão reversível entre domínio e DN composto de dc, mas excluiu o método para localizar o servidor LDAP. Também alertou que um servidor não confiável poderia alegar contextos não delegados.

A RFC 2377 imaginava ilhas frouxamente acopladas: referrals conectavam servidores que compartilhavam namespace; uma URL LDAP acrescentava host e porta ao DN para atravessar ilhas. Operadores independentes ainda podiam manter objetos diferentes com o mesmo DN para o mesmo sujeito real.

Nomear também não era buscar. uid podia construir o RDN, enquanto cn continuava importante para descoberta e exibição. Nomes DNS públicos ainda podiam revelar pistas sobre ramos escondidos por ACL.

A RFC 4519 depois tornou definitivas as definições de uid, dc, dcObject e uidObject. Ela esclareceu schema, sem transformar UID em caixa postal, credencial ou identidade autenticada.

Reutilizar sem promover significado

Pela disciplina de camadas de Lu Heng, delegação DNS, DN estruturado, string visível, UID, mail, URL LDAP, resposta autenticada, ACL e entrega são recibos diferentes. Running-Code Primacy exige observar os sistemas reais. Minimum Initial Specification mostra o acerto: convenção suficiente para começar, preservando escolhas locais.