Zusammenfassung

  • RFC 2079 definierte das groß-/kleinschreibungssensitive, mehrwertige Attribut labeledURI und die Hilfsklasse labeledURIObject, die bestehende X.500- oder LDAP-Einträge erweitern konnte.
  • Ein nicht codiertes Leerzeichen trennte URI und optionale Beschriftung. Mehrere Werte konnten verschiedene verwandte Ressourcen oder mehrere Orte einer Ressource sein; ein Beziehungstyp fehlte.
  • Ein gespeicherter Verweis belegte weder Erreichbarkeit noch Aktualität, Autorität oder Gleichwertigkeit. Die Beschriftung war kein vertrauenswürdiges HTML; vor blindem Einfügen wurde ausdrücklich gewarnt.

1997 experimentierten bereits unabhängige Gruppen mit URLs in LDAP und X.500. RFC 2079 erfand den Verweis nicht. Es schuf einen gemeinsamen Namen und eine Form, die unterschiedliche Clients erkennen konnten.

Der Wert begann mit einer URI — damals einer URL nach RFC 1738 — und konnte nach Leerzeichen eine menschenlesbare Beschriftung enthalten. Da URLs kein uncodiertes Leerzeichen enthalten durften, markierte das erste eine eindeutige Grenze. Der Client musste die Sprache nicht verstehen, um Adresse und Text zu trennen.

Mehrere Werte ließen die Beziehung offen

Laut RFC bezeichneten mehrere Werte gewöhnlich verschiedene Ressourcen mit Bezug zum Objekt, konnten aber auch verschiedene Orte derselben Ressource darstellen. Profilseite und Foto unterscheiden sich von Hauptseite und Spiegel. Trotzdem enthielt das Attribut keine maschinenlesbaren Rollen wie Porträt, Spiegel, kanonische Quelle, Archiv oder Ersatz.

Die Beschriftung durfte Art oder Größe andeuten, hatte aber keine definierte Grammatik. „Offizielle Seite“ war eine Aussage des Schreibenden. Das Verzeichnis konnte den angehängten Wert unter einem bekannten Attribut nachweisen, nicht die Zustimmung des Ziels oder die Austauschbarkeit zweier Adressen.

RFC 3986 beschrieb URI-Vergleiche später als Stufen. Zeichengleiche URIs dürfen als äquivalent gelten; unterschiedliche Zeichenfolgen können nach syntaktischer oder schemenspezifischer Normalisierung dennoch dieselbe Ressource bezeichnen. Exakte Speicherung dokumentiert die Eingabe, löst aber nicht jede Identitätsfrage.

Erweiterbarkeit verlieh keine zusätzliche Autorität

labeledURIObject war eine von top abgeleitete Hilfsklasse. Sie verlangte kein Feld und erlaubte labeledURI, sodass ein bestehendes Objekt ergänzt werden konnte. Andere Klassen durften das Attribut direkt aufnehmen.

RFC 2798 machte es in inetOrgPerson optional und zeigte eine persönliche Homepage. RFC 3383 führte Attribut und Klasse in der LDAP-Deskriptorentabelle. Das belegt Wiederverwendung und Auffindbarkeit, nicht Zustand oder Verbreitung der Zielseiten.

RFC 3296 nutzte dieselbe Wertform für untergeordnete LDAP-Verweise, fügte aber eigene Regeln hinzu. ref ignorierte die Beschriftung, entfernte sie beim Erzeugen der Weiterleitung, verwendete alle URI-Werte und empfahl dem haltenden Server, die referenzielle Integrität nicht zu prüfen. Erst ein weiteres Dokument verwandelte die allgemeine Form in eine bestimmte Protokollhandlung.

Anzeige war eine neue Ausführungsentscheidung

Die Beschriftung war für Menschen gedacht. RFC 2079 riet wegen uneinheitlicher damaliger Clients von Nicht-ASCII-Zeichen ab und unterschied X.500-Darstellung von HTML-Escapes. Seine Sicherheitswarnung war deutlich: Unbehandelte Beschriftungen in HTML könnten bösartige Tags enthalten und Betrachter des gesamten Dokuments täuschen.

Speichern und Darstellen waren damit getrennte Handlungen. Der Client musste escapen, das tatsächliche Ziel zeigen und über Klickbarkeit entscheiden. Außerhalb des Verzeichnisses kamen Umleitungen, Inhaltswechsel, abgelaufene Hosts, Kontrollwechsel und protokollspezifisches Verhalten hinzu.

Eine belastbare Beweiskette trennt Eintrag, Wert, URI/Beschriftung, Mehrwertigkeit, behauptete Beziehung, Behauptenden, Abruf, Herkunft und Aktualität des Ziels, sichere Anzeige und Folgerung. Korrekte Form deckt nur einen Teil davon ab.

Ein Attribut ersetzte zwei Namen, nicht zwei Bedeutungen

Ein früher Entwurf hatte labeledURL definiert. RFC 2079 erklärte es für veraltet, weil die Arbeitsgruppe ein URI-Attribut statt zweier Attribute bevorzugte. Die alte Definition blieb für Übergangskompatibilität erhalten.

Die Konsolidierung verkleinerte das gemeinsame Vokabular. Sie löschte keine bestehenden Werte, bewies keine Migration und ergänzte keine Beziehungstypen. Auch machte der breitere Begriff URI verschiedene Protokolle nicht austauschbar.

Die bleibende Lehre ist genau begrenzt: Eine gemeinsame Art, Zeiger anzuhängen, ermöglicht Austausch. Sie vereinheitlicht weder ihren Zweck noch ihren heutigen Zustand oder das Vertrauen in den Text daneben.

Quellen