Zusammenfassung

  • RFC 832 nahm die TCP-Angaben der NIC-Hosttabelle als Behauptungen und protokollierte Telnet-, FTP- und SMTP-Versuche getrennt als nicht angenommen, abgelehnt, unerreichbar, ohne Antwort oder angenommen.
  • Negative Ergebnisse wurden wiederholt; die ganze Erhebung erschien wöchentlich neu. Ein Befund gehörte damit zu Quelle, Pfad und Zeitfenster, nicht dauerhaft zum Wesen des Hosts.
  • RFC 844 erreichte von einem anderen Class-C-Netz nur 127 der zuvor 187 Telnet-Annehmer. Ausführung war stärker als die Liste, bewies aber weder globale Erreichbarkeit noch vollständige Konformität.

Zwei Wahrheiten in derselben Zeile

Grundlage von RFC 832 war die NIC-Hosttabelle vom 2. Dezember 1982. T bezeichnete TCP allgemein, t, f und s Telnet, FTP und SMTP. Die Spalte hieß Claims—Angaben oder Behauptungen.

Daneben standen die Messergebnisse. Ein Host ohne Dienstmarke konnte eine Verbindung annehmen; ein eingetragener Dienst konnte schweigen. Die Gegenüberstellung entzog weder der Registrierung ihren Nutzen noch der Ausführung ihre Eigenständigkeit. Der Datensatz bestimmte, wo geprüft wurde. Er erzeugte das Ergebnis nicht.

RFC 801 zeigt, warum das nötig war. Der Übergangsplan sammelte von Entwicklern gemeldete Implementierungsstände: verfügbar, experimentell, in Arbeit oder geplant. Er warnte, dass diese Informationen schnell altern würden. Außerdem nannte er Abkürzungen, die eine Implementierung nicht nehmen durfte—fehlende Prüfsummenprüfung, fehlende IP-Reassemblierung, keine TCP-Neuordnung, ignorierte Optionen und unbrauchbare Fehlermeldungen.

Eine offene Dienstschnittstelle prüfte diese Anforderungen nicht. Die Smallberg-Erhebung stellte daher eine engere, belastbare Frage: Welches Transportergebnis ist von diesem Ursprung in diesem Zeitraum an diesem bekannten Port zu beobachten?

Ablehnung war nicht Schweigen

Refused bedeutete eine ausdrückliche Zurückweisung durch das Ziel. Unreachable bezeichnete einen Fehler aus dem Pfad. Dead hieß, dass innerhalb der Methode keine brauchbare Antwort kam. Ein leeres Feld behauptete nur, dass keine Annahme beobachtet wurde. Accepted besagte, dass der Verbindungsversuch die definierte Schwelle überschritten hatte.

FTP erhielt accepted+, wenn anonymer Zugriff mit dem Passwort guest funktionierte. Gerade diese Zusatzprüfung begrenzt das gewöhnliche accepted: Es bewies weder Anmeldung noch Übertragung, Nutzen, Identität oder vollständiges Protokollverhalten.

Am 7. Dezember wurde in zwei Zeitfenstern getestet. Als dead, refused oder unreachable erfasste Hosts wurden am 8. Dezember erneut versucht. Die Wiederholung verringerte den Einfluss einer momentanen Störung; sie machte einen Messpunkt nicht allwissend.

Von 315 gelisteten Hosts nahmen 83 Telnet, 70 FTP und 63 SMTP an. Der Rest war keine Liste von Regelverletzern. Spezialrechner mussten die Dienste nicht anbieten, andere waren zeitweise ausgeschaltet oder anders konfiguriert.

Der Nenner hatte eine Versionsgeschichte

RFC 833 wiederholte die Erhebung am 14. Dezember und erklärte, dass doppelte Hosts etwas anders entfernt worden waren. Dadurch änderten sich Zeilensummen. Ohne diese Methodennotiz hätte eine Datenbereinigung wie eine Veränderung des Netzes ausgesehen.

RFC 847 fasste zwölf Erhebungen zusammen. Zwischen dem 7. Dezember und dem 22. Februar stiegen Telnet-Annahmen von 83 auf 190, FTP von 70 auf 181 und SMTP von 63 auf 178. Die Umstellung wurde in erreichbaren Diensten sichtbar.

