Zusammenfassung

  • RFC 1484 bezeichnete den eingegebenen User Friendly Name als purported name: Er durfte Typen, Ebenen und exakte Schreibweisen auslassen und musste erst auf Distinguished Names aufgelöst werden.
  • Das Ergebnis entstand aus geordneter lokaler Umgebung, Schema, aktuellem Verzeichnisinhalt, Alternativwerten, Matching und nötigenfalls einer menschlichen Wahl.
  • Der ausgewählte DN benannte einen Verzeichniseintrag. Authentisierung, Befugnis, Attributwahrheit und die spätere Wirkung blieben eigene Entscheidungen.

Das fehlende Feld im Suchprotokoll

RFC 1484 wollte einen X.500-Namen so benutzbar machen, wie Menschen Namen tatsächlich weitergeben: auf einer Visitenkarte, in einer Mail oder im Gespräch. Niemand sollte eine Folge expliziter Attributtypen in ein Formular übertragen müssen.

Der Standard erlaubte deshalb Typauslassung, Abkürzung höherer Komponenten, Überspringen einer Organisationseinheit, alternative Werte, ungefähre Schreibweisen und freundliche Ländernamen. Doch er nannte die Eingabe nicht Distinguished Name. Sie war ein purported name, eine Behauptung, die das Verzeichnis erst auflösen musste.

Die kurze Zeichenkette war also nicht selbstgenügsam. Sie wurde erst durch unsichtbare Eingaben ausführbar. Wer nur Eingabe und Endergebnis speichert, verwischt genau den Vorgang, der aus menschlicher Beschreibung eine technische Referenz machte.

Ausgelassene Typen wanderten ins Schema

Ein Standardschema konnte nicht bezeichnete Komponenten als Common Name, Organisation, Organisational Unit und Country einordnen. Kontext- und datenabhängige Varianten waren ebenfalls vorgesehen. Wo das nicht genügte, suchte der Client über mehrere Attributarten.

Ein zweibuchstabiger Wert konnte an einer Stelle ein Land, an anderer eine Region oder Organisation bezeichnen. Eine Kurzform konnte als exakter Alternativwert gelten; ein Tippfehler nur als ungefähre Übereinstimmung. Die Oberfläche sparte Zeichen, das System übernahm Interpretationsarbeit.

RFC 1484 empfahl, anschließend fast immer den DN zu speichern. Ein purported name, der heute eindeutig war, konnte durch einen neu registrierten Namen morgen mehrdeutig werden. Die Zeichenkette hatte sich nicht geändert. Ihre Umgebung hatte es.

Die lokale Umgebung bestimmte die Suchrichtung

Jeder Abgleich geschah in einem local environment: einer geordneten Liste nicht-blattförmiger DN im Directory Information Tree. Je nach Zahl der eingegebenen Komponenten galten andere Listen; einzelne Nutzer sollten sie beeinflussen können.

Im Universitätsbeispiel begann eine einteilige Suche im Fachbereich, dann folgten Universität, Land und Wurzel. Zweiteilige Angaben starteten anders. Ein öffentlicher US-Client verwendete wiederum eine andere Reihenfolge.

Reihenfolge war keine kosmetische Präferenz. Ein früher exakter Treffer konnte weitere Umgebungen verdrängen. Ein lokal bekannter Name konnte ohne Rückfrage gewählt werden, während ein externer Client mehrere Personen zeigte. Dieselbe Eingabe führte regelkonform zu verschiedenen Suchpfaden.

Zur Reproduktion gehören deshalb Client, Sprache, Parser, environment, Schema, Filter, Zeitpunkt und Kandidaten. Der DN allein verrät nicht, welche Alternativen nie sichtbar wurden.

Exact, good und poor steuerten den Ablauf

RFC 1484 unterschied exact, good und poor. Exakte Treffer wurden verfolgt. Gab es keine, folgten gute Treffer. Schlechte Teil- oder Näherungstreffer wurden dem Nutzer vorgelegt. Lehnte er alles ab, konnte der Client zum nächsten environment wechseln.

