Field Note 45 current

Read the standards; better yet, help write them

By: Theo Zourzouvillys
Published: June 12, 2026
Tags: interoplearningindustryprinciples

TL;DR

Get comfortable reading standards documents — RFCs, W3C Recommendations, ISO specs, IETF Internet-Drafts — as a primary skill, not a thing you do only when a blog post fails you. They look forbidding and mostly aren’t; once you know the conventions (the MUST/SHOULD/MAY keywordsRFC 2119 / RFC 8174 — Key words for use in RFCs (BCP 14)Defines the precise, capitalised requirement keywords — MUST, SHOULD, MAY, and their negations — that carry the normative force in a standard. RFC 8174 clarifies that only the upper-case forms are normative. Learning to read these exactly is the single biggest unlock for reading any spec correctly.rfc-editor.org ↗, the ABNF grammars, the boilerplate you can skip, the Security Considerations section that tells you what the authors were really afraid of) they read faster than the second-hand summaries of them — and they’re the source, with none of the paraphrase error.

Even better: get involved. Lurk on a working-group mailing list, read the active drafts, send an implementer’s feedback, file an erratum, eventually contribute text. It’s the best protocol-design education there is, it puts you in a room with the people who design the systems you build on, and it lets you shape the standard instead of just inheriting it. This isn’t a detour from using standards rather than reinventing them — it’s the skill that makes you good at it.

And zoom out one level, because this is the real point: this is professional development in the truest sense. Taking your craft seriously means being active within something — contributing, not just consuming. It doesn’t have to be standards. It can be an open-source project, a research or practitioner community, a working group, a meetup. Standards work is the version I know best and the one I’d point to first, but the universal move is to stop being a pure consumer of your field and start being a participant in it.

Context

Most engineers treat the spec as a last resort. They’ll read three blog posts, two Stack Overflow answers, and a library’s README before they’ll open the actual RFC — and now they’ll ask a model to summarise it before they’ll read a line of it. That’s backwards. A standard is the primary source: the exact, agreed, normative text that every conformant implementation is measured against. Everything downstream of it — the blog post, the tutorial, the model’s summary, your mental model — is a lossy compression, and the bits that get lost are precisely the ones that bite you in production: the edge case in a SHOULD, the threat enumerated in Security Considerations, the interop trap the authors spent two years arguing about.

The fear is mostly unfamiliarity. Specs have a house style, and once you’ve internalised it the intimidation evaporates. The requirement keywordsRFC 2119 / RFC 8174 — Key words for use in RFCs (BCP 14)Defines the precise, capitalised requirement keywords — MUST, SHOULD, MAY, and their negations — that carry the normative force in a standard. RFC 8174 clarifies that only the upper-case forms are normative. Learning to read these exactly is the single biggest unlock for reading any spec correctly.rfc-editor.org ↗ are precise and they carry real weight — MUST and SHOULD are not synonyms, and reading them sloppily is how you ship a bug. There’s normative text and informative text, Updates and Obsoletes headers, Standards-Track versus Informational versus Experimental versus BCP, errata, and IANA registries. None of it is hard; it’s just a vocabulary, and it’s the same vocabulary across thousands of documents. Learn it once and a whole library opens up.

But reading is only the floor. The thing that genuinely changed my trajectory was participating. Standards aren’t handed down from on high — at the IETF they’re built in the open by whoever shows up and does the work, on the principle of rough consensus and running codeRFC 3935 — A Mission Statement for the IETFHarald Alvestrand's statement of what the IETF is for and how it decides: open process, technical competence, and the famous principle of 'rough consensus and running code' — decisions are made by working groups in the open, validated by implementations, not by vote or authority.rfc-editor.org ↗. Which means you can show up. And when you do, you stop seeing standards as fixed artefacts and start seeing them as arguments that were had — with rejected alternatives, known scars, and reasons. That’s the judgment that doesn’t fit in the document, and it’s the most valuable thing you can carry back to your own design work.

From the field

Early in my career I got deep into SIP — the Session Initiation ProtocolRFC 3261 — SIP: Session Initiation ProtocolThe core signalling protocol for establishing voice, video, and messaging sessions on IP networks. A large, much-extended standard developed at the IETF; the protocol family I spent my early career helping to standardise and implement.rfc-editor.org ↗ — and the IETF work around it. I didn’t just implement it: I lived on the mailing lists, read every draft, argued in the hallways, authored IETF drafts and an RFC, and ended up chairing an IETF working group. I went to SIPit, the multi-day interoperability events where everyone drags their implementations into one room and finds out whose reading of the spec was wrong; worked on the SIP Forum’s SIPconnect trunking profile; and got published in IEEE Spectrum along the way. (I also drank far too much at IETF social events — that part’s on the syllabus too.) It was the best education I’ve ever had, and none of the formal parts were.

And it was never only standards — which is the real point. The same instinct pulled me into the wider community that quietly keeps the internet running: Nominet, the exchanges (LINX, LoNAP, LIPEX), and the operator and user groups (South West LUG, UKNOF). Being active within something compounds. I came out understanding not just SIP but how protocols are designed — extensibility, versioning, state machines, the security model, the hundred ways interop quietly breaks — because I’d watched experts fight over exactly those things. And I got to know the people: the folks who designed the protocols the whole industry runs on. You cannot buy that exposure, and it raised my taste across everything I’ve built since. But the part I didn’t see coming — and value most now — is that those rooms gave me some of my closest, lifelong friends. I went in to help standardise one protocol; I came out fluent in the whole craft, and with people I’ll know for the rest of my life.

