Zusammenfassung

  • RFC 3383 verteilte LDAP-Erweiterungen je nach Kollisionsrisiko auf Standards Action, Expert Review, Specification Required, First Come First Served, experimentelle und private Räume.
  • Eine Registrierung belegte Koordination, nicht Implementierung oder Sicherheit. Ihr Wert lag in der öffentlichen Verbindung zu Spezifikation, Verantwortlichem, Prüfung und Änderungskontrolle.

Wenn zwei Implementierungen dieselbe Zahl für unterschiedliche Ergebnisse verwenden, kann jede Nachricht formal gültig bleiben. Der Empfänger erkennt nicht zwingend einen Kodierungsfehler. Er kann den Wert erfolgreich lesen und falsch verstehen. Ein großer Zahlenraum verhindert diese semantische Kollision nicht von selbst.

RFC 3383 erschien im September 2002 als BCP 64 und behandelte LDAP-Erweiterbarkeit als Verwaltungsaufgabe mit technischen Folgen. Neue Operationen, Ergänzungen vorhandener Operationen und Schema-Erweiterungen waren bereits möglich. Nun musste der gemeinsame Raum ihrer Kennungen geordnet werden.

Das Dokument setzte nicht auf eine einzige Genehmigungsstufe. Nachrichtentypen, auffindbare Mechanismen, Ergebniscodes, Authentisierungsmethoden, OID-Deskriptoren und AttributeDescription-Optionen hatten unterschiedliche Reichweiten. Deshalb erhielten sie unterschiedliche Eintrittshürden.

Für IETF-Elemente konnte eine Spezifikation einen OID-Zweig unter Internet Directory Numbers erhalten. Dafür galten Expert Review und Specification Required. Nach Zuweisung eines Zweigs durfte das Dokument darunter selbst OIDs vergeben. IANA koordinierte die Äste; die Spezifikation verwaltete ihren lokalen Baum.

Andere Entwickler durften ordnungsgemäß delegierte OIDs verwenden, darunter Private Enterprise Numbers. Frühe Implementierungen sollten experimentelle OIDs nehmen, damit ein Arbeitsstand nicht mit der später veröffentlichten Kennung kollidierte. In publizierten Spezifikationen sollten diese experimentellen Werte nicht fortleben.

Für über Root DSE auffindbare Controls und Extensions galt häufig First Come First Served mit Specification Required. Ein Standards-Track-Mechanismus musste dagegen über Standards Action registriert werden. Eine verfügbare technische Beschreibung war eine Koordinationsvoraussetzung, aber keine Standardisierung.

Die Begriffe dürfen nicht als Qualitätsnoten gelesen werden. First Come First Served prüft keine Sicherheit. Specification Required beweist keinen Konsens. Standards Action beweist keine Auslieferung. Jede Richtlinie beschreibt nur die Voraussetzungen für einen bestimmten gemeinsamen Raum.

OID-Deskriptoren waren kurze, nicht zwischen Groß- und Kleinschreibung unterscheidende Namen. Mehrere Namen konnten auf dieselbe OID zeigen. Ein Name mit abschließendem Bindestrich reservierte eine Familie. x- kennzeichnete nicht registrierbare private Nutzung, e- Experimente mit einfacher Vergabe; andere Deskriptoren verlangten Expert Review.

AttributeDescription-Optionen nutzten eine ähnliche Trennung. Das Präfix war eine Aussage über Koordinationsumfang. Ein privater Name konnte lokal funktionieren, erhielt dadurch aber weder globale Eindeutigkeit noch eine öffentlich geprüfte Bedeutung.

Bei resultCode-Werten war die Abstufung numerisch: 0 bis 1023 benötigten Standards Action, 1024 bis 4095 Expert Review mit Specification Required, 4096 bis 16383 First Come First Served samt e--Namen. Ab 16384 und für x--Namen galt nicht registrierbare Private Use.

