Zusammenfassung

  • RFC 1292 ist FYI 11, ein Informational RFC vom Januar 1992. Der Text katalogisiert kommerzielle und offene X.500-Implementierungen; er standardisiert sie nicht und bestätigt nicht unabhängig ihre Qualität oder Funktionsfähigkeit.
  • Die Stichworte folgen expliziten Aussagen in einer Implementierungsbeschreibung oder Angaben ihres Verfassers. Ein sauber zugeordnetes Stichwort ist kein Protokoll eines durchgeführten Tests und kein Urteil über die Interoperabilität zweier konkreter Endpunkte.

Ein Katalogeintrag wirkt oft entschiedener, als sein Ursprung ist. In einer Tabelle steht etwa ein Produktname neben DSA/DUA, einer Transportumgebung, einer Verfügbarkeitsart und einigen Funktionen. Das Auge liest die geschlossene Zeile leicht als technische Einheit: Dieses Produkt sei bestimmt, erreichbar und passend. RFC 1292 verlangt eine zurückhaltendere Lesart. Die Zeile ist eine zusammengeführte Beschreibung mit Regeln für ihre Einordnung, nicht die Aufzeichnung einer Installation, einer Verbindung oder eines organisatorischen Beschlusses.

Diese Unterscheidung ist für die Geschichte des Internets wichtig, weil der Wert einer technischen Übersicht gerade in ihrer Abstraktion liegt. Sie reduziert Komplexität, damit jemand Kandidaten vergleichen kann. Würde sie zugleich behaupten, jede denkbare Folge der beschreibenden Angaben geprüft zu haben, wäre sie nicht mehr Übersicht, sondern ein viel umfangreicheres Labor-, Betriebs- und Entscheidungsarchiv. RFC 1292 beansprucht diese zusätzliche Rolle nicht.

Klassifizieren ist eine andere Handlung als testen

Der Text nennt eine präzise Regel für seine Keywords. Eine Implementierung wird unter einem Stichwort verzeichnet, wenn ihre Beschreibung die Fähigkeit ausdrücklich, nicht nur implizit, erwähnt oder wenn der Autor der Beschreibung sie als Eingabe liefert. Die Regel begrenzt die redaktionelle Schlussfolgerung. Ein Editor soll nicht aus benachbarten Informationen erraten, dass eine Eigenschaft vorliegt, und dann diese Vermutung als Katalogfakt ausgeben.

Das ist eine starke Regel für die Beziehung zwischen einem Satz und einer Kategorie. Sie beantwortet: Warum steht diese Zeile in dieser Spalte? Sie beantwortet nicht: Hat jemand diese Funktion in einer bestimmten Version gestartet? Wurde sie mit einem benannten Gegenüber ausgeführt? Welche Parameter, Zugriffsrechte und Daten galten? Was kam zurück? Ein Test besitzt eine Versuchsanordnung; ein Katalogstichwort besitzt eine Herkunftsbeziehung zu einer Beschreibung. Beides sollte man nicht mit derselben Evidenzklasse bezeichnen.

Die praktische Verwechslung beginnt häufig mit einem wahren Zwischensatz. Wenn in der Beschreibung ein Merkmal ausdrücklich vorkommt, ist es wahr, dass der Katalog dieses Merkmal nachvollziehbar indexiert. Daraus wird dann unbemerkt: Das Merkmal sei im Einsatz gesichert. Die zweite Aussage enthält neue Tatsachen über Version, Konfiguration, Gegenstelle und Zeit. Sie ist ohne ein separates Testprotokoll nicht durch den ersten Satz gedeckt.

Auch ein leeres Feld braucht diese Vorsicht. Es kann bedeuten, dass eine Eigenschaft nicht erwähnt, nicht eingereicht oder nicht in die redaktionelle Taxonomie aufgenommen wurde. Es beweist nicht automatisch, dass die Fähigkeit fehlt. Wer vorhandene Keywords als Erfolg und fehlende Keywords als Negativurteil liest, erweitert die Klassifikationsregel in zwei Richtungen über ihre Quelle hinaus.

Gemeinsames Transportlabel erzeugt keine gemeinsame Assoziation

Für die Internetworking Environment listet RFC 1292 unter anderem CLNP, OSI Transport, RFC 1006 und X.25. Ein RFC-1006-Eintrag zeigt im Rahmen des Katalogs, dass die Beschreibung die Implementierung mit einem TCP/IP-Transportdienst verband. Das ist nützlich für die Vorauswahl. Zwei Interessenten können entscheiden, welche Kandidaten überhaupt eine Untersuchung verdienen.

