Zusammenfassung

  • Der IESG stellte am 3. September 2026 fest, dass die unabhängige Safe-IOC-Einreichung nicht mit IETF-Arbeit kollidiert. Diese RFC-5742-Feststellung ist weder technische Billigung noch IETF-Konsens oder RFC-Veröffentlichung.
  • Version 13 definiert eine kanonische, umkehrbare Darstellung. Ob sie inaktiv bleibt, entscheidet trotzdem jeder nachgelagerte Parser, Renderer, Previewer, Resolver und Deobfuscator. Diese Aktivierungshoheit muss pro Übergang belegt werden.

Die IETF-Mitteilung gibt das Ergebnis des Conflict Review wieder. Nach RFC 5742 prüft der IESG bei Independent-Stream-Arbeiten Konflikte mit dem IETF-Standardisierungsprozess. Wird kein Konflikt gefunden, bleiben technische Bewertung und Publikationsentscheidung im unabhängigen Verfahren. Der Datatracker-Eintrag bezeichnet das Dokument als individuelles Internet-Draft im Independent Submission Stream mit beabsichtigtem Informational-Status. Version 13 trägt das Datum 4. September und hatte noch keine RFC-Nummer.

Die RFC-Editor-Erläuterung sagt ausdrücklich, dass Independent-Stream-RFCs keinen Community-Konsens benötigen oder verkörpern und weder Standards noch Best Practices sind. Aus „kein Konflikt“ darf deshalb kein Zertifikat für lokale Produkte werden.

Der Text der Version 13 beseitigt eine echte Mehrdeutigkeit. Teams haben Schemes und Punkte bisher in vielen Varianten verändert. Safe-IOC schreibt eine Reihenfolge vor, kapselt das Scheme, verändert strukturelle Trennzeichen in userinfo und host und behandelt bereits transformierte Tokens als undurchsichtig. Eine zweite Ausführung erzeugt somit keine weiteren Klammern: Die Vorwärtsoperation ist idempotent.

Die Rückrichtung stellt den aktionsfähigen Wert wieder her. Deshalb darf sie nur in einen nicht ausführbaren Puffer schreiben und nicht in eine Browser-Vorschau, ein Live-Dokument, einen Rich-Text-Editor oder einen Kontext, der automatisch auflöst, ausführt oder einen Link erzeugt. Ein Rollback kann genau diese Zielklassifizierung ändern, ohne die sichtbare Betriebsanweisung zu verändern.

RFC 3986 liefert die strukturelle Grenze. Ein percent-encoded Punkt im Host ist nicht reserviert und kann vor der Transformation normalisiert werden. Encodierte reservierte Trennzeichen müssen dagegen erhalten bleiben. Nach der Umkehr kann der Wert semantisch gleich, aber nicht bytegleich sein. Wer die Quelle überschreibt, verliert forensische Vergleichbarkeit.

Auch verschachtelte Indikatoren erfordern mehr als Suchen-und-Ersetzen. Ein Redirect-Ziel kann in einer Query stecken. Path, Query und Fragment dürfen nicht pauschal verändert werden, weil dieselbe Interpunktion gewöhnliche Daten sein kann. Nur als vollständige Indikatoren erkannte Spans werden rekursiv behandelt. Damit werden Parser-Version und Grammatik selbst zu kontrollierten Abhängigkeiten.

Teilformen erzeugen falsche Sicherheit. Ein aktives Scheme mit geklammerten Host-Punkten kann weiterhin Linkifizierung auslösen. Die Altformen hxxp und hxxps stehen syntaktisch an der Scheme-Position. Ihre provisorischen Einträge im IANA-Register unter dem Rahmen von RFC 7595 sind keine Auflösungsbefugnis. Das Draft untersagt, obfuskierte Formen als auflösbar zu behandeln.

Die Darstellung beweist zudem nicht die Qualität des Indikators. RFC 9424 trennt Entdeckung, Bewertung, Weitergabe, Deployment, Erkennung, Reaktion und Lebensende. Adressen können veralten, doppelt genutzt oder falsch zugeordnet sein. RFC 7970, STIX 2.1 und TAXII 2.1 tragen Kontext und Austauschzustand, den Klammern nicht ersetzen. Empfang ist nicht Installation; Installation ist nicht Beobachtung oder Wirkung.

Tests sollten die reservierten Namen aus RFC 2606 verwenden. Running-Code Primacy verlangt Belege aus dem tatsächlich laufenden Parser. Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption erlaubt eine dünne gemeinsame Form mit lokalen Aktivierungsentscheidungen. On Reality Layers, Symbolic Power, and Why Clarity Feels So Hostile trennt das inaktive Symbol vom realen Request.