Die Reihe stieg jedoch nicht jede Woche. Telnet ging im Dezember von 103 auf 102 und 95 zurück. Tabellenstände, Ausfälle, Routen, Testzeiten und Dienstpolitik bewegten die Zahl. Ein produktives Netz ist kein verwalteter Fortschrittsbalken.

Auch RFC 846, die letzte Erhebung, nannte ihre Koordinaten: Hosttabelle vom 18. Februar, Test am 22. von ISI-VAXA und Wiederholung negativer Fälle am 23. Sie erklärte keinen endgültigen Abschluss, sondern veröffentlichte einen neuen Befund.

Ein anderer Ursprung prüfte eine andere Aussage

RFC 843 hatte am 8. und 9. Februar von ISI-VAXA 187 Telnet-Annahmen beobachtet. RFC 844 testete genau diese Menge manuell von einem BBN-Terminalkonzentrator im Class-C-Netz 192.1.2.0/24.

Nun musste nicht nur ein Port lauschen. Gateways brauchten einen Rückweg zum Class-C-Netz, Hosts mussten die Adresse verarbeiten, und ICMP sowie Routing wirkten mit. Nur 127 von 187 wurden OK, 67,9 Prozent.

Die übrigen sechzig verloren dadurch nicht TCP. RFC 844 legte offen, dass nur drei manuelle Durchgänge stattfanden und abgeschaltete Hosts übersehen worden sein konnten. Die erste Messung belegte Annahme aus ISI; die zweite Erreichbarkeit unter zusätzlichen Adress- und Pfadbedingungen. Der Beobachterwechsel änderte die geprüfte Aussage.

Damit wurde eine Grenze zentraler Überwachung sichtbar. Ein ausführbarer Versuch ist überprüfbar, aber er repräsentiert nicht automatisch andere Ursprünge und Wege.

Auch die Zusammenfassung brauchte Herkunft

RFC 847 schätzte 37 Spezial-Hosts, elf Prozent, die nicht alle drei Dienste anbieten sollten. Ein vernünftiges Maximum sei deshalb 89 statt 100 Prozent. Internet-Teilnahme und offenes Telnet waren nicht dasselbe.

Die abgeleitete Tabelle enthält zugleich sichtbare Unstimmigkeiten: 70 von 315 werden als 26 Prozent gedruckt, obwohl es etwa 22 sind; ein Nenner lautet 382 statt 328, ein anderer 389 statt 329; eine Februar-Erhebung von 1983 erhält einmal das Jahr 1982.

Das entwertet die Serie nicht. Es fordert, Zähler, Nenner, Methode und Ursprungserhebung zu behalten. Ein abgeleiteter Fehler ist korrigierbar, wenn seine Herkunft erhalten bleibt. Eine glatte Kennzahl ohne Herkunft verlangt bloß Glauben.

Messmacht blieb begrenzt

Der Beobachter wählte Ports, Zeiten und Ergebniswörter. Der entfernte Betreiber bestimmte Software und Dienstfreigabe und trug deren Folgen. Eine Annahme erlaubte keinen Eingriff am Host; ein Timeout übertrug weder Eigentum noch bewies es Pflichtverletzung.

Laufender Code kann eine Registerangabe disziplinieren, weil andere lokal nachprüfen können. Seine Beweiskraft endet jedoch bei der geprüften Aussage. Ein offener Socket zertifiziert nicht das ganze TCP, authentisiert keinen Betreiber, garantiert keinen Nutzwert und beschreibt nicht alle Pfade.

RFC 832 hinterließ deshalb mehr als eine Zählung: Behauptung, Experiment, typisiertes Ergebnis, Wiederholung und nächste Fassung. Die Bestandsliste sagte TCP; die Messung durfte differenziert antworten.

Quellen und Beweisgrenzen

Diese RFCs dokumentieren Pläne, datierte Angaben, Verbindungsexperimente und eine Zusammenfassung. Sie beweisen weder heutige Verbreitung noch vollständige Konformität, Identität, Berechtigung oder Transaktionsabschluss. Negative Ergebnisse bleiben an Messpunkt, Pfad, Methode und Zeit gebunden.