Primäre Domain
Infrastruktur
Innerhalb der Facette Primäre Domain bündelt Infrastruktur die Berichterstattung nach primärem Themenbereich, sodass Leser einen fokussierten Bereich der Internetinfrastruktur, Governance, Konnektivitätsmärkte oder des digitalen Kapitals verfolgen können. Die Seite führt verwandte Artikel, öffentliche Belege, Institutionen, Unternehmen, Personen, regionale Verflechtungen, operative Abhängigkeiten und Marktkontext zusammen, die sonst über verschiedene Kategorieseiten verstreut wären. Sie erläutert den Themenbereich, die wahrscheinliche Akteursgruppe, den Markt- oder Governance-Kontext und das Quellenmaterial, das Leser beim Vergleich von Signalen heranziehen sollten. Betreiber, Analysten und mit Governance befasste Leser können erkennen, wie derselbe Themenbereich in Ereignissen, Profilen, Marktveränderungen, Belegen aus öffentlichen Quellen, regionalen Abhängigkeiten und langfristigen Infrastrukturentscheidungen immer wieder auftaucht.
Geschichte
Im RFC stand 37. Das laufende Netz verstand 38: RFC 3115
Im Jahr 2001 vergaben ein Standards-Dokument und das IANA-Register verschiedene Nummern für dieselben Mobile-IP-Erweiterungen. RFC 3115 folgte den Werten, die Implementierungen bereits verwendeten.
Geschichte
Das Passwort stimmte. Der Benutzer war noch nicht authentifiziert: RFC 3112
RFC 3112 gab LDAP eine Methode, ein Passwort mit einem abgeleiteten Verzeichniswert abzugleichen. Zugleich begrenzte das Dokument die Aussage: Ein Treffer machte die LDAP-Assoziation noch nicht authentifiziert.
Geschichte
Beide Schichten sagten „vorwärts“ und meinten entgegengesetzte Richtungen: RFC 3108
RFC 3108 beschrieb einen Fehler, den ein Parser nicht erkennen konnte: Call Control und ATM-Bearer-Signalisierung benutzten dasselbe Richtungswort, maßen aber von verschiedenen Endpunkten aus.
Geschichte
Das Gateway verlieh die Adresse, Lokalität wurde zum Protokoll: RFC 3102
Realm Specific IP wollte Adressenteilung nicht vollständig in einem unsichtbaren Übersetzer verbergen. Der private Host erhielt öffentliche Parameter und setzte sie selbst ein. Die Adresse wanderte zum Host; Pool, Laufzeit, Richtlinie und Rückweg blieben beim Gateway.
Geschichte
DHCP-Authentifizierung blieb innerhalb der Vertrauensdomäne: RFC 3118
RFC 3118 ergänzte DHCP um Authentifizierung, schuf aber keine netzweite Identitätsinstanz. Das verzögerte Verfahren setzte voraus, dass Client und Server innerhalb derselben Verwaltungsdomäne über einen getrennten Kanal ein gemeinsames Geheimnis erhielten; ob ein nicht…
Geschichte
Bevor Einwilligung zum Kontrollkästchen wurde: RFC 3098
RFC 3098 machte aus Verantwortung ein Betriebsmodell: keine automatische Anmeldung, klare Datennutzung, Bestätigung mit Herkunft, erreichbarer Austritt und Listenkosten bei dem Akteur, der den kommerziellen Nutzen suchte.
Geschichte
ROHC begann ohne Rückkanal: RFC 3095
Bevor ROHC einer Bestätigung vertrauen konnte, musste es dort funktionieren, wo keine Antwort zurückkam. RFC 3095 ließ deshalb jeden Kontext im unidirektionalen Modus beginnen und gab dem Dekompressor das Recht, den optimistischen oder zuverlässigen Modus anzufordern.
Geschichte
TALI durfte nicht annehmen, dass der Partner Version 2 beherrschte: RFC 3094
Bevor ein TALI-2.0-Gateway neue Verwaltungsoperationen senden konnte, musste es wissen, was die Gegenstelle verstand. RFC 3094 macht diese Aushandlung zur Protokollregel und veröffentlicht den Vorschlag des Herstellers mit einem ungewöhnlich klaren Hinweis, dass das IETF keine…
Geschichte
Foo stand in den RFCs, bevor es erklärt wurde: RFC 3092
RFC 269 benannte 1971 eine Datei von `FOO` in `BAR` um und setzte voraus, dass beide Wörter als austauschbare Beispiele erkannt würden. Dreißig Jahre später zählte RFC 3092 die Konvention in fast sieben Prozent der Reihe. Erst nach der Verbreitung bekam sie eine öffentliche…
Geschichte
Die Pi-Multicastgruppe war keine IPv4-Adresse: RFC 3091
RFC 3091 stellte sich vor, dass Clients π aus einem Datenstrom, einer indexierten UDP-Antwort oder per Multicast zusammensetzen. Doch die angegebene Multicastgruppe ließ sich nicht als gültige IPv4-Adresse darstellen; auch die TCP- und UDP-Ports im selben Dokument passten nicht…
Geschichte
Die Firewall erlaubte HTTP, aber nicht das darin versteckte Paket: RFC 3093
RFC 3093 wollte ein vollständiges IP-Datagramm in eine HTTP-Nachricht legen, durch die Web-Öffnung schicken und hinter der Firewall erneut einspeisen. Der am 1. April 2001 veröffentlichte komische Entwurf machte eine ernste Grenze sichtbar: Die Erlaubnis für den äußeren Umschlag…
Geschichte
Dieselbe Zone war hier sicher und anderswo unsicher: RFC 3090
2001 war die Frage „Ist diese DNS-Zone sicher?“ ohne Beobachter unvollständig. Die Antwort hing vom Resolver, seinem Vertrauensanker und dem geprüften Weg ab. RFC 3090 beschrieb diese unbequeme Wirklichkeit: Eine signierte Zone konnte eine lokale Sicherheitsinsel sein und für den…
Geschichte
Der Root-Dienst verwies weiter, statt die Verzeichnisantwort zu liefern: RFC 3088
Ein Verzeichnisserver kann den nächsten Ansprechpartner kennen, ohne den gesuchten Eintrag selbst zu führen. Der OpenLDAP-Versuch von 2001 machte diese Grenze sichtbar: DNS lieferte mögliche LDAP-Ziele, der Root-Dienst gab Verweise zurück, und erst der verwiesene Server sollte…
Geschichte
Die URI wählte das Sprachmenü, authentifizierte aber nicht den Anrufer: RFC 3087
2001 konnte ein SIP-Anruf die Mailbox erreichen, ohne alle verlässlichen Hinweise mitzubringen, aus denen klassische Telefonanlagen die erste Ansage ableiteten. RFC 3087 machte das aktuelle Anfrageziel zur Dienstanweisung. Der Weg bekam Kontext; die Adresse wurde trotzdem kein…
Geschichte
Der Policy-Server schob die Regeln. Beim Wiederverbinden musste noch geklärt werden, was das Gerät behalten hatte: RFC 3084
RFC 3084 behandelte Policy-Provisionierung nicht als bloßen Versand. Eine Gruppe von Änderungen bildete eine Transaktion, das Gerät meldete deren Ergebnis, und ein unmittelbarer Fehler verlangte die Rückkehr zum letzten guten Zustand. Nach einer Verbindungsunterbrechung konnten…
Geschichte
Eine Revisionsnummer konnte ein NewsItem ordnen. Abrufen konnte sie es nicht: RFC 3085
Ein NewsItem konnte an mehreren Orten liegen. RFC 3085 gab ihm eine URN und eine Nummer, die seine eigenen Revisionen ordnete. Zugleich unterschied der Text zwischen einer Aktualisierung des Beitrags und dem Austausch bloßer Verwaltungsmetadaten. Ob jemand den Inhalt damit finden…
Geschichte
Das Kabel verschlüsselte den Verkehr. Seine Verwaltung konnte den Schutz dennoch abschalten: RFC 3083
RFC 3083 machte DOCSIS Baseline Privacy per SNMP sichtbar, einstellbar und rücksetzbar. Das half der Diagnose, eröffnete aber eine zweite Sicherheitsgrenze: Die Schnittstelle, die Schlüsselzustände sah, konnte auch Autorisierung neu starten, Zeiten ändern und Multicast-Zugriff…
Geschichte
TCP war zuverlässig. Ein Kanal konnte die anderen trotzdem aushungern: RFC 3081
RFC 3081 legte eine BEEP-Sitzung auf eine TCP-Verbindung und behandelte anschließend das Problem, das Zuverlässigkeit nicht löste: Ein langsamer Anwendungskanal konnte gemeinsame Kapazität binden und seine Nachbarn am Fortschritt hindern. Über dem zuverlässigen Strom brauchte es…
Geschichte
Die Meldungen liefen ohne Directory Agent weiter. Neue Dienste konnten dennoch unbemerkt bleiben: RFC 3082
RFC 3082 sollte wiederholte Abfragen durch Änderungsmeldungen ersetzen. Das Wiederanlaufverfahren macht eine feinere Asymmetrie sichtbar: Bereits informierte Service Agents können weiter melden, während ein neu hinzukommender Agent womöglich nie erfährt, dass jemand zuhört.
Geschichte
Eine Verbindung war kein Gespräch: RFC 3080
Bei BEEP konnte die Verbindung fehlerfrei sein, obwohl noch keine Anwendung miteinander sprach. RFC 3080 gab Kanal null eine schmale Aufgabe: Profile ankündigen, Kanäle öffnen und schließen. Erst ein angenommenes Profil verlieh einem Anwendungskanal Bedeutung.