Visual RFC.
ALL RFCs / RFC 8174
Read the RFC ↗
RFC 8174 / READING REQUIREMENTS

Keep requirement levels distinct

03

The capitalization clarification preserves RFC 2119’s different levels. SHOULD is not a weaker spelling of MUST, and MAY is not a recommendation.

DIAGRAMRead RFC section 2 ↗
RFC 8174 · § 2EXAMPLE
3 / 3
Keep requirement levels distinctThree fictional profile examples preserve different requirement levels. MUST include tag is an absolute requirement: an omitted-tag path stops before a conforming decision. SHOULD cache allows a particular exception only after its full implications are understood and carefully weighed. MAY add option allows with/without implementations, but required interoperability remains except for functionality of the option. These are specification-to-implementation decisions, not actual protocol fields newly mandated by RFC8174.Fictional profiles · three independent examplesMAY add option · truly optionalWith optionWithout optionshared protocol still interoperatesinteroperate in the other directionRequired interoperability remainsExcept for functionality the option supplies
03
Choose an optional feature while preserving interoperability.

A fictional optional extension may be implemented or omitted. Either choice must still support the applicable interoperability obligations in RFC 2119 §5.

Source for this drawing: RFC 8174 · Read RFC section 2 ↗

Protocol participantThreat or exceptionProtocol controlSimplified drawings · precise section references
New to this? Start hereA quick picture + helpful background

A message needs an address.

Think of a packet as a small addressed envelope. Devices pass it onward; transport protocols decide what delivery promises an application gets.

Start with this guide; no earlier guide is needed for the overview.

These pictures are analogies to help you learn. The linked RFC explains the actual rules.

Related RFCs and changes

“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.

KEY POINT

Carry the level and its conditions into an implementation decision.

  • RFC 2119 §§1–2: MUST/REQUIRED/SHALL is an absolute requirement; MUST NOT/SHALL NOT is an absolute prohibition of the specification.
  • RFC 2119 §§3–4: SHOULD/RECOMMENDED and SHOULD NOT/NOT RECOMMENDED allow justified particular exceptions, with the full implications understood and carefully weighed.
  • RFC 2119 §5: MAY/OPTIONAL means truly optional. Implementations with and without the option MUST be prepared to interoperate, apart from functionality the option supplies.
DETAILS

The tag, cache policy and extension below are fictional profile examples, not requirements added to any actual protocol. RFC 2119 notes that the force of these terms is modified by the requirement level of the document using them. Its §§6–7 advise careful use and explanation of security implications; RFC 8174 does not redefine the levels.

Read the RFC section ↗

All chapters in RFC 8174

Drawing view

Scroll the drawing to see every part. Playback controls stay above it.

RFC 9700 / CHAPTERS

Chapters

For full details, tables, algorithms, and exceptions, read the original RFC.

RFC status and corrections ↗