Zusammenfassung

  • RFC 1861 ordnete Befehlsannahme, Erreichbarkeit, Warteschlange, Zustellung ans Funkgerät, Lesen durch den Teilnehmer, Antwort und endgültigen Abschluss verschiedenen Zuständen zu.
  • ACKRead trennte die Lesebestätigung von einer Antwort; Message_Tag, Pass_Code, MSTAtus und eine ansteigende Sequenz hielten spätere Änderungen nachvollziehbar.
  • Die Genauigkeit blieb begrenzt: Das Dokument war Informational, behandelte Sicherheitsfragen nicht, überließ Aufbewahrung und Betrieb teilweise den Anbietern und dokumentierte den Streit über ein eigenes Protokoll statt vorhandener E-Mail-Infrastruktur.

Ein Empfänger aus mehreren Schichten

Wer empfing eine Funknachricht? Der Gateway-Server, der Paging-Dienst, das Gerät oder der Mensch? Im Alltag konnte jedes Glied das Wort „Empfang“ benutzen. Im Störungsfall musste dagegen klar sein, welcher Teil tatsächlich etwas beobachtet hatte.

RFC 1861 begann mit einer bescheidenen Grenze. Der allgemeine Code 250 bestätigte, dass der Server einen Befehl erfolgreich verarbeitet hatte. Eine Pager-Kennung oder ein Nachrichtentext konnte angenommen sein, ohne dass ein Funksignal das Feldgerät erreicht hatte.

Im Zweiwegmodus unterschied PAGEr weiter. 850 meldete ein erreichbares Gerät und eine angenommene Transaktion. 950 meldete ein nicht erreichbares Gerät, dessen Nachricht für später in eine Warteschlange kam. 750 lehnte die Transaktion ab. Die Antworten standen an derselben Stelle im Ablauf, eröffneten aber verschiedene Handlungen: fortfahren, aufschieben oder einen anderen Kanal wählen.

Das Gateway gewann durch die Annahme keine Vollmacht über die nachgelagerten Tatsachen. Seine Meldung war verlässlich, wenn sie klein blieb.

Der Rückweg verlängerte die Geschichte

SNPP entwickelte sich in weniger als zwei Jahren. RFC 1568 beschrieb im Januar 1994 eine frühe Einwegfassung. RFC 1645 ersetzte sie im Juli als Version 2. RFC 1861 erschien im Oktober 1995, erklärte RFC 1645 für überholt und fügte Level 3 für bestätigungsfähige Zweiweggeräte hinzu.

Zuvor diente das Protokoll als einfache Schicht zwischen Internet-Clients und TAP/IXO-Pagingterminals. Der Client wählte ein Gerät, lieferte Text und startete den Versand. Das Gateway verbarg ältere Steuerzeichen und terminalbezogene Abläufe.

Mit dem Rückkanal kam menschliche Zeit ins Verfahren. Die Spezifikation stellte fest, dass technische Zustellung und Empfangsbestätigung vergleichsweise vorhersehbar sein konnten. Niemand wusste jedoch, wann der Teilnehmer das Gerät hervorholen, lesen und antworten würde. Eine Telefonverbindung während dieser Wartezeit offen zu halten, konnte teuer werden.

Level 3 machte deshalb die Transaktion dauerhaft, nicht die Verbindung. 2WAY eröffnete einen Vorgang für genau ein Gerät. SEND startete die Nachricht und beendete diese Phase. Später fragte der Client mit MSTAtus nach. Die Akte überlebte die Sitzung.

Vier Familien beschrieben den Abstand zum Ende

Die Statusgruppen folgten dem Grad der Endgültigkeit. 86x bedeutete: zunächst zugestellt, aber eine verlangte Aktion steht aus. 87x bezeichnete eine Zwischenstufe vor dem Abschluss. 88x war endgültig. 96x bedeutete Warteschlange.