Authentisierungsmethoden folgten denselben Bereichen und wurden zusätzlich als COMMON, LIMITED USE oder OBSOLETE klassifiziert. Ohne öffentliche Spezifikation durfte eine Methode nicht COMMON heißen. Eine neue Registrierung durfte nicht als OBSOLETE beginnen. Die Klassifikation beschrieb vorgesehene Nutzung, keine gemessene Verbreitung.

Neue LDAP-Nachrichtentypen verlangten Standards Action. Erweiterbare Nachrichten verringerten zwar den Bedarf an neuen obersten Typen, beseitigten ihn aber nicht. Eine Änderung der grundlegenden Hülle brauchte mehr Koordination als ein lokales Experiment.

Das Register Directory Systems Names wurde für neue Einträge geschlossen. Es gehörte zur LDAPv2-Darstellung von Distinguished Names; LDAPv3 verwendete anders aufgebaute OID-Deskriptoren. Die vorhandene Liste sollte historisch erreichbar bleiben. Ein Ende der Zuteilung bedeutete keine Löschung.

Expert Review war ein öffentliches Verfahren. Ein vollständiges Formular wurde zwei Wochen zur Diskussion gestellt. Eine überarbeitete Fassung startete den Zeitraum erneut. Teilnehmer konnten Einwände erheben; der Experte genehmigte und leitete weiter oder lehnte ab. Gegen die Entscheidung war Berufung möglich.

First-Come-Anträge gingen direkt an IANA. Auch Eigentum folgte der Richtlinie: IESG galt als Eigentümer von Standards-Action-Werten, Antragsteller gewöhnlich als Eigentümer der anderen. Das wurde später für Pflege und Korrektur wichtig.

Änderungen unterlagen denselben Bedingungen wie neue Registrierungen. Konnte oder wollte ein Eigentümer eine notwendige Korrektur nicht vornehmen, durfte IESG die Kontrolle übernehmen. Erhebliche Einwände Dritter konnten nach Expert Review als Kommentare angefügt werden. Das Register konnte Dissens bewahren, statt Einigkeit zu erfinden.

Die Vorlagen verlangten Kennung, Beschreibung, Spezifikation, Kontakt, Autor oder Change Controller, Nutzung und Kommentare. Eine nackte Zahl verhindert nur eine ordentliche Doppelvergabe. Ohne diese Metadaten fehlt der Ort, an dem Bedeutung und Reparaturzuständigkeit nachgeschlagen werden können.

RFC 2434 lieferte die damalige allgemeine Begriffswelt, RFC 8126 aktualisierte sie später. Die heutigen IANA LDAP Parameters belegen die Kontinuität eines öffentlichen Registers, nicht unveränderte Felder seit 2002 und nicht die Implementierung jedes Eintrags.

RFC 3377 ordnete das Dokument in die damalige LDAPv3-Spezifikation ein. RFC 2251, RFC 2252 und RFC 2255 lieferten Protokoll-, Schema- und URL-Kontext; RFC 4510 beschrieb später die revidierte Spezifikation. Diese Genealogie ist kein Adoptionsnachweis.

Das dauerhafte Prinzip war abgestufte Reibung. Vollständige Standardisierung jedes Versuchs hätte Experimente erstickt. Ungeregelte öffentliche Zuteilung hätte Kosten in spätere Interoperabilitätsfehler verschoben. Experimentelle und private Räume ließen Bewegung zu, ohne globale Bedeutung vorzutäuschen.

Lu Hengs minimale Anfangsspezifikation zeigt die Sparsamkeit: Partitionen, Richtlinien, Formulare, Eigentümer und Reparaturwege festlegen, zukünftige Erweiterungen aber lokal entscheiden. Seine Realitätsebenen trennen Zuteilung, Registrierung, Spezifikation, Implementierung, Betrieb und Ergebnis. Ein Registereintrag belegt nur eine dieser Ebenen.

RFC 3383 machte Erweiterbarkeit zu dauerhafter Verwahrung. Die Kennung gab der Erweiterung einen Platz. Die Richtlinie bestimmte ihre Eintrittskosten. Das Register hielt Bedeutung, Verantwortlichen und Korrekturweg noch auffindbar, als die Zuteilung längst vergangen war.

Quellen