Recommendation

Treat reading the primary source as a core skill, and build the habit of going upstream.

Learn the conventions once. The requirement keywordsRFC 2119 / RFC 8174 — Key words for use in RFCs (BCP 14)Defines the precise, capitalised requirement keywords — MUST, SHOULD, MAY, and their negations — that carry the normative force in a standard. RFC 8174 clarifies that only the upper-case forms are normative. Learning to read these exactly is the single biggest unlock for reading any spec correctly.rfc-editor.org ↗ (MUST/SHOULD/MAY), normative vs. informative text, ABNF, the Updates/Obsoletes relationships, document status (Standards Track / Informational / Experimental / BCP), errata, and IANA registries. A couple of hours of deliberate learning pays off across every spec you’ll ever read.
Read the spec, not the summary — especially for anything you implement or secure. A model or a blog is fine for orientation; for the parts that have to be correct, the normative force lives in the exact wording and in Security Considerations, and those don’t survive paraphrase. Open the RFC.
Read the scary sections first. Security Considerations and IANA Considerations tell you what the authors were actually worried about and what the moving parts are. Then the abstract, then the parts you need. You rarely have to read a spec front to back.
Follow the drafts, not just the published RFCs. The thinking happens in the Internet-Drafts and on the mailing list. By the time it’s a published RFC the interesting arguments are over — reading the drafts is how you see why, and how a body like the IAB will even revisit its own foundational principlesRFC 9413 — Maintaining Robust ProtocolsAn IAB document revisiting Postel's robustness principle ('be conservative in what you send, be liberal in what you accept') and arguing that, over the long run, lenient acceptance erodes interoperability. A clear example of a standards body updating its own foundational wisdom — visible only if you read the primary sources.rfc-editor.org ↗ when experience demands it.
Then get involved, on a ladder you can actually climb. Start small and escalate as it earns its place in your week:
- Subscribe to the relevant working-group list and lurk. The Tao of the IETFThe Tao of the IETF — A Novice's Guide to the IETFThe IETF's own newcomer's guide: how working groups, mailing lists, Internet-Drafts, and meetings actually work, and how a newcomer participates. Formerly published as an RFC (4677, then 6722), now a living web document. The on-ramp for getting involved.ietf.org ↗ is the newcomer’s map for how this all works (W3C and others have their equivalents).
- Send an implementer’s report when you build against a draft. Real interop feedback is gold to a working group, and almost nobody supplies it.
- File errata when you find a genuine defect or ambiguity instead of silently working around it.
- Attend a meeting — remote participation is normal now, so the travel barrier is gone.
- Eventually, contribute text, then co-author, then help shepherd. Each rung teaches more than the last.
Read critically, not worshipfully. Some specs are over-engineered, some are badly written, some are really one vendor’s format wearing a standard’s clothes. Reading deeply is exactly what lets you tell the difference — and judge when a standard is genuinely overkill for your problem.
And if standards aren’t your venue, find the one that is. Everything above is about RFCs and working groups because that’s where I did it — but the principle underneath is bigger than the IETF and bigger than standards. Taking your craft seriously means being an active participant in your field, not just a consumer of its output: maintain or contribute to an open-source project, join a practitioner or research community, write, speak, mentor, help run a meetup. Pick the venue that fits you. The move that matters is from passive user to participant — that’s where the compounding education, the people, and the influence actually come from. Do it within something.

Consequences

Easier:

You get the real requirements instead of a paraphrase, so you implement the edge cases, the security properties, and the interop details correctly the first time — the failure modes that blog-driven implementations discover in production.
Your protocol and API design taste rises across the board. Seeing how thousands of person-years of argument shaped a handful of good standards teaches you what good design looks like: extensibility, versioning, clear state, an honest threat model.
Involvement is the best, cheapest network and education in the field. You learn directly from the people who designed the systems everyone runs on — and you can shape the standard to represent your use case instead of inheriting one that doesn’t.
It makes ZFN-30 real: you can only “use the standard, don’t reinvent it” well if you can actually read the standard.

Harder:

Reading specs well is a skill with a genuine learning curve. The first few are slow and unpleasant; the fluency comes only after you’ve pushed through several.
Standards bodies are slow, consensus-driven, and sometimes political. “Rough consensus” can be a grind, and deep involvement is a sustained, real time commitment — not everyone needs to climb all the way to authoring.
It’s possible to over-rotate: to fetishise process, bikeshed, or treat every problem as deserving a standard. Specs are inputs to engineering judgment, not a replacement for it.

New obligations:

If you implement a spec and hit a real defect or ambiguity, you owe the commons a report or an erratum — not just a private workaround. You benefited from everyone who did that before you.

References

RFC 2119 / RFC 8174 — Key words (BCP 14) — read the requirement keywords precisely; it’s the biggest single unlock.
The Tao of the IETF — the newcomer’s guide to how the process actually works and how to start participating.
RFC 3935 — A Mission Statement for the IETF — “rough consensus and running code”; how standards get made in the open.
RFC 9413 — Maintaining Robust Protocols — the field revisiting Postel’s robustness principle; the kind of depth you only see in the primary sources.
RFC 3261 — SIP — the protocol family I cut my standards teeth on.
ZFN-30 — use the standard, don’t reinvent it; this note is the skill that makes that judgment possible.
ZFN-7 and ZFN-6 — notes that are, in practice, me reading and implementing RFCs (9421, DPoP) rather than rolling my own.

Changelog

2026-06-12: First published as a Field Note.