Summary

  • RFC 2377 schlug DNS-abgeleitete dc-Komponenten und vorhandene uid-Werte vor, warnte aber ausdrücklich: Eine E-Mail-förmige UID musste kein gültiges Postfach sein; Anwendungen sollten das getrennte Attribut mail prüfen.
  • UID-Domain und DN-Pfad durften abweichen, gleiche DNs konnten auf unabhängig verwalteten Servern liegen, und der DN allein lokalisierte oder authentisierte keinen LDAP-Dienst.

Ein vorhandenes Register war billiger als ein neues

X.500 bot Hierarchie und Delegation, doch konventionelle Namen über Staaten, Regionen und juristische Organisationsnamen waren schwer einzurichten. Allgemeine Personennamen kollidierten. RFC 2377 erschien 1998 als freiwillige Informational-Empfehlung: acme.com wurde zu dc=acme,dc=com; Blätter konnten mit uid oder cn benannt werden.

DNS, Personalnummern, Handles und RFC-822-Kennungen hatten bereits Verwaltungsbereiche. Ihre Wiederverwendung ersparte ein zweites globales Register. Sie wurden dadurch weder universelle Identitäten noch Bausteine eines einzigen Weltverzeichnisses.

Das At-Zeichen-Zeichen war kein Zustellnachweis

Für Personen empfahl das Memo gelegentlich eine ausgewählte „distinguished“ Mailkennung als UID. Manche Organisationen gaben ein solches Format jedoch auch Menschen ohne echtes Postfach, weil es weiterhin eindeutig war.

Darum die klare Grenze: uid nicht als Mailbox annehmen, sondern mail prüfen. Die UID wählte einen Eintrag. mail behauptete einen Kontaktweg. SMTP lieferte spätere Routing- und Zustellbelege. Authentisierung und Autorisierung blieben eigene Entscheidungen.

Zwei Domains durften absichtlich verschieden sein

uid=external-mailbox-shaped-identifier konnte unter dc=mis,dc=acme,dc=com stehen. Der DIT-Pfad durfte Zugriffskontrolle oder Partitionierung ausdrücken, während die UID eine externe Kennung bewahrte. Eine Verzeichnisreorganisation musste keine neue Mailadresse erzwingen.

Damit war auch die Umkehrung verboten: Aus dem Teil nach At-Zeichen ließ sich kein autoritativer DN erzeugen; aus dem DN keine aktuelle Mailbox. Die verbundenen dc-Werte mussten einen registrierten DNS-Namen ergeben, um Namenskonflikte zu vermeiden. Registrierung authentisierte aber weder LDAP-Server noch Organisation oder Person.

Ein DN war kein Endpunkt

RFC 2247 definierte die umkehrbare Abbildung zwischen Domain und reinem dc-DN, nicht jedoch die Suche nach dem LDAP-Server. Ein nicht vertrauenswürdiger Server konnte sogar nicht delegierte Namenskontexte beanspruchen.

RFC 2377 erwartete lose gekoppelte Serverinseln. Referrals verbanden gemeinsame DN-Namensräume; eine LDAP-URL ergänzte Host und Port, um Inseln zu überbrücken. Unabhängige Betreiber konnten unterschiedliche Objekte mit demselben DN für dasselbe reale Subjekt halten.

Benennen war auch nicht Suchen: uid konnte den RDN bilden, während cn für Suche und Anzeige wichtig blieb. Öffentliche DNS-Namen konnten zudem Strukturen verraten, die ACLs beim Browsen verbargen.

RFC 4519 machte später uid, dc, dcObject und uidObject normativ präzise. Ein sauberes Schema verwandelte die UID dennoch nicht in Postfach, Berechtigungsnachweis oder authentisierte Identität.

Namen wiederverwenden, Beweiskraft nicht

Lu Hengs Realitätsschichten trennen DNS-Delegation, strukturierten DN, Textdarstellung, UID, mail, LDAP-URL, authentisierte Antwort, ACL-Entscheidung und Zustellung. Running-Code Primacy verlangt die tatsächliche Serverbeobachtung. Minimum Initial Specification erklärt die Stärke des Plans: ein enger gemeinsamer Anfang ohne Zwang für spätere lokale Entscheidungen.