Zusammenfassung

  • RFC 3349 erlaubte dem Vorsitz einer IETF-Arbeitsgruppe, eine vorläufige URI für ein noch entwickeltes BEEP-Profil zu autorisieren.
  • Die URI konnte bereits bei der Kanalaushandlung wirken, belegte aber weder RFC-Veröffentlichung noch dauerhafte IANA-Zuweisung, Sicherheit, Implementierung oder Einsatz.

BEEP machte den Profilnamen zu einem Laufzeitwert. Wer einen Kanal eröffnen wollte, bot eine oder mehrere Profil-URIs an. Die Gegenseite wählte eine akzeptierte URI oder lehnte den Kanal ab. Nach der Auswahl bestimmten die Regeln dieses Profils die Nachrichten auf dem Kanal. Eine gemeinsame Zeichenfolge konnte also einen realen Zustandsübergang auslösen.

Diese Zeichenfolge wurde benötigt, solange der Text noch veränderbar war. Frühe Implementierungen sollten gerade jene Unterschiede sichtbar machen, die vor einer Veröffentlichung behoben werden konnten. Mit eigenen Namen hätten zwei Prototypen einander nicht erkannt. Ein vermeintlich endgültiger Name hätte umgekehrt suggeriert, dass die technische und institutionelle Entscheidung schon gefallen sei. RFC 3349 schuf eine koordinierte Zwischenstufe.

Bei der Gründung einer Arbeitsgruppe vergab das IETF-Sekretariat ein kurzes Kürzel. Begann die Gruppe mit einem BEEP-Profil, konnte ihr Vorsitz eine URI der Form http://iana.org/beep/transient/XXX/YYY zuweisen. XXX stand für das Gruppenkürzel, YYY für eine eindeutige, URI-konforme Zeichenfolge. Anschließend füllte der Vorsitz die in RFC 3080 definierte Registrierungsvorlage aus und übermittelte sie an IANA.

Die Zuständigkeiten blieben getrennt. Das Sekretariat verwaltete das Gruppenkürzel. Der Vorsitz autorisierte die Entwicklungsregistrierung. IANA führte den Eintrag. Die Gruppe entschied weiter über den Inhalt. Für ein dauerhaftes Profil auf dem Standards Track sah RFC 3080 dagegen eine Autorisierung durch die IESG vor. Der Wechsel betraf daher nicht nur den Pfad der URI, sondern auch die Entscheidungskette.

Der Bestandteil iana.org konnte mehr Gewissheit ausstrahlen, als die Regel gewährte. Er bot einen koordinierten Namensraum. Er bedeutete nicht, dass IANA den Profilentwurf technisch gebilligt hatte. IANA verwaltete die Registrierung nach der festgelegten Richtlinie; sie schrieb nicht das Protokoll und prüfte nicht jede Implementierung. Auch der Arbeitsgruppenvorsitz besaß begrenzte Koordinationsmacht, keine alleinige Standardisierungsmacht.

Die URI war zudem kein Web-Verfügbarkeitstest. BEEP verglich den Wert in der Kanalverwaltung. Zwei Prozesse konnten sich auf die Kennung einigen, ohne eine Webseite abzurufen. Eine erreichbare HTTP-Ressource hätte ihrerseits keine Profilunterstützung im entfernten Prozess bewiesen. Syntax, Dereferenzierung, Registereintrag, Profilauswahl, Nachrichtenverarbeitung und Anwendungsergebnis waren verschiedene Belege.

RFC 3349 nannte vorläufige Beispiele für EPP und SACRED. Sie erklärten das Muster, nicht den Einsatz. Später verwendete RFC 3767 für SACRED die dauerhafte URI http://iana.org/beep/sacred; die beispielhafte Form /transient/sacred/pdm blieb nicht erhalten. Software konnte den endgültigen Namen also nicht durch lokales Kürzen erraten. Die Quellen sagen auch nicht, ob das genaue Beispiel registriert wurde, ob Prototypen beide Namen akzeptierten oder wie eine Umstellung verlief.

APEX zeigt den dauerhaften Zustand aus derselben Zeit. RFC 3340 definierte http://iana.org/beep/APEX und beschrieb die Registrierung als Standards-Track-Profil. Die heutige IANA-Tabelle enthält die URI weiterhin. Damit ist die dokumentierte Identität belegt. Nicht belegt sind die Korrektheit eines Programms, die Interoperabilität zweier Versionen, die Erreichbarkeit eines Dienstes oder ein erfolgreiches Anwendungsergebnis.

Die für diesen Artikel gesicherten aktuellen HTML- und XML-Ansichten von IANA listen dauerhafte Profile wie APEX und SACRED, aber keinen eigenständigen Bereich für vorläufige Einträge. Das ist eine zeitgebundene Beobachtung vom 3. Oktober 2026. Daraus folgt weder, wann sich die Registerdarstellung änderte, noch ob ältere Einträge anders archiviert wurden. Gegenwärtige Abwesenheit ist ohne weitere Quelle kein historisches Löschereignis.

Ein funktionierender Arbeitsname erzeugte Migrationskosten. Er wanderte in Konfigurationen, Tests, Mitschnitte, Protokolle und Handbücher. Die Veröffentlichung einer dauerhaften URI änderte diese Kopien nicht. Wechselte nur eine Seite, konnte die Kanalaushandlung scheitern, obwohl beide weitgehend gleiche Nachrichten verstanden. Dauerhafte Doppelakzeptanz vermied den Bruch, machte aber aus dem Provisorium eine langfristige Kompatibilitätspflicht.

RFC 3349 definierte weder einen universellen Alias noch eine automatische Weiterleitung oder ein gemeinsames Ablaufdatum. Er definierte die Voraussetzung: begrenzte Vergabemacht, sichtbare Vorläufigkeit und einen eigenen Weg zur Dauerhaftigkeit. Auch der Sicherheitsabschnitt blieb eng. Die Verwaltungskonvention ersetzte keine Authentisierung, Autorisierung oder profilspezifische Sicherheitsanalyse.

Eine erfolgreiche URI-Auswahl lieferte somit einen präzisen Beleg: Beide Seiten hatten für diesen Kanal dieselbe erklärte Profilidentität gewählt. Sie bewies nicht, wer der Peer war, was er durfte, ob die Nachricht gültig war oder ob die Anwendung ihr Ziel erreichte. RFC 3349 ließ den Namen früh arbeiten, ohne den späteren Beschluss vorzutäuschen.

Quellen