Direkt auf SEND konnte 860 folgen: zugestellt, Lesebestätigung offen. 861 hieß: zugestellt, Antwort offen. 880 bedeutete Zustellung ohne ausstehende Antwort. 960 sagte ausdrücklich, dass noch auf Zustellung gewartet wurde.

Spätere Abfragen konnten 870 liefern, wenn gelesen worden war, aber eine Antwort ausstand. 881 bestätigte Zustellung und Lesen. 888 trug eine vorbereitete Auswahlantwort, 889 freien Text. 780 beendete den Vorgang mit Ablauf vor der Zustellung.

Nach einem 88x-Code, so das RFC, sollten keine weiteren Statusänderungen eintreten. Damit hatte „final“ eine prüfbare Bedeutung. Ein Client, der 860 bereits als abgeschlossen zeigte, unterschlug die angeforderte Lesebestätigung. Wer 960 zu „zugestellt“ umbenannte, machte aus einer künftigen Absicht einen gegenwärtigen Erfolg.

Lesen war keine Antwort

Mit ACKRead 1 verlangte der Client eine Meldung in dem Moment, in dem der Teilnehmer die empfangene Nachricht tatsächlich betrachtete. Die Spezifikation erklärte diese Funktion ausdrücklich für unabhängig von einer Antwort.

Ein Gerät konnte empfangen, während es unbeachtet lag. Der Mensch konnte lesen und schweigen, weil er keine Zeit, keine passende Auswahl oder keine Befugnis hatte. Diese Zustände waren nicht fehlerhafte Varianten desselben Ereignisses, sondern verschiedene Ereignisse.

RTYPe bestimmte, welche Antwortform erlaubt war: keine, ja/nein, einfache Anbieterantworten, nachrichtenspezifische Mehrfachauswahl oder freier Text. MCResponse legte Auswahlmöglichkeiten fest. Wenn 888 zurückkam, war ein Auswahlcode eingetroffen. Daraus folgte weder informierte Zustimmung noch die Berechtigung, ein Unternehmen zu binden.

Der Rückkanal lieferte bessere Kommunikationsbelege. Er schuf keine institutionelle Vertretungsmacht.

Nicht zu warten konnte zuverlässiger sein

Warteschlangen helfen, wenn ein Gerät vorübergehend keine Funkabdeckung hat. Bei zeitkritischen Alarmen können sie einen klaren Fehler durch eine trügerische Hoffnung ersetzen. Eine spät zugestellte Meldung verbessert die Statistik und verpasst dennoch den Zweck.

NOQUEUE musste vor PAGEr stehen und untersagte die Speicherung für diese Transaktion. War das Gerät offline, folgte eine Ablehnung der 750er-Reihe. Der Absender behielt damit die Entscheidung, ob Verzögerung noch nützlich war. Das Gateway musste Dringlichkeit nicht erraten, sondern eine explizite Grenze beachten.

EXPTag änderte die Ablaufzeit einer wartenden Nachricht. Nach Fristende wurde sie gelöscht und der Status als nicht zugestellt aktualisiert. Standarddauer und Tag-Verfall blieben herstellerabhängig. Gemeinsame Syntax ersetzte also keine lokale Aufbewahrungspolitik.

Nach dem endgültigen Lesen konnte KTAG den Status-Tag entfernen. Zu frühes Löschen zerstört Untersuchungsmöglichkeiten; unbegrenztes Speichern sammelt Lesezeiten, Antworten und womöglich Standortdaten. Das Protokoll bot einen Hebel, aber keine vollständige Regel für seine Verwendung.

Aktenzeichen und PIN blieben begrenzte Mittel

Ein erfolgreicher Zweiweg-SEND gab Message_Tag und Pass_Code zurück. Der Tag fungierte als Aktenzeichen, der Passcode sollte als zufällige PIN die Statusabfrage autorisieren. MSTAtus benötigte beide.

Die Akte enthielt außerdem eine bei Änderungen steigende Sequence sowie Datum und Uhrzeit. Damit ließ sich eine neue Lesung oder Antwort von der wiederholten Anzeige eines alten Zustands unterscheiden. Der Zähler war ein Änderungszeichen, kein versprochenes unveränderliches Journal.

