rfc·explained

RFC 2119 · · Best Current Practice

MUST, SHOULD und MAY, ein für alle Mal definiert.

Der offizielle Titel lautet "Key words for use in RFCs to Indicate Requirement Levels." Worüber der RFC wirklich entscheidet: dass MUST, SHOULD oder MAY in Großbuchstaben eine exakte, verabredete Bedeutung tragen statt der üblichen englischen Unschärfe.

Status
✓ Weiterhin gültig
Auch bekannt als
BCP 14
Aktualisiert durch
RFC 8174

Geschrieben von Noel Lang · IT-Trainer

Kurzfassung

RFC 2119 ist das Wörterbuch, mit dem jeder andere RFC geschrieben ist. Er legt drei Anforderungsstufen fest: MUST (absolut, keine Ausnahmen), SHOULD (tu es, außer du kannst begründen warum nicht) und MAY (echt optional), dazu ihre Verneinungen und ein paar Synonyme. Veröffentlicht als BCP 14 und aktualisiert durch RFC 8174, das die Regel ergänzte, dass nur die großgeschriebenen Wörter binden.

Welches Problem er löst

Normales Englisch ist für ein Protokoll zu vage. Wenn eine Spec sagt, eine Implementierung “should” eine Signatur prüfen, heißt das, sie muss es, oder wäre es nur nett? Zwei Hersteller lesen denselben Satz, ziehen entgegengesetzte Schlüsse und liefern Produkte aus, die sich weigern, miteinander zu reden. Genau das untergräbt den ganzen Sinn eines Standards.

RFC 2119 nimmt das Raten heraus, mit einem winzigen, festen Vokabular. Sobald alle einig sind, dass MUST absolut ist, SHOULD eine Empfehlung mit dokumentiertem Notausgang und MAY wirklich optional, lässt sich eine Spec von jeder Implementiererin der Welt gleich lesen. Der RFC ist drei Seiten lang und klammheimlich tragend für das gesamte Standard-Ökosystem.

Die Analogie mit der Bauordnung

Stell dir eine Spezifikation als Bauordnung vor, denn Bauordnungen sprechen bereits in genau diesen drei Tonlagen. Manche Regeln sind Gesetz: ein Notausgang ist nicht verhandelbar, und ein Prüfer, der keinen findet, lässt dich durchfallen. Das ist MUST. Manche Regeln sind starke fachliche Vorgabe: Rauchmelder gehören in Schlafzimmernähe, und abweichen darfst du nur, wenn du einen echten Grund nennen und zeigen kannst, dass du es durchdacht hast. Das ist SHOULD. Und manche Entscheidungen sind einfach deine: streich die Wände, in welcher Farbe du willst. Das ist MAY.

Der Wert der Bauordnung liegt nicht darin, dass sie Regeln aufzählt. Er liegt darin, dass jeder Lesende auf einen Blick weiß, in welcher Tonlage jede Regel geschrieben ist. RFC 2119 gibt Spec-Autoren diese drei Tonlagen und gibt Lesern die Legende dazu.

Die drei Anforderungsstufen

Ein Vokabular, drei Verpflichtungsstärken. Alles andere in RFC 2119 ist ein Synonym oder eine Verneinung davon:

  • MUST · MUST NOT REQUIRED · SHALL · SHALL NOT

    Absolut. Kein Ermessensspielraum. Um konform zu sein, tust du es (oder lässt es garantiert). Verletzt du ein MUST, ist deine Implementierung schlicht nicht konform. Alltagsversion: ein Gebäude MUSS einen Notausgang haben. Den Prüfer interessieren deine schönen Gründe nicht.

  • SHOULD · SHOULD NOT RECOMMENDED · NOT RECOMMENDED

    Tu es, außer du kannst begründen warum nicht. Die Vorgabe ist ja; abweichen darfst du nur, nachdem du die vollen Folgen verstanden und abgewogen hast. Alltagsversion: Rauchmelder SOLLEN in Schlafzimmernähe hängen. Du darfst sie woanders anbringen, aber dann besser mit dokumentiertem Grund.

  • MAY OPTIONAL

    Wirklich deine Entscheidung. Es einzubauen und es wegzulassen sind beide voll konform. Ein Hersteller liefert es aus, ein anderer nicht, und keiner liegt falsch. Alltagsversion: du DARFST die Wände streichen, in jeder Farbe. Dafür fällt dich niemand durch.