Doch ein gemeinsamer Eintrag ist keine erfolgreich aufgebaute DUA-DSA-Assoziation. Zwei Implementierungen können trotz gleichem Transportwort an Protokollversionen, Namensdarstellungen, Directory-Schemata, Objektklassen, Referenzen, Routing, Authentifizierung, Zugriffsrichtlinien oder Fehlerbehandlung scheitern. Selbst dieselbe Software kann auf zwei Betriebssystemen oder unter zwei lokalen Konfigurationen verschieden reagieren. Das Label beschreibt eine Hypothese über eine Ebene des Pfads, nicht das beobachtete Verhalten der gesamten Kette.

Ein belastbarer Interoperabilitätsnachweis müsste die beiden Endpunkte, ihre Versionen, die relevante Konfiguration, den Zeitpunkt, die Operation und die Antwort nennen. Wenn eine DUA eine bestimmte Directory-Information abfragt, muss sichtbar bleiben, welches DSA antwortete, auf welchem Weg, mit welcher Berechtigung und mit welchem Ergebnis. RFC 1292 wurde nicht als Speicher für diese Details gebaut. Seine Tabelle kann die Frage stellen helfen, aber nicht die Antwort vorwegnehmen.

DUA- und DSA-Konnektivität haben unterschiedliche Richtung

Der Katalog unterscheidet Pilot Connectivity nicht als einen einzigen Zustand. DUA Connectivity bedeutet, dass eine DUA sich mit dem Pilot verbinden und Informationen über beliebige Einträge suchen sowie Standardattribute und Objektklassen, einschließlich der in COSINE und Internet Schema definierten, anzeigen kann. DSA Connectivity bedeutet dagegen, dass ein DSA mit dem Directory Information Tree verbunden ist und die Informationen in diesem DSA für beliebige Pilot-DUAs zugänglich sind.

Die Unterscheidung trennt Anfrage- und Bereitstellungsseite. Eine DUA, die einen Eintrag abfragen kann, hält die Information nicht notwendigerweise selbst. Ein als zugänglich beschriebenes DSA beweist nicht, dass jede DUA, jede Route und jeder Zeitpunkt zu einer erfolgreichen Abfrage führt. Dazwischen liegen Wahl des Eintrags, Schema, Pfad, Zugriffsentscheidung und die Betriebsfähigkeit beider Seiten.

Auch die Kategorie einer Lightweight DUA Client Application verdichtet keinen Ende-zu-Ende-Erfolg. Ein nicht-OSI-Client kann über ein Anwendungsprotokoll mit einer DUA sprechen, die ihrerseits mit einem DSA spricht. Dass der erste lokale Übergang beschrieben ist, sagt nichts darüber, ob der zweite Übergang die richtige entfernte Information erreicht oder ob deren Verwendung erlaubt ist. Jede Übergabe schafft eine eigene Bedingung und eine eigene Möglichkeit, dass die Wirklichkeit von der Katalogbeschreibung abweicht.

Verfügbarkeit etikettiert einen Weg, nicht sein Ergebnis

RFC 1292 ordnet die Verfügbarkeit als FTP, FTAM, Commercial, Free, Source oder Potentially Unavailable. Diese Kategorien vermeiden sinnvollerweise die Behauptung, alle Angebote seien gleich. Ein kommerzielles Produkt ist nicht dasselbe wie eine frei verfügbare Kopie; Quelltext ist nicht dasselbe wie ein ausführbares System; „möglicherweise nicht verfügbar“ hält eine Unsicherheit offen, die eine nüchterne Übersicht nicht löschen sollte.

Die Kategorien sind dennoch zeitgebunden. Ein FTP-Ort kann verschwinden, ein Vertrag sich ändern, eine Quelltextlieferung Abhängigkeiten oder Rechte vermissen lassen, eine Anleitung auf eine nicht mehr vorhandene Plattform verweisen. Der Erwerb von Dateien ist nicht ihr Kompilieren; das Kompilieren ist nicht ihre Konfiguration; die Konfiguration ist nicht der sichere und erfolgreiche Betrieb. Zwischen diesen Stufen liegen Prüfsummen, Bibliotheken, Compiler, Daten, Zugangsdaten, Netzwege und die Kompetenz, Fehler zu deuten.

Ein Eintrag mit Source erlaubt daher die Frage, ob eine reproduzierbare Bereitstellung möglich sein könnte. Er ist kein Build-Log und kein Nachweis, dass eine Organisation die Software rechtmäßig, sicher und sinnvoll einsetzen kann. Wer aus einer historischen Verfügbarkeitsklasse einen aktuellen Beschaffungs- oder Betriebsanspruch macht, ersetzt die zeitliche Aussage des Katalogs durch eine Behauptung, die neu geprüft werden müsste.

Herkunft der Beschreibung bestimmt ihre Reichweite

DISI sammelte die Informationen nach eigener Darstellung durch Aufrufe an die X.500-Gemeinschaft über Internet-Mailinglisten. Implementierer und Anbieter verfassten die Beschreibungen. DISI half bei ihrer Lesbarkeit, gewährleistete jedoch weder die Gültigkeit der Beschreibung noch den Wert einer Implementierung. Der Katalog ist damit auch ein Dokument darüber, wie eine Gemeinschaft Selbstbeschreibungen zu Vergleichszwecken bündelte.