Ob Initialen, Zeichensetzung, Akronyme oder Varianten als gut galten, war Implementierungs- und Datenfrage. Der Dialog gehörte zum Algorithmus. Ein menschliches Ja verwandelte eine Kandidatenmenge in eine Auswahl.

Später beschrieb RFC 4511 LDAP-Suchen mit base, scope, Alias-Politik, Größen- und Zeitgrenzen, Filter und Attributauswahl. Ein Server kann Einträge und continuation references liefern, bevor das Endergebnis vorliegt. Ein sichtbarer Treffer beweist daher keine vollständige Suche.

Der Name hatte drei technische Gestalten

RFC 1309 erklärt die X.500-Grundlage: Ein Eintrag liegt im DIT; die RDN entlang des Wurzelpfads bilden seinen DN. Der vorhandene RFC-1309-Artikel behandelt DUA, DSA, chaining, referrals, Alias- und Replikatgrenzen. RFC 1484 behandelt die andere Frage: Wie findet ein Mensch den Pfad, ohne ihn zu kennen?

RFC 1485 definierte parallel eine Textdarstellung für einen bereits bekannten DN. RFC 1779, RFC 2253 und RFC 4514 entwickelten diese Darstellung weiter.

RFC 4514 definiert ausdrücklich keine kanonische DN-Zeichenkette. Gleichheit richtet sich nach distinguishedNameMatch, nicht nach rohem Textvergleich. Darstellungsunterschiede müssen keine verschiedenen Einträge bedeuten; ähnlich aussehende Werte müssen nicht gleich sein.

RFC 4512 ordnet Attributtypen Syntax und Matching Rules zu und verlangt RDN-Eindeutigkeit unter Geschwistern. RFC 4518 bereitet internationalisierte Zeichenketten für Matching vor. Anzeige, Codepunkte, vorbereiteter Wert und Eintragsreferenz sind getrennte Belege.

Ein Eintrag konnte niemanden authentisieren

Ein DN verweist im Verzeichnismodell eindeutig auf einen Eintrag. Der Eintrag ist eine benannte Informationssammlung über ein Objekt. Diese Modellbeziehung beweist nicht, dass der aktuelle Nutzer dieses Objekt ist oder kontrolliert.

Zugriffsregeln können Attribute verbergen, referrals können offen bleiben, Replikate können altern und Nutzer können Namensvetter auswählen. Die nachgelagerte Anwendung muss weiterhin authentisieren, autorisieren, die verwendete Eintragsversion festhalten und den Effekt beobachten.

Adressfindung beweist keine Zustellung. Ein Kontotreffer erteilt keine Berechtigung. Ein exact match ist keine juristische Identität.

Das Experiment veröffentlichte seine Schulden

RFC 1484 berichtete von einer Implementierung in FRED im PSI Pilot und einem Prototyp für Verteilerlisten; die Reaktion war günstig. Das ist laufender Code, aber keine Internet-weite Messung.

Mehrere Ebenen von Organisationseinheiten bereiteten Probleme, wenn eine ausgelassene Einheit nicht direkt unter der genannten lag. Führende Wildcards konnten ineffizient sein. Mehrdeutigkeit, Nutzen, Leistung und Varianten sollten weiter untersucht werden; das Format galt als eher stabil, der Algorithmus nicht.

Der RFC-Editor-Eintrag belegt den Dokumentstatus. RFC 1484 war Experimental und behandelte laut Security Considerations keine Sicherheitsfragen. Datenschutz, Enumeration-Schutz und Identitätsstärke lassen sich daraus nicht ableiten.

Freundlichkeit stand am Anfang der Beweiskette

Heng Lus Texte über laufenden Code, lokale Zukunftsentscheidung und Realitätsschichten helfen, die Rollen sauber zu halten. Das gemeinsame Format blieb klein. Der Client behielt Kontext, das Verzeichnis Daten, der Nutzer die Auswahl und die Anwendung die Wirkung.

Eine belastbare Chronik verbindet Äußerung, purported name, environment, Suche, Kandidaten, Auswahl, DN, Eintragsversion, Authentisierung, Autorisierung und Ergebnis. RFC 1484 machte den Einstieg freundlich. Es erklärte die übrigen Stufen nicht für überflüssig.

Quellen