Read normative text without a key-word shortcut
04Normative text specifies requirements. RFC 8174 explicitly says it need not use special key words; many requirements are expressed through plain prose, grammar or field definitions. An octet is an eight-bit byte.
For this fictional format, 01 02 has two octets; 01 02 03 has three and does not meet the stated definition. The rule comes from the example specification, not from RFC 8174 defining a wire format.
Source for this drawing: RFC 8174 · Read RFC section 2 ↗
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.
Terms in this drawing
Related RFCs and changes
“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.
Read the whole rule and its context, not just a case-sensitive word search.
- Use of the RFC 2119 key words is not required. Text can be normative without any of those key words.
- In this fictional normative format definition, a record contains exactly two octets. The example’s two-octet requirement does not disappear merely because the sentence has no MUST.
- A scanner finding no special key word cannot conclude optional. Likewise, finding MUST in a quoted illustration does not by itself establish an actual protocol requirement; read the scope and complete text.
RFC 8174 §3 requires no IANA actions. Section 4 describes the document as purely procedural with no related security considerations; it adds no encryption or authorization mechanism. This guide’s parser illustration is a made-up teaching example, not an IANA-registered format or a claim that typography verifies conformance.
Read the RFC section ↗