Zusammenfassung

  • RFC 5242 ist eine beständige Veröffentlichung der RFC Series. Metadaten und IESG Note kennzeichnen sie jedoch als informativen Humor, nicht als IETF-Dokument oder Normkandidaten, und als unvollständig.
  • Die Nummer beantwortet, welches Dokument gemeint ist. Status, Stream, institutionelle Hinweise, Version, Code und Einsatz sind eigenständige Tatsachen.

Eine genaue Quellenangabe mit falscher Wirkung

In einer Anforderung steht: „Zeichenverarbeitung gemäß RFC 5242.“ Die Nummer verweist auf einen echten Text. Dieser vereinigt visuell ähnliche Formen, baut Buchstaben aus Linien und Modifikatoren und begründet 23-Bit-Zeichen damit, dass 3 und 23 Primzahlen seien — anders als 42. Die Mailingliste nutzt eine offenkundig erfundene Domain; das Datum ist der 1. April.

Die Einordnung hängt nicht vom Humorverständnis ab. Die Informationsseite trägt humor. Der Status ist Informational. Die IESG Note sagt, es handle sich nicht um ein IETF-Dokument, es komme für keine Stufe des Internet Standards infrage, habe keine IETF-Prüfung auf Einsatzrisiken erhalten und sei vorsichtig zu bewerten. Der Abstract nennt die Spezifikation unvollständig.

Ein Katalog mit Nummer und Titel behält damit den prestigeträchtigen Teil und entfernt den Teil, der seine Reichweite bestimmt.

Die Nummer leistet echte Arbeit

Sie schafft stabile Identität, kanonisches Archiv und dauerhafte Zitierbarkeit. Daraus folgt keine Zertifizierung. RFC 5242 zeigt gerade, dass starke Dokumentidentität und ausdrücklich fehlende Normautorität nebeneinander bestehen.

Die RFC Series umfasst mehrere Streams und Kategorien. RFC 4844, 5741, 7841 und 8729 machen Herkunft und Status sichtbar. Standards Track, Best Current Practice, Experimental und Informational sind keine austauschbaren Etiketten.

Die Nummer beantwortet „welcher Text?“. Status und Veröffentlichungsweg beantworten „durch welches Verfahren und mit welchem Anspruch?“. Eine IESG Note kann den Anspruch weiter einschränken. Updates und Obsoletes ordnen Nachfolger zu. Keines dieser Felder beweist laufenden Code.

Veröffentlichung ist nicht Betrieb

Der RFC Editor traf eine dokumentierte redaktionelle Entscheidung. Das ist kein IETF-Konsens. Selbst ein formaler Standard beweist keine interoperable Implementierung. Implementierung beweist keine Verbreitung; Verbreitung beweist keine Sicherheit oder Wirkung.

Für RFC 5242 nennen die Quellen kein Produkt, keinen Betrieb, keinen Vorfall und keine Messung. Sie als praktische Alternative zu Unicode oder IDNA darzustellen, würde fehlende Betriebsdaten erfinden.

Entscheidungssysteme sollten Nummer, Titel, Datum, Kategorie, Stream oder Publikationsweg, explizite Hinweise und Nachfolgebeziehungen gemeinsam anzeigen. Für kritische Nutzung kommen Prüfnachweis, Vollständigkeit, Implementierungstest und Deployment-Beleg hinzu.

Benutzeroberflächen können Autorität waschen

Suchmaschinen stellen Nummer und Titel vor die Warnung. Automatische Zusammenfassungen übernehmen die Kodierregeln und lassen die IESG Note aus. Einzelne Aussagen bleiben texttreu, während die institutionelle Schlussfolgerung falsch wird.

Der Qualifikator gehört neben das Zitat: „RFC 5242, Informational-Humor; kein IETF-Dokument“ ist nicht dieselbe Behauptung wie die nackte Nummer.

Die IESG Note verweist auf RFC 4690 zu sprachlichen, betrieblichen und sicherheitsbezogenen IDN-Fragen. RFC 3490 definierte IDNA2003 und wurde durch IDNA2008 einschließlich RFC 5890 und 5891 ersetzt. Unicode pflegt eigene Versionen. RFC 5242 nutzt diesen Kontext, erbt aber nicht dessen Autorität.

Eine belastbare Autoritätskette hält sechs Belege auseinander: Identität; Status und Herkunft; institutionelle Note; Version und Nachfolge; Implementierung; Betrieb und Ergebnis. Lu Hengs überprüfbare Wirklichkeit verlangt, dass ein angesehenes Etikett nie weiter reicht als der zurechenbare Prozess und die beobachtete Wirkung.

Quellen