Profil
Research
Research Profilanalyse verbindet die Berichterstattung über Personen, Unternehmen, Institutionen und weitere Entitäten für Leser, die die Subjekte hinter der BTW.MEDIA-Berichterstattung vergleichen. Die Seite hilft beim Vergleich öffentlicher Profile, zugehöriger Ereignisse, Evidenzpakete, Rollenwechsel, operativer Präsenz, Governance-Exposition, organisatorischer Verknüpfungen und Marktrelevanz, während Organisations- und Personendatensätze von der gewöhnlichen Nachrichtenchronologie getrennt bleiben. Leser können das Subjekt hinter der Schlagzeile verstehen, die Belege, die dieses Profil stützen, sowie die Infrastruktur- oder Marktbeziehungen, die das Profil relevant machen. Sie sehen, wen oder was das Profil repräsentiert, welche öffentlichen Quellen es stützen, wie es mit Unternehmen, Märkten, Governance-Gremien oder Ereignissen verbunden ist und welche Änderungen weitere Aufmerksamkeit verdienen, während sich das Subjekt weiterentwickelt.
Geschichte
Die Einladung stand im Kalenderobjekt, nicht im Mailkopf: RFC 2447
RFC 2447 verband die Terminprotokolle von iTIP mit dem gewohnten E-Mail-Transport. Das maschinenlesbare Kalenderobjekt lag in einem MIME-Teil `text/calendar`; dessen Parameter `method` musste mit dem inneren `METHOD` übereinstimmen. Ein Klartextteil durfte Menschen helfen, die…
Geschichte
Der Suffix verriet das Trägermaterial, nicht den Auftrag: RFC 3023
Ein System konnte `+xml` erkennen und einen allgemeinen XML-Parser wählen. Ob das Dokument eine Rechnung, eine Grafik oder eine Anweisung war und ob es wirken durfte, blieb Sache des vollständigen Medientyps.
Geschichte
RFC 2446 und iTIP: Warum ein Gegenvorschlag noch keinen neuen Kalendertermin schafft
Kalender wirken im Alltag wie einfache Listen bestätigter Termine. RFC 2446 zeigt jedoch, dass hinter einer Einladung eine Folge getrennt zu betrachtender Zustände und Entscheidungen liegt. Besonders deutlich wird das beim iTIP-Verfahren COUNTER: Ein Attendee kann eine…
Geschichte
Zwei Endpunkte mussten sich einigen, bevor zwei Adressen eingespart waren: RFC 3021
Die Buchhaltung eines `/31` war einfach: zwei statt vier IPv4-Adressen pro nummerierter Punkt-zu-Punkt-Verbindung. Technisch real wurde die Einsparung erst, wenn beide Router dieselben Bitmuster als Hosts behandelten.
Geschichte
Drei Leitungen liefen. Der Verbund blieb trotzdem unten: RFC 3020
Bei Multilink Frame Relay war der Zustand eines logischen Bündels keine bloße Summe seiner Leitungen. RFC 3020 ließ den Betreiber festlegen, ob eine, alle, eine bestimmte Zahl oder eine implementierungsspezifische Bedingung genügten. Erst diese Regel gab dem Wort up seine…
Geschichte
Die Tabelle meldete Mitglieder. Der Manager konnte die Zeile selbst angelegt haben: RFC 3019
RFC 3019 machte IPv6-Multicast-Mitgliedschaft über SNMP sichtbar. Dieselbe MIB erlaubte aber auch das Anlegen und Löschen von Cache-Zeilen, lokale Mitgliedschaft und Änderungen an Timern. Die Zeile belegte Agentenzustand, nicht unabhängig einen entfernten Empfänger oder eine…
Geschichte
Ein Einmalpasswort schützte die Sitzung nicht: RFC 2444
RFC 2444 machte das Einmalpasswort zu einem benannten SASL-Mechanismus, den Netzwerkprotokolle aufrufen konnten. Damit wurde der Authentisierungseinstieg klarer; die folgende Kommunikation wurde weder verschlüsselt noch der Server beglaubigt.
Geschichte
Der Befehlssatz war atomar. Seine Fernwirkung hatte keinen allgemeinen Rückweg: RFC 3018
UMSP legte Speicher, Code und Kontrollfluss verschiedener Rechner in einen 128-Bit-Adressraum. Eine Transaktion konnte ihre Befehle gemeinsam freigeben; bereits ausgeführte Sprünge, Aufrufe und Schreibvorgänge konnte das Protokoll nicht gemeinsam zurückholen.
Geschichte
Die Replikate waren sich einig. Die Clients mussten trotzdem zurückkehren: RFC 2443
Ende der 1990er-Jahre konnte ATM IP-Multicast transportieren. Ein Client brauchte jedoch weiterhin einen Dienst, der Gruppen und ihre Mitglieder kannte. RFC 2443 verteilte diesen Zustand auf mehrere MARS-Server. Die entscheidende Regel zeigte sich im Fehlerfall: Wenn der…
Geschichte
Das Telefonbuch hatte die höhere Version. Der Einwahlzustand blieb unbelegt: RFC 3017
Eine größere Zahl konnte einen geänderten Bestand anzeigen. Sie bewies weder die richtige Ausgabe noch einen atomaren Import und erst recht keinen erreichbaren Point of Presence. RFC 3017 trennte das portable Dokument von jener Betriebskette, die aus Angaben eine funktionierende…
Geschichte
Die MTU war nicht das einzige Maß: RFC 3016 und die Größe eines Verlusts
Ein RTP-Paket kann unter die Path MTU passen und trotzdem einen zu großen Ausfallbereich bilden. RFC 3016 verband syntaktische Hierarchie, Paketgrenzen und gespeicherte Konfiguration zu einer zweiten Größenfrage: Wie viel Bedeutung hängt an genau diesem Datagramm?
Geschichte
Das neue Tag passte ins Paket. Trotzdem konnte es das Protokoll schwächen: RFC 2440
Ein freier Wert im Paketkopf wirkt wie eine Einladung. Die OpenPGP-Spezifikation stellte 1998 die schwierigere Frage: Ein neues Tag lesen zu können, bewies nicht, dass die bezeichnete Funktion sicher mit dem übrigen Kryptosystem zusammenarbeiten würde.
Geschichte
Der Kontext war verbunden. Der Anruf war nicht bewiesen: RFC 3015
Megaco machte die interne Verbindung eines Media Gateways steuerbar und prüfbar. RFC 3015 hielt zugleich die Grenze offen: Lokaler Zustand, transportierte Medien und eine tatsächlich geführte Unterhaltung waren verschiedene Belege.
IETF
Änderbar ist keine Antwort auf die Frage nach dem Berechtigten
Der neue SCHC-Entwurf begrenzt, wie tief eine Kompressionsregel verändert werden darf. Für eine belastbare Freigabe müssen Identität, Objektgrenze, Versionsstand und Aktivierung trotzdem als getrennte Nachweise erhalten bleiben.
Geschichte
Die Meldung ging verloren. Auch das Ersatzprotokoll konnte sie verlieren: RFC 3014
Ein lokales Protokoll sollte auffangen, was ein SNMP-Trap oder -Inform auf dem Weg verlor. RFC 3014 machte aus diesem Auffangnetz keinen Mythos: Es beschrieb zugleich Filter, Rechte, Speichergrenzen, Alterung, Neustarts und die Zähler, die auf Löcher im Netz hinwiesen.
Geschichte
Die Seite wurde schneller; der gemeinsame Link musste trotzdem Rechenschaft ablegen: RFC 2414
1998 konnten zwei TCP-Segmente mehr bewirken, als doppelt so viele Daten wie eines zu transportieren. Das zweite konnte eine Bestätigung auslösen, bevor der verzögerte ACK-Timer ablief. Ein größeres Anfangsfenster war deshalb für kurze Web-Transfers attraktiv – doch die Pakete…
IETF
Der Proxy meldete die Schnittstelle aktiv. Sie hatte nie geantwortet
PROBE kann eine Schnittstelle beschreiben, die vom Messpunkt aus nicht bidirektional erreichbar ist. Dafür wird ein erreichbarer Proxy zum Zeugen. Wer dessen Aussage als Antwort der Ziel-Schnittstelle speichert, macht aus einer nützlichen Beobachtung einen falschen Beweis.
Geschichte
Das Gateway stellte eine Challenge. Vertrauen musste erst noch kommen: RFC 3012
Der Foreign Agent konnte am besuchten Netz einen begrenzten Sachverhalt selbst feststellen: Antwortete die Registrierung auf einen eben ausgegebenen Wert, oder wurde alter Verkehr wiederholt? Für Identität und Zulassung brauchte er weiterhin andere Stellen.
Geschichte
Die Anfrage kam aus einem Subnetz. Die Adresse sollte aus einem anderen stammen: RFC 3011
RFC 3011 machte aus einer stillen DHCP-Annahme eine überprüfbare Entscheidung: Der beobachtete Eingangsweg durfte vom Netz abweichen, in dem eine Adresse verbraucht wurde.
Geschichte
Die DNS-Antwort führte den MAC der Anfrage weiter: RFC 2845
Im Jahr 2000 brauchte DNS eine Möglichkeit, eine Transaktion zu authentifizieren, ohne einen geteilten Schlüssel als öffentliches Identitätssystem auszugeben. RFC 2845 band die Antwort an den MAC der Anfrage und führte einen laufenden MAC über mehrteilige TCP-Antworten fort. So…