2. Konventionen dieses Dokuments
Die Schlüsselwörter „MUST“ (MUSS), „MUST NOT“ (MUSS NICHT/DARF NICHT), „REQUIRED“ (ERFORDERLICH), „SHALL“ (SOLL), „SHALL NOT“ (SOLL NICHT), „SHOULD“ (SOLLTE), „SHOULD NOT“ (SOLLTE NICHT), „RECOMMENDED“ (EMPFOHLEN), „MAY“ (KANN) und „OPTIONAL“ (OPTIONAL) in diesem Dokument MÜSSEN wie in [RFC 2119] beschrieben interpretiert werden.
Interpretation der RFC-2119-Schlüsselwörter
Gemäß RFC 2119 haben diese Schlüsselwörter in dieser Spezifikation folgende spezifische Bedeutung:
Verbindliche Anforderungen
| Schlüsselwort | Bedeutung | Beispiel |
|---|---|---|
| MUST | Absolute Anforderung | Implementierung muss Füllzeichen enthalten |
| MUST NOT | Absolutes Verbot | Implementierung darf keine Zeilenumbrüche hinzufügen |
| REQUIRED | Identisch mit MUST | Unterstützung des Standardalphabets erforderlich |
| SHALL | Identisch mit MUST | Decoder muss illegale Zeichen zurückweisen |
| SHALL NOT | Identisch mit MUST NOT | Encoder darf keine Nicht-Standard-Zeichen verwenden |
Empfehlungen
| Schlüsselwort | Bedeutung | Beispiel |
|---|---|---|
| SHOULD | Stark empfohlen, Ausnahmen möglich | Implementierung sollte Auffüllung validieren |
| SHOULD NOT | Stark abgeraten, Ausnahmen möglich | Implementierung sollte Fehler nicht ignorieren |
| RECOMMENDED | Identisch mit SHOULD | URL-sicheres Alphabet empfohlen |
Optionalität
| Schlüsselwort | Bedeutung | Beispiel |
|---|---|---|
| MAY | Wirklich optional | Implementierung kann Modus ohne Auffüllung unterstützen |
| OPTIONAL | Identisch mit MAY | Unterstützung von Zeilenumbrüchen ist optional |
Anwendung in Basis-Kodierungsspezifikationen
Verwendung von MUST
Beispiel 1: Auffüllanforderung
"Die Implementierung MUSS das entsprechende
Füllzeichen am Ende der kodierten Daten enthalten."
Folge bei Verletzung: ❌ Dekodierungsfehler, Datenkorruption
Beispiel 2: Behandlung illegaler Zeichen
"Enthalten die kodierten Daten Zeichen außerhalb
des Alphabets, MUSS die Implementierung diese zurückweisen."
Folge bei Verletzung: ❌ Sicherheitslücke, Datenkorruption
Verwendung von SHOULD
Beispiel: Fehlerbericht
"Bei Dekodierungsfehler SOLLTE die Implementierung
eine klare Fehlermeldung liefern."
Akzeptable Nichtbefolgung:
- Resourcenbeschränkte Embedded-Systeme
- Performance-kritische Szenarien
Verwendung von MAY
Beispiel: Optionale Funktion
"Die Implementierung KANN die Dekodierung von
Daten ohne Füllzeichen unterstützen."
Bedeutung: Dies ist eine wirklich optionale Funktion;
die Implementierung darf frei entscheiden, ob sie sie unterstützt.
Praktische Anwendungsrichtlinien
Für Implementierer
Konformitätspriorität:
1. MUST/MUST NOT/REQUIRED/SHALL/SHALL NOT
→ strikt einhalten, sonst nicht konform
2. SHOULD/SHOULD/RECOMMENDED
→ stark empfohlen, außer aus triftigem Grund
3. MAY/OPTIONAL
→ nach Bedarf entscheiden
Für Tester
Test-Schwerpunkte:
✅ Alle MUST-Anforderungen verifizieren
✅ Implementierung der SHOULD-Empfehlungen prüfen
⚠️ Unterstützungsstatus der MAY-Funktionen dokumentieren
Für Benutzer
Bei der Auswahl einer Implementierung:
1. Sicherstellen, dass alle MUST-Anforderungen erfüllt sind
2. Implementierungen bevorzugen, die SHOULD-Empfehlungen folgen
3. MAY-Funktionen nach Bedarf wählen
Häufige Missverständnisse
❌ Falsches Verständnis
Missverständnis 1: „SHOULD kann ignoriert werden“
✗ Falsch: SHOULD ist nur ein Vorschlag, frei ignorieren
✓ Richtig: SHOULD ist stark empfohlen, Abweichung nur aus triftigem Grund
Missverständnis 2: „MAY ist nur eine optionale Funktion“
✗ Falsch: MAY-Funktionen sind unwichtig
✓ Richtig: MAY-Funktionen sind optional, aber bei Implementierung korrekt
Missverständnis 3: „MUST ist nur ein Vorschlag“
✗ Falsch: MUST kann manchmal ignoriert werden
✓ Richtig: MUST ist absolute Anforderung, strikt einhalten
Vorschau der Schlüsselanforderungen dieser Spezifikation
In den folgenden Abschnitten begegnen Ihnen diese Schlüsselanforderungen:
Abschnitt 3.1:
"Die Implementierung DARF kodierten Basisdaten keine
Zeilenumbrüche hinzufügen, sofern die Referenzspezifikation
es nicht explizit verlangt…"
Abschnitt 3.2:
"Die Implementierung MUSS das entsprechende Füllzeichen
am Ende der kodierten Daten enthalten…"
Abschnitt 3.3:
"Enthalten die kodierten Daten Zeichen außerhalb des
Basisalphabets, MUSS die Implementierung sie zurückweisen…"
Diese Anforderungen verwenden MUST, was bedeutet, dass sie absolut verbindlich sind und von allen konformen Implementierungen eingehalten werden müssen.
Referenzen
- RFC 2119 - Schlüsselwörter zur Kennzeichnung von Anforderungsstufen in RFCs
- RFC 8174 - Groß-/Kleinschreibungsmehrdeutigkeit der RFC-2119-Schlüsselwörter (aktualisierte Version)