Skip to main content

2. Conventions Used in This Document

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC 2119].

RFC 2119 Keywords Interpretation​

According to RFC 2119, these keywords have specific meanings in this specification:

Mandatory Requirements​

KeywordMeaningExample
MUSTAbsolute requirementImplementations MUST include pad characters
MUST NOTAbsolute prohibitionImplementations MUST NOT add line feeds
REQUIREDSame as MUSTREQUIRED to support standard alphabet
SHALLSame as MUSTDecoders SHALL reject illegal characters
SHALL NOTSame as MUST NOTEncoders SHALL NOT use non-standard characters

Recommendations​

KeywordMeaningExample
SHOULDStrong recommendation, but exceptions possibleImplementations SHOULD validate padding
SHOULD NOTStrong non-recommendation, but exceptions possibleImplementations SHOULD NOT ignore errors
RECOMMENDEDSame as SHOULDRECOMMENDED to use URL-safe alphabet

Optionality​

KeywordMeaningExample
MAYTruly optionalImplementations MAY support no-padding mode
OPTIONALSame as MAYLine feed support is OPTIONAL

Application in Base Encoding Specification​

Use of MUST​

Example 1: Padding Requirement
"Implementations MUST include appropriate pad characters 
at the end of encoded data."

Consequences of violation: ❌ Decoding failure, data corruption
Example 2: Illegal Character Handling
"Implementations MUST reject the encoded data if it 
contains characters outside the base alphabet."

Consequences of violation: ❌ Security vulnerabilities, data corruption

Use of SHOULD​

Example: Error Reporting
"Implementations SHOULD provide clear error messages 
when decoding fails."

Cases where non-compliance is acceptable:
- Embedded systems with limited resources
- Performance-critical scenarios

Use of MAY​

Example: Optional Features
"Implementations MAY support decoding of data without 
padding characters."

Meaning: This is truly optional functionality; implementations may 
choose to support it or not.

Practical Application Guidelines​

For Implementers​

Compliance Priority:
1. MUST/MUST NOT/REQUIRED/SHALL/SHALL NOT
   → Must be strictly followed, otherwise non-compliant
   
2. SHOULD/SHOULD NOT/RECOMMENDED
   → Strongly recommended to follow unless good reason exists
   
3. MAY/OPTIONAL
   → Decide based on requirements

For Testers​

Testing Focus:
✅ Verify all MUST requirements
✅ Check implementation of SHOULD recommendations
⚠️  Document support status for MAY features

For Users​

When Choosing Implementations:
1. Ensure implementation meets all MUST requirements
2. Prefer implementations that follow SHOULD recommendations
3. Choose based on requirements for MAY features

Common Misconceptions​

❌ Incorrect Understanding​

Misconception 1: "SHOULD can be ignored"
✗ Wrong: SHOULD is just a suggestion, can be ignored at will
✓ Correct: SHOULD is strongly recommended, only deviate with good reason

Misconception 2: "MAY is just optional features"
✗ Wrong: MAY features are not important
✓ Correct: MAY features are optional, but if implemented must be correct

Misconception 3: "MUST is just a suggestion"
✗ Wrong: MUST can be disregarded in some cases
✓ Correct: MUST is absolute requirement, must be strictly followed

Preview of Key Requirements in This Specification​

In subsequent sections, you will see these key requirements:

Section 3.1:
"Implementations MUST NOT add line feeds to base-encoded 
data unless..."

Section 3.2:
"Implementations MUST include appropriate pad characters..."

Section 3.3:
"Implementations MUST reject the encoded data if it 
contains characters outside the base alphabet..."

These requirements use MUST, indicating they are absolutely mandatory, and all conforming implementations must comply.

References​

  • RFC 2119 - Key words for use in RFCs to Indicate Requirement Levels
  • RFC 8174 - Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words (Updated version)
Last updated on