Zum Hauptinhalt springen

RFC 2119 - Schlüsselwörter zur Angabe von Anforderungsstufen in RFCs

  • Status: Best Current Practice
  • Veröffentlicht: March 1997
  • Stream: IETF
  • Errata: Keine Errata

Status dieses Memos (Status of this Memo)​

Dieses Dokument spezifiziert Internet Best Current Practices für die Internet-Gemeinschaft und bittet um Diskussion und Verbesserungsvorschläge. Die Verbreitung dieses Memos ist unbegrenzt.

Zusammenfassung (Abstract)​

In vielen Dokumenten des Standards Track werden mehrere Wörter verwendet, um die Anforderungen der Spezifikation zu kennzeichnen. Diese Wörter werden oft großgeschrieben. Dieses Dokument definiert diese Wörter so, wie sie in IETF-Dokumenten interpretiert werden sollen. Autoren, die diesen Leitlinien folgen, sollten die folgende Phrase nahe dem Anfang ihres Dokuments aufnehmen:

Die Schlüsselwörter "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" und "OPTIONAL" in diesem Dokument sind so zu interpretieren, wie in RFC 2119 beschrieben.

Beachten Sie, dass die Verbindlichkeit dieser Wörter durch die Anforderungsstufe des Dokuments modifiziert wird, in dem sie verwendet werden.

1. MUST (muss)​

Dieses Wort oder die Begriffe "REQUIRED" oder "SHALL" bedeuten, dass die Definition eine absolute Anforderung der Spezifikation ist.

2. MUST NOT (darf nicht)​

Diese Phrase oder die Phrase "SHALL NOT" bedeutet, dass die Definition ein absolutes Verbot der Spezifikation ist.

3. SHOULD (sollte)​

Dieses Wort oder das Adjektiv "RECOMMENDED" bedeutet, dass es in besonderen Umständen gültige Gründe geben kann, einen bestimmten Punkt zu ignorieren, die vollen Auswirkungen jedoch verstanden und sorgfältig abgewogen werden müssen, bevor ein anderer Weg gewählt wird.

4. SHOULD NOT (sollte nicht)​

Diese Phrase oder die Phrase "NOT RECOMMENDED" bedeutet, dass es in besonderen Umständen gültige Gründe geben kann, bei denen das beschriebene Verhalten akzeptabel oder sogar nützlich ist, die vollen Auswirkungen jedoch verstanden und der Fall sorgfältig abgewogen werden sollte, bevor ein mit diesem Label beschriebenes Verhalten implementiert wird.

5. MAY (kann)​

Dieses Wort oder das Adjektiv "OPTIONAL" bedeutet, dass ein Element wirklich optional ist. Ein Anbieter kann das Element aufnehmen, weil ein bestimmter Markt es verlangt oder weil er der Meinung ist, dass es das Produkt verbessert, während ein anderer Anbieter dasselbe Element weglassen kann. Eine Implementierung, die eine bestimmte Option nicht enthält, MUST darauf vorbereitet sein, mit einer anderen Implementierung zu interoperieren, die die Option enthält, gegebenenfalls mit eingeschränkter Funktionalität. Ebenso MUST eine Implementierung, die eine bestimmte Option enthält, darauf vorbereitet sein, mit einer anderen Implementierung zu interoperieren, die die Option nicht enthält (außer natürlich für die durch die Option bereitgestellte Funktion).

6. Hinweise zur Verwendung dieser Imperative (Guidance in the use of these Imperatives)​

Imperative der in diesem Memo definierten Art müssen sorgfältig und sparsam verwendet werden. Insbesondere MUST sie nur dort verwendet werden, wo sie tatsächlich für die Interoperabilität erforderlich sind oder um Verhalten zu begrenzen, das potenziell Schaden verursachen kann (z. B. Begrenzung von Neuübertragungen). Sie dürfen beispielsweise nicht verwendet werden, um Implementierern eine bestimmte Methode aufzuzwingen, wenn diese Methode für die Interoperabilität nicht erforderlich ist.

7. Sicherheitsbetrachtungen (Security Considerations)​

Diese Begriffe werden häufig verwendet, um Verhalten mit Sicherheitsimplikationen zu spezifizieren. Die Auswirkungen auf die Sicherheit, wenn ein MUST oder SHOULD nicht implementiert wird oder etwas getan wird, von dem die Spezifikation sagt, dass es MUST NOT oder SHOULD NOT getan werden darf, können sehr subtil sein. Autoren von Dokumenten sollten sich die Zeit nehmen, die Sicherheitsimplikationen des Nichtbefolgens von Empfehlungen oder Anforderungen auszuführen, da die meisten Implementierer nicht den Vorteil der Erfahrung und Diskussion gehabt haben werden, die die Spezifikation hervorgebracht hat.

8. Danksagungen (Acknowledgments)​

Die Definitionen dieser Begriffe sind ein Amalgam aus Definitionen aus einer Reihe von RFCs. Darüber hinaus wurden Vorschläge mehrerer Personen aufgenommen, darunter Robert Ullmann, Thomas Narten, Neal McBurnett und Robert Elz.

9. Adresse des Autors (Author's Address)​

Scott Bradner
Harvard University
1350 Mass. Ave.
Cambridge, MA 02138

phone - +1 617 495 3864
email - [email protected]

Referenzen (References)​