Balkenlänge ≈ wie bindend die Stufe ist, von absolut (MUST) bis voll optional (MAY).

Das SHOULD, über das alle stolpern

Wenn du dir eine Sache merkst, dann diese: SHOULD heißt nicht optional. Es ist das meistmissverstandene Wort im ganzen Vokabular. SHOULD heißt “tu es, außer du kannst wirklich nicht, und wenn du nicht kannst, solltest du genau wissen, worauf du verzichtest”. Der RFC schreibt es aus: triftige Gründe, ein SHOULD zu ignorieren, mögen in bestimmten Fällen existieren, aber die vollen Folgen müssen verstanden und sorgfältig abgewogen werden, bevor du einen anderen Weg wählst.

SHOULD sitzt also zwischen zwei sehr verschiedenen Wörtern. Darüber lässt MUST überhaupt keinen Spielraum. Darunter gibt MAY dir die freie Wahl, ohne Begründung. SHOULD ist die Mitte: ein Standard-Ja, das du überschreiben darfst, aktenkundig, mit offenen Augen. Behandelst du ein SHOULD als “nice to have”, baust du klammheimlich etwas, das die Autoren der Spec von dir nicht erwartet haben.

Das Kleingedruckte von 2017: nur Großbuchstaben zählen

Zwanzig Jahre lang hatte RFC 2119 eine Lücke. Er sagte nie, was passiert, wenn ein Dokument das Wort “must” kleingeschrieben verwendet, in einem gewöhnlichen Satz, ohne normative Absicht. Pedanten stritten. Im Mai 2017 schloss RFC 8174 das Loch mit einer einzigen Regel: die Schlüsselwörter tragen ihre besondere Bedeutung nur, wenn sie komplett großgeschrieben sind. Ein kleingeschriebenes “must” ist einfach Englisch.

Seitdem bilden die beiden Dokumente zusammen BCP 14, und das eine lässt sich nicht korrekt zitieren ohne das andere. Eine Spec, die ihnen folgt, erkennst du an ihrer Boilerplate, einem nahezu identischen Absatz: “The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals.” Wo du diese Zeile siehst, ist jedes großgeschriebene Schlüsselwort darunter ein Versprechen. Alles Kleingeschriebene ist bloß Prosa.

Was der RFC wirklich sagt

Das ganze Dokument ist drei Seiten, und das meiste davon ist das Vokabular selbst. Die Landkarte, falls du vorbeischaust:

Abschnitt In einfachen Worten
1–5 · Die Definitionen Ein nummerierter Abschnitt pro Schlüsselwort: MUST, MUST NOT, SHOULD, SHOULD NOT, MAY. Das ist das ganze Wörterbuch, und es passt auf eine einzige Seite.
6 · Guidance Ein Appell zur Zurückhaltung: setze diese Imperative sparsam ein, nur wo sie wirklich für Interoperabilität oder zur Schadensvermeidung nötig sind. Nicht jeder Satz verdient ein MUST.
7 · Sicherheit Eine kurze Erinnerung, dass Anforderungsstufen sicherheitsrelevant sind: ein leichtfertiges SHOULD, wo ein MUST hingehört, kann ein echtes Loch hinterlassen.

Was Leute falsch verstehen

  • "SHOULD heißt optional."

    Das meistverbreitete Missverständnis. SHOULD ist eine starke Empfehlung mit Notausgang, keine freie Wahl. Die eigenen Worte von RFC 2119: es mag in bestimmten Fällen triftige Gründe geben, es zu ignorieren, aber die vollen Folgen müssen zuvor verstanden und sorgfältig abgewogen werden. Wer ein SHOULD ohne echten, verteidigbaren Grund überspringt, macht es falsch. Das wirklich optionale Wort ist MAY.

  • "Ein kleingeschriebenes must bindet trotzdem."

    Nicht mehr seit RFC 8174 (2017). Nur die großgeschriebenen Formen tragen die besondere Bedeutung. Ein Prosasatz, eine Implementierung "must be fast", ist ganz normales Englisch und stellt keine formale Anforderung. Deshalb schreiben Spec-Autoren nur dort groß, wo sie es auch meinen.

  • "MAY heißt empfohlen."

    Nein. MAY heißt wirklich optional: tu es oder lass es, beides ist konform. Das Wort für "empfohlen" ist SHOULD (oder das wörtliche Synonym RECOMMENDED). Beides zu verwechseln macht aus einer Option eine Pflicht oder umgekehrt, genau die Mehrdeutigkeit, die RFC 2119 abschaffen soll.

  • "RFC 2119 ist nur eine IETF-Sache."

    So fing es an, dann sickerte es überallhin. W3C-Standards, OpenAPI und JSON Schema, Cloud-Anbieter-API-Dokus, interne Engineering-RFCs und sogar Beschaffungsverträge stützen sich heute auf MUST/SHOULD/MAY im Sinne von RFC 2119. Einmal gelernt, liest du sie alle richtig.

