Zusammenfassung

  • RFC 7763 erschien im März 2016 als informatives IETF-RFC und registrierte text/markdown. Für diesen Medientyp ist charset erforderlich; variant kann freiwillig die vom Autor gemeinte Syntax bezeichnen.
  • Der Variantenname ist ein Hinweis an den Empfänger. Er darf ihn verwenden, muss es aber nicht. Das begleitende RFC 7764 verzeichnet mehrere Markdown-Spielarten, darunter Original, GFM, CommonMark und Pandoc.
  • IANA führt den Medientyp und ein eigenes Register der Markdown-Varianten. Diese Einträge benennen etwas; sie rendern keine Seite.

Derselbe Quelltext, eine andere Tabelle

Markdown machte Schreiben leicht. Eine Überschrift brauchte nur ein Zeichen, eine Liste wenige Striche. Die Quelle blieb lesbar, und jede Gemeinschaft konnte das Verfahren für ihre Arbeit erweitern. Diese Freiheit schuf zugleich unterschiedliche Lesarten. Eine Zeile mit senkrechten Balken ist in einem Programm Teil einer Tabelle, in einem anderen bloßer Text. Solange Autor und Publikum dasselbe Programm benutzen, fällt die Abweichung kaum auf. Beim Wechsel des Systems steht sie plötzlich auf der Seite.

Nehmen wir eine Arbeitsanweisung mit einer Tabelle aus Zuständigkeiten und Fristen. Das Archiv überträgt die Datei exakt; Hash und Dateigröße stimmen. Die neue Veröffentlichung zeigt die Balken jedoch wörtlich. Nun muss der Leser erraten, welcher Termin zu welcher Aufgabe gehörte. Der Fehler liegt jenseits der üblichen Dateiintegrität. Ein Verzeichnis voller unveränderter Quellen kann eine Sammlung veränderter Seiten liefern.

Das RFC 7764 hält fest, wie vielfältig Markdown bis 2016 geworden war. Es führt die Arbeit von John Gruber und Aaron Swartz aus dem Jahr 2004 als Ausgangspunkt an und beschreibt Original, GFM, CommonMark, Pandoc sowie weitere Varianten. Seine GFM-Beschreibung nennt unter anderem Tabellen, eingerahmte Codeblöcke und automatisch erkannte Webadressen. Jede solche Funktion ist eine Entscheidung darüber, welche Rolle ein Zeichen im fertigen Dokument spielt.

Das Etikett am Transportweg

RFC 7763 löste zunächst die Identitätsfrage. Ein HTTP-Server oder Mailprogramm konnte text/markdown melden, statt den Typ aus der Endung .md erraten zu lassen. Die Registrierung verlangt charset. Der Empfänger muss die Bytes zu Zeichen dekodieren, bevor er Überschriften oder Tabellen erkennen kann. Einen voreingestellten Zeichensatz setzt das RFC für diesen Medientyp nicht fest.

Dann folgt die eigentliche Streitfrage: Welche Markdown-Grammatik meinte der Verfasser? Der optionale Parameter variant kann eine Antwort mitgeben. Content-Type: text/markdown; charset=UTF-8; variant=Original nennt Familie, Zeichensatz und beabsichtigte Spielart. Ohne variant entscheidet der Kontext des Empfängers. Mit variant erhält der Empfänger einen Hinweis. Das RFC lässt ihm die Wahl, ob er die benannte Variante verwendet.

Ein sauber ausgefüllter Header verleiht einem Programm keine fehlende Fähigkeit. Wer eine Tabelle in einer Variante verschickt, die die Gegenseite nicht beherrscht, bekommt aus der Registrierung allein keine kompatible Darstellung. Deshalb rät RFC 7763 bei wichtiger Autorenabsicht zu Varianten, die der Empfänger tatsächlich kennt. Ein gemeinsamer Name hilft beim Aushandeln; die Funktion muss auf beiden Seiten laufen.

Das Etikett kann auch unterwegs abfallen. RFC 7764 behandelt die Frage, wie Varianteninformationen erhalten bleiben, wenn Inhalte einen Transport mit Medientyp-Parametern verlassen. Eine isolierte .md-Datei enthält ihren Text, aber nicht zwingend den früheren Content-Type. RFC 7763 empfiehlt, variant und weitere einschlägige Parameter zusammen mit dem Inhalt zu speichern. Sonst bleibt im Archiv die Quelle und verschwindet die Anleitung zu ihrer Auslegung.

Ein Register ist kein Parser

IANA listet text/markdown als Medientyp. Daneben stehen in einem separaten Variantenregister Namen wie Original, GFM, CommonMark und Pandoc. Die Anmeldung erfolgt dort nach dem Prinzip „wer zuerst kommt“. Das schafft eindeutige Bezeichnungen für Gespräche zwischen Systemen. Welche der Regeln ein konkretes Programm ausführt, steht in seinem Code und in seiner Version.

Ein Betreiber sollte daher zwei Proben unterscheiden. Die Dateiprüfung beantwortet, ob alle Zeichen angekommen sind. Die Rendering-Prüfung beantwortet, ob Tabellen, Links, Überschriften und Codeblöcke die beabsichtigte Struktur behalten. Ein Umzug ist erst überzeugend, wenn beide Ergebnisse passen. Die Formulierung „Markdown wird unterstützt“ ist ohne Varianten- und Versionsangabe zu billig.

Die vier hier verwendeten Originalquellen belegen Regeln und Register. Für Aussagen über die Einführung durch ein bestimmtes Produkt wären datierte Handbücher, Quellcode-Releases oder aufgezeichnete HTTP-Antworten nötig. Der historische Befund von 2016 ist bereits präzise: Die Familie erhielt einen Namen auf dem Draht, während die Leseentscheidung im empfangenden Programm blieb.