Requirements & behavior · IETF convention
BCP 14 requirement levels
Distinguish mandatory requirements, recommendations, and genuine options.
What it helps you do
Prevent readers from treating a recommendation as mandatory, or a mandatory constraint as optional advice.
Starting knowledge: No specialist knowledge is required.
- Declare that the document uses the BCP 14 convention.
- Use MUST, SHOULD, and MAY deliberately with their defined meanings.
- Supply enough context to understand exceptions and implementation consequences.
The problem it came from
RFC 2119 defined requirement keywords for IETF documents in 1997. RFC 8174 clarified in 2017 that the special meanings apply to uppercase keywords when the convention is adopted.
Together these documents form BCP 14. The convention concerns requirement strength; it does not define a complete specification-writing method.
Work through an example
This specification adopts BCP 14 keyword meanings.
The exported report MUST include its source revision.
The report SHOULD include a human-readable title.
The report MAY include an optional display theme.- Each strength is an explicit choice in this original example.
- The revision requirement still needs a definition of the revision format.
- An optional theme must not silently become required to read the report.
Where it helps. Where it stops.
Use it when
- A protocol, output contract, or specification needs consistent requirement strength.
- “Should” is used casually where a mandatory outcome is intended.
Potential benefits
- A reader can distinguish obligations from recommendations.
- A reviewer can ask why a requirement permits exceptions.
Limits and common mistakes
- Capitalization does not make an ambiguous requirement measurable.
- A SHOULD is not simply unimportant; departures need understanding of the implications.
The prompt below asks for this structure. It does not guarantee accuracy, complete coverage, better learning, or conformance to a standard. Treat those outcomes as separate checks.
Practise the judgment
Try a choice, inspect a boundary, then explain a case yourself. Hints and answers are available whenever you need them.
Which keyword indicates a genuine implementation option under this convention?
Hint
Distinguish optional from recommended.
Explained answer
Best answer for this case: MAY
MAY marks an optional behavior. It should not hide a dependency that makes the supposedly optional feature necessary.
Does writing “MUST be fast” make the requirement measurable?
Hint
Capitalization does not define a threshold.
Explained answer
Best answer for this case: No; fast still needs an agreed definition
Requirement strength and acceptance criteria solve different problems.
A critical source reference is written as “the report MAY include provenance.” What needs review?
Hint
Could the report be accepted without that field?
Explained answer & self-review rubric
Decide whether the reference is genuinely optional. If review depends on it, use an appropriate mandatory requirement and define what provenance must contain. Do not change strength without agreement.
- Identify dependency on the information
- Separate policy choice from wording
- Define the required content
Take it into your own work
Manual template
Use this structure yourself, with a colleague, or in your preferred writing tool.
# Requirement strength review
Convention declaration:
Mandatory behaviors and rationale:
Recommended behaviors and exception conditions:
Optional behaviors:
Definitions and measurable checks:
Review the result
- Is the convention declared?
- Does each keyword reflect intended strength?
- Are the required behaviors specific enough to evaluate?
Use this approach with your own AI tool
Help me apply BCP 14 requirement levels to the material below.
Reader and existing knowledge: [describe]
Task and desired outcome: [describe]
Use these principles: Declare that the document uses the BCP 14 convention.; Use MUST, SHOULD, and MAY deliberately with their defined meanings.; Supply enough context to understand exceptions and implementation consequences..
Preserve source facts, identifiers, quantities, conditions, exceptions, and uncertainty.
Separate supplied facts from assumptions. Ask for missing information instead of inventing it.
Explain your representation choices and provide a review checklist. Do not claim formal compliance or correctness from formatting alone.
Material: [paste only information you are permitted to share]Go to the source
History and the underlying approach are grounded in these references. Examples, prompts, and practice cases here are original educational adaptations. Edition-specific details should be checked against the referenced publication.
Last editorial review: 2026-10-24. An overview is not certification, and this guide is not a reproduction of a standard.