Der RFC 2119 vom Autor Scott Bradner von der Harvard University in Cambridge, wurde von Jean-Louis Fuchs von der Adfinis SyGroup in die deutsche Sprache interpretiert. Es handelt sich dabei nicht um eine wortgetreue Übersetzung, sondern um eine Interpretation in Deutsch. Das Ziel dieser Interpretation ist es, den RFC 2119 im deutschsprachigen Raum zur Verfügung zu stellen und zu verbreiten.

Der RFC 2119 behandelt die Schlüsselwörter in Dokumenten, um die Anforderung der Spezifikation aufzuzeigen.

Die Originalversion befindet sich auch auf GitHub.

Schlüsselwörter zum Kennzeichnen von Anforderungen

Status dieses Memorandum

Basierend auf RFC 2119 definiert dieses Dokument Schlüsselwörter zum Kennzeichen von Anforderungen. Dies ist keine Übersetzung, sondern eine Interpretation für Deutschsprachige, damit dieses grossartige Werkzeug auch für Deutsche Dokumentationen eingesetzt werden kann.

Zusammenfassung

Im Standardisierungsverfahren werden in vielen Dokumenten Schlüsselwörter verwendet um Anforderungen der Spezifikation aufzuzeigen. Diese Wörter werden oft gross geschrieben. Autoren die diesen Richtlinien folgen, sollten den folgenden Satz am Anfang ihres Dokuments einfügen:

Die Schlüsselwörter "MUSS", "DARF NICHT", "ERFORDERLICH", "SOLL", "VERBOTEN", "NÖTIG", "NICHT NÖTIG", "SOLL NICHT", "EMPFOHLEN", "DARF", "KANN" und "OPTIONAL" werden nach 2119de interpretiert. https://goo.gl/6QZH4J

Beachten Sie dass die Aussagekraft dieser Wörter, durch die Anforderungen des Dokuments in welchem sie verwendet werden, relativiert werden können.

1. MUSS
oder die Schlüsselwörter “ERFORDERLICH” oder “NÖTIG” bedeuten, dass die Definition eine absolute Anforderung der Spezifikation ist.

2. DARF NICHT
oder das Wort “VERBOTEN” Bedeutet, dass die Definition ein absolutes Verbot der Spezifikation ist.

3. SOLL
oder das Adjektiv “EMPFOHLEN” bedeutet, dass es in speziellen Situationen Gründe geben kann, diese Spezifikation zu ignorieren. Natürlich müssen die Auswirkungen voll und ganz verstanden und sorgfältig abgewägt werden, bevor von der Spezifikation abgewichen wird.

4. SOLL NICHT
oder “NICHT EMPFOHLEN” bedeutet, dass es gute Gründe in speziellen Situationen geben kann, dass dieses Verhalten akzeptabel, ja sogar nützlich sein kann. Natürlich müssen die Auswirkungen voll und ganz verstanden und sorgfältig abgewägt werden, bevor von der Spezifikation abgewichen wird.

5. DARF
oder “KANN”, “NICHT NÖTIG” oder das Adjektiv “OPTIONAL” bedeuten, dass dieses Verhalten wirklich optional ist.

Wichtig bei der Definition einer Interaktion oder Protokolls: Ein Anbieter kann entscheiden dieses Verhalten einzuschliessen, weil es das Produkt verbessert oder für einen speziellen Markt erforderlich ist. Ein anderer Anbieter kann dieses Verhalten weglassen. Eine Implementation die dieses Verhalten weglässt MUSS bereit sein, mit einer anderen Implementation welche dieses Verhalten einschliesst, zu interagieren. In der selben Art MUSS eine Implementation die dieses Verhalten einschliesst mit einer Implementation die dieses Verhalten weglässt interagieren können.

Anmerkung fürs Deutsche: Alle Schlüsselwörter DÜRFEN dekliniert und konjugiert werden. Die Grossschreibung ist ausreichend um die Schlüsselwörter zu erkennen. “NICHT” kann mit “KEIN” ersetzt werden, wie es im Deutschen üblich ist.

Abgrenzung

1. Leitlinie für die Verwendung

Die Gebote, die in diesem Memo definiert sind, sollen sparsam und mit Sorgfalt eingesetzt werden. Im speziellen ist es NÖTIG, sie nur dort zu benutzen, wo es für die Interaktion wichtig ist oder um nachteiliges Verhalten auszuschliessen. Sie DÜRFEN KEINE Implementationsdetails vorschreiben, welche unabhängig von der Interaktion sind.

2. Sicherheitsbedenken

Diese Begriffe werden oft verwendet um sicherheitsrelevantes Verhalten zu definieren. Ein MUSS oder SOLL wegzulassen oder etwas zu tun, dass als DARF NICHT oder SOLL NICHT definiert ist, kann subtile Auswirkungen haben. Autoren sollten sich Zeit nehmen, um über Sicherheitsauswirkungen nachzudenken, da die Anwender des Dokuments unter Umständen nicht über die selbe Erfahrung und Hintergrundwissen verfügen.

Danksagung

Ich danke den Autoren des RFCs 2119, welches es mir ermöglicht hat 2119de zu schreiben.

Die Definitionen basieren auf existierenden RFCs. Zusätzlich sind Anmerkungen einer Reihe von weiteren Personen eingeflossen, unter anderem Robert Ullmann, Thomas Narten, Neal McBurnett and Robert Elz.

Autor des original RFCs 2119:

Scott Bradner
email - sob@harvard.edu

Autor:

Jean-Louis Fuchs
email - ganwell@fangorn.ch