Auch der Passcode darf nicht zu einer Sicherheitsarchitektur hochgeschrieben werden. Der Abschnitt zu Security Considerations sagt nur, dass Sicherheitsfragen in diesem Memo nicht behandelt werden. Verschlüsselung, starke Authentisierung, Rate-Limits, Berechtigungsmodelle oder sichere Speicherung sind nicht belegt. Die historische Darstellung muss diese Lücke stehen lassen.

Gerade weil die Akte Lesezeit und Antwort enthalten konnte, waren Zugriffsfragen wichtig. Präzise Beweise sind empfindlicher, nicht automatisch sicherer.

Auffindbar, ohne den Ort preiszugeben

PING konnte Standort oder Zustand eines Zweiweggeräts ermitteln. Wegen der Sensibilität durfte der Teilnehmer eine allgemeine Antwort wählen: Gerät im System, aber keine Standortinformation verfügbar. Das RFC nannte dies ACLU mode und verwendete 821.

Damit wurden internes Wissen und Offenlegungsrecht getrennt. Ein Dienst konnte den Ort kennen, ohne ihn jedem Fragenden zu nennen. Die Verweigerung der Ortsangabe musste die Erreichbarkeit nicht leugnen.

Offen blieb, wie die Präferenz authentisiert, die Standortdaten geschützt, Ausnahmen genehmigt oder Streitfälle geprüft wurden. 821 begrenzte eine Schnittstelle. Es war keine vollständige Datenschutzordnung. Betreiber, Vertrag und Recht behielten Aufgaben, die SNPP nicht an sich zog.

Die Veröffentlichung entschied den Architekturstreit nicht

Der Autor hielt fest, dass Mitglieder der IESG und die Arbeitsgruppe „822 Extensions“ eine Lösung über die vorhandene E-Mail-Infrastruktur bevorzugten. Sie war weit verbreitet; ein weiteres Protokoll zu verteilen war teuer. Manche Prüfer meinten, sorgfältige Konfiguration könne das geforderte „sofort zustellen oder scheitern“ bereits liefern. Andere wollten Paging-Details eher als SMTP-Erweiterungen.

Der Autor verteidigte ein separates Protokoll, um TAP/IXO und Nachfolger von Benutzern und Mailverfahren abzuschirmen. Mail-zu-SNPP-Gateways blieben möglich. Der Streit betraf also Kosten und die Lage der Komplexität.

Der bibliografische Eintrag des RFC Editor führt RFC 1861 als Informational. Die Nummer bewahrte einen Entwurf und seine Argumente. Sie belegte weder universelle Implementierung noch eine Befugnis, Betreibern die Architektur vorzuschreiben.

Gute Nachweise überschreiten ihren Zeugen nicht

Das Gateway beobachtete Befehle. Der Paging-Dienst beobachtete Warteschlange und Funkweg. Das Gerät konnte Empfang und Betrachtung melden. Der Rückkanal lieferte Auswahl oder Text. Der Client setzte die Veränderungen bis zum Endzustand zusammen. Keine Stelle sah alles.

RFC 1861 machte aus dieser Aufteilung eine Stärke. „Am Gerät zugestellt“ und „vom Menschen noch nicht gelesen“ konnten zugleich wahr sein. Gelesen blieb von geantwortet getrennt. Ablauf blieb ein eigener Abschluss und wurde nicht nachträglich als Erfolg ausgegeben.

Für heutige Belege bleibt die Prüffrage: Wo zugestellt, durch wen beobachtet, welche Anforderung noch offen, unter wessen Kontrolle gespeichert? Ein Register gewinnt Vertrauen, wenn es eng antwortet. Es verliert es, wenn sein Betreiber aus einem technischen Zwischenstand menschliche Aufmerksamkeit, Zustimmung, Autorität oder tatsächliche Wirkung ableitet.

Quellen