Zusammenfassung

  • RFC 2234 machte ABNF zu einem eigenständigen Dokument, nachdem Internet-Spezifikationen jeweils eigene Definitionen der Notation enthielten.
  • Eine gemeinsame Grammatik erleichtert Verweise und Regelkombinationen; sie beweist nicht, dass verschiedene Implementierungen ein Protokoll gleich auslegen.

Eine Spezifikation konnte festlegen, wie Protokollnachrichten aufgebaut sind, und zugleich die Notation erläutern, mit der diese Regeln beschrieben werden. RFC 2234 blickt auf den Grund dafür zurück: In den frühen ARPANET-Jahren enthielt jede Spezifikation ihre eigene ABNF-Definition. Die E-Mail-Spezifikationen RFC 733 und später RFC 822 wurden zu häufig herangezogenen Referenzen. Eine allgemeine Erklärung der Grammatik in einem einzelnen Protokolldokument zu verstecken, war dennoch ein Umweg für alle, die das Sprachsystem selbst nachschlagen wollten.

RFC 2234 erschien im November 1997 und löste die Definition heraus, damit andere Spezifikationen sie bei Bedarf gezielt zitieren konnten. Das bedeutete nicht, dass das Internet einen einzigen Parser einführte. Es schuf vielmehr einen gemeinsamen Bezugspunkt für Regelnamen, Terminals, Wiederholungen, Alternativen, Zahlenbereiche und Gruppierung. ABNF beschreibt eine Syntax – also welche Zeichenfolgen eine Regel zulässt. Sie belegt nicht, was ein tatsächlich eingesetztes Programm akzeptiert.

Die Ebenen müssen auseinandergehalten werden: ABNF beschreibt Syntax, die Protokollspezifikation wählt die Regeln für ihre Nachrichten, die Übertragungsumgebung legt die externe Kodierung der Terminalwerte fest, und Parser setzen diese Entscheidungen um. RFC 2234 sagt ausdrücklich, dass dieselbe Grammatik verschiedene externe Kodierungen haben kann, und behandelt deren Details als außerhalb des ABNF-Umfangs. Die Notation konnte also zwischen Protokollen wiederverwendet werden, ohne alle Fragen zu den übertragenen Bytes selbst zu entscheiden.

Regeln lassen sich auch in Teilen zusammensetzen. Der Operator =/ fügt einer andernorts definierten Regel weitere Alternativen hinzu. RFC 2234 nennt unabhängige Spezifikationen, die von einem gemeinsamen Regelsatz ausgehen, als möglichen Anwendungsfall. Das ist ein Mittel zur Dokumentkomposition, keine Anweisung an Parser, Erweiterungen zur Laufzeit automatisch zu entdecken. Die Autoren müssen weiterhin angeben, welche Dokumente die Regel zusammensetzen und wo ihre Grenzen liegen.

Das ist eine begrenzte Form der Internet-Koordination: ein gemeinsames Vokabular zum Schreiben von Regeln, getrennte Regeln für einzelne Protokolle und sichtbare Entscheidungen zur Kodierung. RFC 2234 beseitigte Meinungsverschiedenheiten nicht dadurch, dass es sie benannte; es machte eine Ebene davon leichter auffindbar. Die Folgeversionen – RFC 4234 und danach RFC 5234 – zeigen zudem, dass eine gemeinsame Sprache überarbeitet werden kann. RFC 7405 befasste sich später mit UTF-8-bezogener Syntax; diese Änderungen dürfen nicht rückwirkend in den Text von 1997 hineingelesen werden.

Die Geschichte handelt also nicht davon, dass Prosa durch Mathematik ersetzt wurde. Prosa erklärt weiterhin Zweck und Kontext eines Protokolls; Grammatik fasst seine Form knapp. Der wichtige Schritt war, die Definition der Grammatik nicht mehr in jedes Protokolldokument einzubetten, das sie verwendete. Wiederverwendung bekam einen klar zitierbaren Bezugspunkt. Aussagen über Implementierungen brauchen weiterhin Belege aus den Implementierungen selbst.

Quellen: RFC 2234; Datatracker-Eintrag zu RFC 2234; Datatracker-Verlauf von RFC 2234; RFC-Editor-Eintrag zu RFC 2234; RFC 733; RFC 822; RFC 4234; RFC-Editor-Eintrag zu RFC 4234; RFC 5234; RFC-Editor-Eintrag zu RFC 5234; RFC 7405; RFC 2119; Lu Heng zur Priorität laufenden Codes; Lu Heng zur minimalen Anfangsspezifikation; Lu Heng zu Realitätsebenen.