Wo dir diese Schlüsselwörter begegnen

RFC 2119 ist der Standard, den du tausendmal gelesen hast, ohne es zu merken. Ein Feldführer:

Du siehst Du schaust vermutlich auf
The key words "MUST", "MUST NOT" ... are to be interpreted as described in BCP 14 Die RFC-2119/8174-Boilerplate. Ihr Vorhandensein sagt dir, dass die großgeschriebenen Schlüsselwörter in diesem Dokument normativ sind, nicht beiläufig.
MUST / SHOULD / MAY in einer OpenAPI- oder JSON-Schema-Beschreibung API-Autoren, die das Vokabular ausleihen, um zu sagen, welche Felder Pflicht, erwartet oder optional sind.
Eine Wand aus großgeschriebenen Schlüsselwörtern in der HTTP-Spec RFC 9110 und Verwandte. Jede Konformitätsregel ist durch genau diese Wörter abgestuft.
MUST / SHOULD in einer CONTRIBUTING.md oder einem internen Style Guide Ein Team, das Anforderungsstufen für seine eigenen Coding-Standards übernimmt, damit ein "SHOULD" im Review anders wiegt als ein "MUST".
shall / shall not in einer ISO-Norm oder einem Vertrag "shall" ist der juristische Urahn von MUST. RFC 2119 führt SHALL als exaktes Synonym, weshalb die Übersetzungspraxis aufgeht.

Fragen, die wirklich gestellt werden

Was bedeutet SHOULD in RFC 2119? +

SHOULD (und sein Synonym RECOMMENDED) heißt: tu es, außer du hast einen triftigen Grund es nicht zu tun, und dann musst du die Folgen vorher vollständig verstehen und abwägen. Es heißt nicht 'nice to have'. Die Standardantwort ist ja, und das Weglassen ist eine bewusste, begründbare Entscheidung, keine freie Wahl.

Was ist der Unterschied zwischen MUST und SHALL? +

Keiner. RFC 2119 führt MUST, REQUIRED und SHALL als exakte Synonyme: alle drei bedeuten eine absolute Anforderung. SHALL ist das ältere, juristischer klingende Wort (verbreitet in ISO-Normen und Verträgen), MUST bevorzugen moderne RFCs. Mischt ein Dokument beide, liest du sie identisch.

Was ist MUST in RFC 2119? +

MUST (auch REQUIRED oder SHALL geschrieben) markiert eine absolute Anforderung der Spezifikation. Um konform zu sein, musst du es tun, ohne Ermessensspielraum. MUST NOT (oder SHALL NOT) ist das Spiegelbild: ein absolutes Verbot.

Zählt ein kleingeschriebenes 'must' in einer Spec als Anforderung? +

Nein. RFC 8174 (2017) hat klargestellt, dass die Schlüsselwörter ihre besondere RFC-2119-Bedeutung nur tragen, wenn sie komplett großgeschrieben sind. Ein kleingeschriebenes 'must' oder 'should' ist ganz normales Englisch und stellt keine formale Anforderung.

Gilt RFC 2119 nur für IETF-Dokumente? +

In der Theorie ja, in der Praxis nein. Er wurde für RFCs geschrieben, aber das Vokabular ist entkommen: W3C-Specs, OpenAPI- und JSON-Schema-Beschreibungen, Hersteller-API-Dokus, interne Engineering-Standards und sogar manche Verträge nutzen MUST/SHOULD/MAY heute im Sinne von RFC 2119. Er ist zum De-facto-Wörterbuch für Anforderungssprache in der Tech-Welt geworden.

Verweise hierher

Andere Erklärseiten auf dieser Website, die auf diesen RFC zurückverweisen:

Wie RFC 2119 zusammenhängt

Womit es zusammenspielt