Das schränkt die Aussagekraft nicht auf Null ein. Es macht sie präzise. Die Quelle kann belegen, dass ein Beteiligter ein Produkt zu dieser Zeit in bestimmter Weise darstellte und dass ein Herausgeber diese Darstellung unter bestimmten Überschriften aufnahm. Sie belegt nicht, dass ein unabhängiges Labor die Behauptung verifiziert, dass ein Kunde dieselbe Erfahrung gemacht oder dass der Eintrag für eine bestimmte Institution wirtschaftlich sinnvoll gewesen wäre.

Für eine spätere Auswertung sollten diese Rollen nicht verschwimmen. Der Implementierer beschreibt. Der Editor strukturiert und entscheidet über die Publikation. Ein Testteam beobachtet eine konkrete Ausführung. Eine Organisation wählt Kriterien, trägt Kosten und akzeptiert Risiken. Ein Katalog kann die ersten beiden Akte dokumentieren; er kann die letzten beiden nicht stellvertretend vollziehen.

Keine Empfehlung ohne benannte Kriterien

Das Scope-Kapitel sagt ausdrücklich, dass RFC 1292 keine Anweisungen zum Installieren, Ausführen oder Verwalten der Implementierungen liefert. Ebenso spricht der Text keine Empfehlung aus, weil Anforderungen und Rechnerumgebungen von Organisation zu Organisation stark variieren. Diese Enthaltsamkeit ist kein Mangel an Urteilskraft, sondern eine Absage an eine falsche Universalität.

Eine Empfehlung verlangt, dass jemand Kriterien auswählt und gewichtet: vorhandener Transportstack, Fachwissen des Personals, Datenmodell, Lizenz, Support, Migration, Sicherheitsanforderungen, Haushaltsgrenzen und Bedürfnisse der Nutzer können einander widersprechen. Aus derselben Tabelle können zwei Institutionen nachvollziehbar verschiedene Entscheidungen ableiten. Die Tabelle enthält nicht die Verantwortung für diese Gewichtung.

Die Wirkung einer geordneten Liste kann dennoch wie eine Rangfolge aussehen. Ein aufgeführtes Produkt scheint bestätigt, ein nicht aufgeführtes verworfen. Beides folgt nicht. Eine Beschreibung mag nicht eingereicht worden sein, außerhalb der Sammlung liegen oder erst nach einer Ausgabe auftauchen. Discovery-Grenzen sind keine Qualitätsurteile. Wer sie als solche verwendet, verschiebt eine Beschaffungsentscheidung in eine Quelle, die dafür weder Kriterien noch Mandat besitzt.

Die Revision war ein sozialer Taktgeber

RFC 1292 fordert Kommentare, Kritik und neue oder überarbeitete Beschreibungen. Eine neue Ausgabe sollte entstehen, wenn DISI genügend Änderungen erhalten hatte; was als genügend galt, entschied der DISI Chair subjektiv. Der Aktualisierungsrhythmus war also kein automatisches Abbild des Softwarezustands, sondern eine Folge von Einsendungen, Redaktion, Urteil und Veröffentlichung.

Zwischen zwei Ausgaben konnte sich eine Implementierung verändern, ihr Vertriebsweg ausfallen oder ein neues Angebot entstehen. Das macht die ältere Ausgabe nicht wertlos. Sie bleibt ein datierter Nachweis dafür, was in ihrem Zeitraum beschrieben und geordnet wurde. Sie wird nur dann missverstanden, wenn diese historische Momentaufnahme als aktueller Betriebszustand gelesen wird, ohne dass Zeit, Version und Nachprüfung erneut sichtbar werden.

Quelle und Evidenzgrenzen

Dieser Beitrag verwendet RFC 1292 — A Catalog of Available X.500 Implementations. Die Quelle trägt die Einordnung als FYI/Informational vom Januar 1992, Zweck und Arbeitsweise des DISI-Katalogs, die Rollen DSA, DUA und Client, die Sammlung über Mailinglisten, die von Implementierern und Anbietern stammenden Beschreibungen ohne Garantie, die Regel expliziter Keywords, die Verfügbarkeits-, Transport- und Pilot-Kategorien, den Verzicht auf Betriebsanweisungen und Empfehlungen sowie die subjektive Revisionsschwelle. Sie trägt nicht die aktuelle Erhältlichkeit, Lizenzierbarkeit, Kompilierbarkeit, Installation oder Unterstützung einer Implementierung; keinen erreichbaren Host, keine beobachtete Pilotverbindung, keine konkrete Interoperabilität, keine Sicherheitszusage, keine Organisationspassung, keine Empfehlung und kein Nutzerergebnis.