Zusammenfassung

  • Who-Provides? suchte per Broadcast nach positiven Anbietern; Schweigen war deshalb kein ausdrücklicher Nachweis, dass die Ressource fehlte.
  • Do-You-Provide? verlangte vom adressierten Host auch eine leere Antwort, während They-Provide über einen Dritten üblicherweise direkt geprüft werden sollte.
  • Der Ressourcenname bildete die Demultiplexing-Kette ab und verhinderte, dass Unterstützung für Transport oder Port automatisch jede darüberliegende Spezialisierung einschloss.

Ein frisch gestarteter Host braucht einen Ausgang ins Internet, kennt aber keine Gateway-Adresse. Dieses Beispiel aus RFC 887 zeigt den Reiz von Resource Location Protocol: Statt eine möglicherweise veraltete Liste vorauszusetzen, kann der Host sein lokales Netz fragen.

Das im Dezember 1983 veröffentlichte Dokument standardisierte dabei nicht nur eine Suche. Es bewahrte die Herkunft jeder Antwort. Wer für sich selbst spricht, wer schweigt und wer nur auf jemand anderen zeigt, erzeugt unterschiedliche Belege.

Der Name beschrieb eine technische Auswahlkette

Eine Ressourcenangabe begann mit der Nummer des niedrigsten Internet-Protokolls, über das sie erreichbar war. Danach folgten Länge und Kennung aus den natürlichen Werten, mit denen höhere Schichten demultiplexen. Das Beispiel für DNS über UDP kombinierte Protokoll 17 mit Port 53.

Die Längenangabe erlaubte es einem Empfänger, eine unbekannte Struktur zu überspringen und die nächste Ressource sicher zu finden. Beim Abgleich prüfte der Host Komponente für Komponente. Eine nicht unterstützte untere Ebene bedeutete Ablehnung. Endete der Name genau nach erfolgreichen Prüfungen, war die Ressource vorhanden. Blieben unbekannte Komponenten übrig, reichte die Unterstützung der unteren Ebene nicht aus.

Ein Host konnte also TFTP anbieten und dennoch eine bestimmte Crash-Dump-Funktion über TFTP nicht anbieten. Die Behauptung blieb so eng wie die vollständig verstandene Kennung.

Der Broadcast sammelte nur positive Stimmen

Who-Provides? wurde gewöhnlich gesendet, ohne einen einzelnen Empfänger zu kennen. Anbieter antworteten mit I-Provide; Hosts ohne Treffer durften schweigen.

Das sparte Verkehr, machte das Ausbleiben einer Antwort aber mehrdeutig. Es konnte keinen Anbieter geben, die Anfrage oder Antwort konnte verloren sein, oder der Dienst konnte ohne RLP existieren. RFC 919 beschrieb IP-Broadcast später als unzuverlässig, ungeordnet und möglicherweise dupliziert. Außerdem belastet jeder Broadcast jeden Host, der ihn hört.

Die Suche tauschte feste Konfiguration gegen gemeinsame Aufmerksamkeit. Einen belastbaren netzweiten Negativnachweis erhielt sie nicht.

Eine gezielte Frage machte die leere Liste aussagefähig

Do-You-Provide? richtete sich an eine bekannte Adresse. Der Empfänger musste auch dann antworten, wenn er keine der Ressourcen anbot. Eine leere I-Provide-Liste war deshalb eine ausdrückliche Verneinung für diesen Host und diese Anfrage.

RFC 887 verbot den Broadcast dieser Variante. Müssten alle Empfänger auch negativ antworten, würde eine Frage eine Antwortflut auslösen. Vor der Gruppe sollten nur Anbieter sprechen; ein namentlich Befragter musste Ja oder Nein liefern.

Das direkte Nein vertrat weder andere Hosts noch eine spätere Konfiguration. Seine Aussagekraft entstand aus der klaren Zuständigkeit, nicht aus großer Reichweite.

Der kundige Vermittler lieferte eine Spur

Who-Anywhere-Provides? und Does-Anyone-Provide? fragten einen bekannten „smart host“ nach Ressourcen auf anderen Hosts. Das half Netzen ohne Broadcast und Gateways mit Wissen über benachbarte Netze.

Die Antwort They-Provide durfte Kandidaten nennen. RFC 887 verlangte aber keinen blinden Glauben. In der Regel sollte der Client den genannten Host mit Do-You-Provide? direkt prüfen.

Im DNS-Beispiel nennt der Vermittler zunächst S. S antwortet direkt mit einer leeren Liste. Der Client schließt S aus, fragt erneut, erhält T und bekommt erst von T die Bestätigung für UDP-Port 53. Der Vermittler muss nicht gelogen haben; sein Wissen kann gealtert sein.

Die getrennte Herkunft macht diese Korrektur möglich. Ohne sie würden eine alte Verzeichnisauskunft und der aktuelle Zustand des Endpunkts in einem scheinbaren Widerspruch verschwinden.

Local-Only begrenzte zulässige Adressen auf das IP-Netz des Fragenden und regelte die passende Quelladresse bei multihomed Hosts. Scope war Bestandteil der Behauptung.

Zuordnung war keine Authentisierung

Eine 16-Bit Message-ID half, Antwort und Anfrage zusammenzuführen. Sie bewies weder Identität noch Berechtigung. Auch die UDP-Prüfsumme war keine kryptografische Signatur.

Selbst ein direktes I-Provide bedeutete nur, dass dieser Host die genannte Ressource beanspruchte. Ob die nächste Transaktion gelang, die Implementierung vollständig konform war, der Client zugelassen wurde oder der Dienst gesund blieb, lag außerhalb dieser Antwort.

Spätere Verfahren setzten andere Grenzen

Der Vergleich belegt keine direkte Abstammung. RFC 2608 strukturierte SLPv2 mit Diensttypen, Attributen, User, Service und Directory Agents sowie administrativen Scopes. URLs und Attribute konnten authentisiert werden; Vertraulichkeit bot das Protokoll nicht.

RFC 6762 ermöglichte DNS-ähnliche Vorgänge auf dem lokalen Link ohne klassischen Unicast-DNS-Server. RFC 6763 beschrieb benannte Dienstinstanzen nach Typ und Domain. Die Datenmodelle wurden reicher, doch Herausgeber, Geltungsbereich, Alter und Wirkung blieben getrennt.

Port 39 bewahrte eine Zuweisung, keinen laufenden Prozess

RFC 887 wies UDP-Port 39 zu. Das heutige IANA-Register für Dienstnamen und Transportports führt rlp auf Port 39 für TCP und UDP. Das ist administrative Kontinuität, keine Messung der Nutzung.

RFC 6335 sagt ausdrücklich, dass eine Zuweisung keine Empfehlung darstellt und Verkehr auf einem Port nicht einmal zum eingetragenen Dienst gehören muss. Das Register koordiniert Bezeichnungen; es prüft keine Erreichbarkeit.

Quellen und Grenzen

Grundlage sind RFC 887, RFC 919, RFC 2608, RFC 6762, RFC 6763, RFC 6335 und das IANA-Register. Sie belegen weder die historische Verbreitung von RLP noch eine direkte Wirkungslinie zu späteren Verfahren oder heutiges Produktverhalten.