Robustness principle - Wikipedia  🔗 **Source:** [Robustness principle - Wikipedia](https://en.wikipedia.org/wiki/Robustness_principle) > [!note]+ Document Notes > tags: [postels-law, robustness-principle, protocol-design, interop, rfc, network-security, tor, standards, bug-for-bug-compatibility, specification] > title: Robustness principle (Postel's law) > author: Wikipedia contributors > source: "Wikipedia" > reference: https://en.wikipedia.org/wiki/Robustness_principle > date created: 2026-09-04 11:35 > > > [!info] Generated analysis — not the author's words. Sections below are machine-written > > from the captured source. Only text inside `> [!quote]` blocks is verbatim from the author. > > Do not quote or attribute any other line to the named author. > > > [!warning] Provenance and why this was read > > **Encyclopedic tertiary source**, collectively authored, no byline. Treat it as a map of the literature, not as an authority; every substantive claim here is attributed to a numbered primary source (RFC 761, RFC 1122, RFC 3117, Thomson's drafts, Rochet & Pereira) and those are what to cite. > > **Read as the third document in a cluster.** Winer's [[3. Resources/Readwise/Articles/Rules for Standards-Makers|Rules for standards-makers]] invokes this principle explicitly — and cites exactly half of it. This page is where the other half's twenty-five-year argument lives, which makes the pairing more informative than either document alone. > > **Short article, dense citations.** ~4,200 characters of prose over six numbered references spanning 1980–2019. > > # 🏷️ Title: Robustness principle (Postel's law) > <!-- deep-read:sections start --> ## 🧭 Table of Contents - [📝 Summary](#-summary) - [📖 Main Content](#-main-content) - [🗒️ Notes](#️-notes) - [📚 References](#-references) - [🗣️ Paraphrase](#️-paraphrase) - [📰 Newsletter](#-newsletter) - [✅ Action Items](#-action-items) - [🧪 Hypotheses](#-hypotheses) - [📊 Methodology](#-methodology) - [❓ Questions](#-questions) - [🔮 Future Research](#-future-research) - [💡 Implications](#-implications) - [🧠 Learning Styles Assessment](#-learning-styles-assessment) - [📊 Accessibility Assessment](#-accessibility-assessment) - [🌍 DEIB Assessment](#-deib-assessment) - [✅ Logical Validity](#-logical-validity) - [🛡️ DARVO Analysis](#️-darvo-analysis) - [🎯 Conclusion](#-conclusion) - [🧱 Refactor Appendix](#-refactor-appendix) - [🧰 Template Library](#-template-library) ### 🔗 References (in-page) - Source: https://en.wikipedia.org/wiki/Robustness_principle - RFC 761 — Postel, ed., *Transmission Control Protocol*, Jan 1980 (doi:10.17487/RFC0761) - RFC 1122 — Braden, ed., *Requirements for Internet Hosts: Communication Layers*, Oct 1989 (doi:10.17487/RFC1122) - RFC 3117 — Rose, *On the Design of Application Protocols*, Nov 2001 (doi:10.17487/RFC3117) - Thomson, Martin — *The Harmful Consequences of the Robustness Principle*, IETF, May 2019 - Rochet & Pereira — "Dropping on the Edge: Flexibility and Traffic Confirmation in Onion Routing Protocols," PETS 2018 - Wilde, Erik — *Wilde's WWW: Technical Foundations of the World Wide Web*, Springer-Verlag, 2012 [1999], p. 26 ## 📝 Summary **The principle.** "Be conservative in what you do, be liberal in what you accept from others" — Jon Postel, in the January 1980 TCP specification (RFC 761). Commonly reworded as "be conservative in what you send, be liberal in what you accept." Programmers know a typed restatement of it: be contravariant in the input type and covariant in the output type. **What it asks for.** Senders should conform completely to the specification; receivers should accept non-conformant input as long as the meaning is clear. RFC 1122 (1989) extended it with a security posture — assume the network is full of malevolent entities sending packets designed for the worst possible effect — and with forward-compatibility guidance: accept unknown codes in existing fields, avoid sending legal-but-obscure features that expose receiver deficiencies, and cooperate to limit the disruption misbehaving hosts can cause. **The case against, which is the article's real content.** Three escalating critiques over twenty years. Rose (RFC 3117, 2001): a defective implementation survives undetected among tolerant peers until it meets a strict one years later, at which point diagnosis is hard and the fix is expensive — so build explicit consistency checks even at implementation cost. Thomson (2015–2018 drafts, published 2019): the principle actively *reduces* robustness, because a flaw becomes entrenched as a de facto standard that every implementation must then replicate to interoperate — "bug for bug compatible." Rochet & Pereira (PETS 2018): a working exploit, using Postel-style tolerance inside Tor's routing protocol to compromise the anonymity of onion services and clients. **Stakeholders.** Protocol designers and implementors; security researchers; anyone maintaining a parser at an internet trust boundary. **Bottom line.** The principle's two halves have had opposite fates. "Be conservative in what you send" is uncontroversial and remains good advice. "Be liberal in what you accept" has accumulated a substantial, specific, and partly empirical case against it, culminating in a demonstrated attack. Citing "Postel's law" approvingly without saying which half is doing the work is now an imprecision worth noticing — including in Winer's document, though he is unusually careful and cites only the send-half by name. ## 📖 Main Content **The asymmetry is the design, not an accident.** Postel's formulation deliberately assigns different obligations to the two ends of a connection: strictness where you control the output, tolerance where you don't control the input. In 1980, with a small number of independently written implementations trying to bootstrap a working network, that asymmetry is what let deployment proceed without global coordination. The principle solved a real problem, and reading the criticism without that context makes it look naive rather than situated. **RFC 1122 quietly changed the principle's character.** Braden's 1989 expansion pairs Postel's tolerance with the instruction to assume the network is filled with malevolent entities. Those two ideas are in obvious tension — be generous with input, and assume input is hostile — and the resolution offered is a narrower reading: tolerate *unknown but well-formed* extensions, do not tolerate *malformed* input. Much of the later criticism can be read as arguing that this distinction, though correct, is not what implementors actually did. **Rose's critique is about time, not correctness.** RFC 3117's insight is that liberal acceptance doesn't prevent failures, it *defers* them — and defers them to the worst possible moment, when the defective implementation is already deployed, its author has moved on, and the failure surfaces as an interop bug between two parties who are both behaving reasonably. His prescription — explicit consistency checks even at implementation cost — is the direct ancestor of "ship a validator," and it is worth noticing that Rose was willing to pay runtime overhead for early failure. **Thomson's critique is the strongest and is structural.** The claim is not that tolerance causes bugs but that it causes bugs to become *load-bearing*. Once a flawed implementation is widely deployed and tolerated, every new implementation must reproduce the flaw to interoperate, so the aberrant behavior is promoted from defect to requirement. "Bug for bug compatible" names an equilibrium nobody chose and nobody can unilaterally leave. The article also records his observation that this is reinforced by a natural reluctance to trigger fatal errors — the humane instinct and the correct instinct diverge. **Rochet & Pereira convert theory into an exploit.** The 2018 PETS paper is the article's most consequential citation because it is the only one that fires the claim rather than arguing it: Postel-style flexibility inside onion routing was used to confirm traffic and compromise anonymity for both onion services and clients. That moves "liberal acceptance is risky" from a design opinion to a demonstrated attack surface in a system whose entire purpose is resisting exactly that class of adversary. **The "See also" list is a genuine argument in miniature.** Unix philosophy, static discipline, and the open–closed principle are three different traditions with three different answers to the same tension between flexibility and constraint. Static discipline in particular is the near-opposite of Postel — push error detection as early as possible — and its presence signals that the encyclopedic consensus now treats the robustness principle as one position among several, not as settled wisdom. ### 🗒️ Notes - **The article documents a reversal without stating one.** Its structure — principle, expansion, then three critiques with no rebuttals — is itself an editorial judgment about where the weight of opinion has landed. There is no "Defense" or "Continued support" section, which is notable given the principle's stature. - **Nobody in the article defends liberal acceptance.** That absence is the most useful thing to know about the current state of the debate, and it is invisible unless you go looking for the missing section. - **The tension with Winer is real and neither document notices it.** Winer cites the send-half approvingly in the 2017 rules, and in the 2026 addition recommends shipping a validator — which is Rose's "explicit consistency checks" and is an argument *against* the accept-half. Winer arrives at the anti-liberal-acceptance position by a different route and never registers that he has done so. - **The typed restatement is a real bridge to type theory** — contravariant input, covariant output is the function-subtyping rule. It reframes an internet folk principle as a special case of a well-understood formalism, and it is one line in the article. - **RFC 1122's "malevolent entities" line predates the modern security-engineering vocabulary by a decade** and is quotable on its own terms. - **Dates matter for citation:** Thomson's work is a series of Internet-Drafts from 2015–2018, with the article's retrieval pointing at a May 2019 version. It is a draft series, not an RFC — worth stating accurately if cited, because "IETF draft" and "RFC" carry different weight. ## 📚 References Primary sources, all with DOIs or stable IETF locations, as listed in the article: - **RFC 761** (Postel, ed., Jan 1980) — the origin. The principle appears in a TCP specification, not in a philosophy paper, which is worth remembering when it is invoked as a general design maxim. - **RFC 1122** (Braden, ed., Oct 1989) — the expansion, and the source of both the malevolent-entities posture and the forward-compatibility guidance. - **RFC 3117** (Rose, Nov 2001) — the first sustained critique, focused on deferred and expensive failure. - **Thomson, *The Harmful Consequences of the Robustness Principle*** (IETF, drafts 2015–2018; retrieved May 2019) — the entrenchment/bug-for-bug-compatibility argument. - **Rochet & Pereira, "Dropping on the Edge"** (PETS 2018) — the empirical security result against Tor. - **Wilde, *Wilde's WWW*** (Springer, 2012 [1999], p. 26) — cited for the RFC 1122 interpretation. This is a strong citation set for a short article: five of six are primary, all are dated, and the two most load-bearing critiques are traceable to specific documents rather than to general opinion. A reader can reconstruct the entire debate from these six items, which is the correct standard for a tertiary source. ## 🗣️ Paraphrase **Definition.** In computing, the robustness principle is a design guideline stating "be conservative in what you do, be liberal in what you accept from others," often reworded as "be conservative in what you send, be liberal in what you accept." It is also known as Postel's law, after Jon Postel, who used the wording in an early TCP specification. **Restatement.** Programs sending messages to other machines or programs should conform completely to the specifications; programs receiving them should accept non-conformant input as long as the meaning is clear. Among programmers the same idea appears as: be contravariant in the input type and covariant in the output type. **Interpretation.** RFC 1122 (1989) expanded on the principle by recommending programmers assume the network is filled with malevolent entities sending packets designed to have the worst possible effect. Protocols should allow new codes to be added to existing fields in future versions by accepting messages with unknown codes, possibly logging them. Programmers should avoid sending messages with legal but obscure protocol features that might expose deficiencies in receivers, and should design their code not merely to survive misbehaving hosts but to cooperate in limiting the disruption such hosts cause to the shared communication facility. **Rose's criticism (2001).** Marshall Rose characterized several deployment problems arising from the principle. A defective implementation sending non-conforming messages may be used only with tolerant implementations until, possibly years later, it meets a less tolerant application that rejects its messages. Identifying the problem is then often difficult and deploying a solution costly. Rose recommended explicit consistency checks in a protocol even where they impose implementation overhead. **Thomson's criticism (2015–2018).** In a series of Internet-Drafts, Martin Thomson argues the principle actually leads to a lack of robustness, including security problems. A flaw can become entrenched as a de facto standard: any implementation of the protocol is then required to replicate the aberrant behavior or fail to interoperate. This is both a consequence of applying the principle and a product of a natural reluctance to trigger fatal error conditions. Ensuring interoperability in that environment is often described as aiming to be "bug for bug compatible." **Rochet and Pereira (2018).** A paper on privacy-enhancing technologies showed how to exploit the robustness principle inside the Tor routing protocol to compromise the anonymity of onion services and Tor clients. **See also.** Unix philosophy; static discipline; open–closed principle. ## 📰 Newsletter **Half of Postel's law has quietly lost the argument** "Be conservative in what you send, be liberal in what you accept." Jon Postel wrote it into the TCP spec in 1980, and it's been quoted approvingly ever since — including by Dave Winer in his [Rules for standards-makers](https://this.how/standards/), which is what sent me to look it up. Winer cites half. He says so explicitly: "1/2 of Postel's robustness principle — be conservative in what you send." That precision turns out to matter, because the other half has spent twenty-five years getting taken apart. Marshall Rose started it in [RFC 3117](https://www.rfc-editor.org/rfc/rfc3117) back in 2001: liberal acceptance doesn't prevent broken implementations, it hides them. A buggy sender works fine among tolerant peers for years, then meets a strict one, and now you're debugging something deployed, unowned, and expensive to fix. His fix was explicit consistency checks, even where they cost you performance. Martin Thomson's drafts took it further, and the phrase that sticks is "bug for bug compatible." Tolerate a flaw long enough and every new implementation has to reproduce it, or it doesn't interoperate. The bug stops being a bug and becomes part of the format. Nobody voted for that. Then in 2018 two researchers used exactly this flexibility inside Tor's routing protocol to deanonymize onion services and clients. That's the point where the argument stops being about design taste. Here's the part I like: Winer's 2026 follow-up says a format should ship a validator. That *is* Rose's consistency check. He arrived at the anti-liberal-acceptance position from the interop side without ever framing it as a disagreement with the law he'd cited. If you're defining a format — a plugin schema, an API contract, anything others implement — the practical version is: be strict at the boundary and ship the tool that proves it. Tolerance feels generous. It's a loan against a debt someone else pays. ## ✅ Action Items **Courtney — personal:** - This is the sharpest note-candidate in the three-document cluster: the two halves of Postel have opposite track records, and nothing in the vault captures it yet. - Directly applicable to her plugin work anywhere input crosses a trust boundary — Micropub payloads, Webmention parsing, the Social Webmention Importer's ingestion of X/LinkedIn responses. Liberal acceptance in an importer is where malformed third-party data becomes permanent local state. - Pair with the WordPress security material already in the vault: [[3. Resources/Permanent Notes/Client-Supplied Hints Are Not Security Boundaries]] and [[3. Resources/Permanent Notes/A Parser Disagreement Between Two Sanitizers Is the Exploitable Seam]] are the same family of problem. **Core / Core Performance:** WordPress's compatibility-first culture is a large-scale instance of liberal acceptance, and the entrenchment critique explains its cost precisely — see [[3. Resources/Permanent Notes/WordPress's Compatibility-First Culture Is Now Its Binding Security Constraint]]. **Plugins / Themes:** Anywhere a plugin parses third-party input, "accept if the meaning is clear" is the posture that produces long-lived, hard-to-remove quirks. **Core AI:** Highly relevant to ability schemas and agent tool definitions — tolerant parsing of model output is exactly the pattern that entrenches malformed conventions. **Documentation:** A validator is a documentation artifact as much as an engineering one; it answers conformance questions the prose cannot. **Meta / Tide / Openverse:** Shared-schema surfaces where strictness at ingest is cheaper than migration later. **Accessibility:** Tangential but real — HTML's extreme liberal acceptance is why malformed markup persists and why assistive technology gets inconsistent trees to work with. **Community / Marketing / Support / Polyglots / Photos / TV / Mobile / Playground / CLI / Hosting / Training / Core Program Team:** Not applicable to this source. **The WPOCC / FAIR:** FAIR only — a federated repository ingesting metadata from many publishers is the canonical liberal-acceptance risk, and the entrenchment argument predicts what happens if it tolerates malformed records early. ## 🧪 Hypotheses 1. **Protocols with strict validation at launch show less implementation divergence at ten years** than tolerant ones. The core testable form of Thomson's entrenchment claim. 2. **"Bug for bug compatible" is detectable in the wild** — conformance suites should reveal named quirks that all major implementations reproduce despite contradicting the spec. HTML, RSS and email are the obvious hunting grounds. 3. **Liberal acceptance correlates with parser-differential vulnerabilities.** Rochet & Pereira is one instance; request smuggling and XML entity attacks are others. A survey would test whether the pattern generalizes. 4. **The send-half alone captures most of the benefit.** If conservative sending without liberal accepting still yields successful deployment, the principle can be split without loss — this is effectively what Winer's practice does. 5. **Deferred failure is more expensive than early failure by a large multiple.** Rose asserts it; the cost differential between a spec violation caught in CI and one caught in a cross-vendor interop bug is measurable. 6. **Reluctance to throw fatal errors is a human factor, not a technical one.** Thomson names it; it is testable by observing whether implementors relax strictness under support pressure. ## 📊 Methodology **Tertiary source with no methodology of its own** — it summarizes, and its quality is a function of its citations rather than of any analysis it performs. On that measure it does well: six references, five primary, all dated, spanning 1980 to 2019. The methodologies of the underlying works differ sharply and the article does not distinguish them, which is the main thing a careful reader must supply: - **RFC 761 / RFC 1122** are normative specifications — engineering consensus documents, not empirical studies. They assert good practice. - **RFC 3117 (Rose)** is analytical, drawing on deployment experience. Argument from practitioner observation, no dataset. - **Thomson's drafts** are also argumentative rather than empirical — reasoning about consequences, supported by examples. Their status as *drafts* rather than adopted RFCs is a fact about their standing that the article records but does not emphasize. - **Rochet & Pereira** is the only peer-reviewed empirical work in the set, and the only one that demonstrates rather than argues. It is also the narrowest — one protocol, one attack class. So the case against liberal acceptance is: two decades of expert argument plus one demonstrated exploit in one system. That is substantial and it is not the same as a systematic empirical finding, and the distinction should survive any citation of this material. ## ❓ Questions 1. Has anyone published a serious *defense* of liberal acceptance since 2001? The article's silence suggests not, but absence in a Wikipedia article is weak evidence of absence in the literature. 2. Is the correct distinction "tolerate unknown extensions, reject malformed input" — and if so, is the principle salvageable in that narrower form rather than abandoned? 3. Did Thomson's drafts ever reach RFC status, or did the argument win informally without formal adoption? 4. How much of HTML5's success is owed to specifying the *error handling* — effectively standardizing liberal acceptance so it stops being divergent? That looks like a third path the article doesn't consider. 5. What is the actual cost of strictness at internet scale — how many legitimate messages does a strict parser reject, and who bears that? 6. Does the principle behave differently inside a trust boundary than across one? Postel wrote it for a cooperative research network, not an adversarial internet. 7. For AI systems: is tolerant parsing of model output the same mistake at a new layer, and is entrenchment already visible in tool-calling conventions? ## 🔮 Future Research - **A conformance-divergence study.** Compare protocols by launch-time strictness and measure implementation divergence over time. This is the empirical work the whole debate lacks and it is doable with existing conformance suites. - **Parser-differential vulnerability survey** across protocols with tolerant parsers, to establish whether the Tor result is representative or singular. - **The HTML5 third path.** Specifying error handling precisely — neither strict rejection nor undefined tolerance — may dissolve the dichotomy the article presents. Whether it generalizes beyond markup is an open and interesting question. - **Postel's two halves in AI protocol design.** Tool-call and structured-output parsing is a live, young, high-velocity space where the same choice is being made right now, mostly by default and mostly toward tolerance. - **The economics of deferred failure.** Rose's central claim has never, as far as this article shows, been quantified. ## 💡 Implications **For practice.** Split the principle when you cite it. Conservative sending is free and good. Liberal accepting is a decision with a documented cost profile, and if you choose it you should be able to say why and what you will do when a tolerated quirk becomes load-bearing. **For policy.** Standards bodies that mandate conformance testing are, in effect, taking Rose's side. The presence or absence of a validator in a standards deliverable is a policy choice about who pays for divergence, and it is usually made implicitly. **For security.** The strongest section of the argument. Liberal acceptance widens the input space a parser must handle correctly, which is definitionally more attack surface; the Tor result shows this is exploitable in a system explicitly designed against a strong adversary. Anywhere untrusted input crosses a boundary, tolerance is a security decision, not a courtesy. **For education.** Postel's law is taught as settled wisdom and is not. It is a good teaching case precisely because it shows a canonical principle accumulating a serious rebuttal over decades — which is a more useful lesson about engineering knowledge than the principle itself. **For funding and sustainability.** Validators and conformance suites are the mitigation, and they are unglamorous shared infrastructure that nobody's roadmap funds. The entrenchment cost, meanwhile, is paid by every future implementer — a textbook externality. ## 🧠 Learning Styles Assessment - **Visual** — Not served. No diagrams. The send/accept asymmetry and the entrenchment mechanism would both benefit enormously from a simple figure, and neither has one. - **Aural** — Not served. Text only. - **Verbal (read/write)** — Very well served. Precise, compact encyclopedic prose with the key formulations quoted exactly and alternatives given. - **Kinesthetic** — Not served. Nothing to do or try; no code, no worked example of a tolerated-then-entrenched quirk. - **Logical** — Very well served, and the article's strongest mode. Clean structure: statement → interpretation → chronological criticism, so the reader can follow the argument's development and see which claim rests on which source. - **Social** — Not served in the article itself, though Wikipedia's talk page and edit history exist as a layer beneath it. - **Solitary** — Very well served. Short, self-contained, and every claim is followed to a citable primary source. - **Naturalistic** — Not applicable to this source — no natural-world or ecological dimension. **Reading level:** roughly grade 13–15 (undergraduate to graduate). Sentences are moderately complex and the vocabulary is unavoidably specialist — protocol, specification, non-conformant, contravariant, onion routing. The contravariance line in particular is opaque without prior type-theory exposure, and it is presented without explanation. A working developer will read this comfortably; a general reader will not get past the second paragraph. ## 📊 Accessibility Assessment Assessed against WCAG 2.2 AA, treating the Wikipedia article as the artifact: 1. **1.1.1 Non-text Content (A).** Low exposure — the captured article carries no meaningful images. Note the Reader capture has **no cover image**, which is a pipeline concern rather than a source defect. 2. **1.3.1 Info and Relationships (A).** Strong. Wikipedia emits genuine heading hierarchy, lists, and a semantically marked reference section; structure reaches assistive technology reliably. 3. **1.4.3 Contrast (Minimum) (AA) / 1.4.4 Resize Text (AA) / 1.4.10 Reflow (AA).** Wikipedia's Vector skin is among the better-tested large-site implementations on all three; not measured here, but the platform has a strong track record and an active accessibility community. 4. **2.4.4 Link Purpose (In Context) (A).** Mostly good — descriptive link text throughout — with the standard encyclopedic weakness of numbered citation superscripts ("[1]", "[2]") that are uninformative out of context. Wikipedia mitigates this with accessible titles on reference links. 5. **2.4.5 Multiple Ways (AA).** Well satisfied — search, categories, "See also," and inbound links. 6. **3.1.3 Unusual Words (AAA, aspirational).** Not met, and relevant: "contravariant," "covariant," and "onion services" appear without gloss. This is the article's real comprehension barrier and it is a AAA criterion, so not a conformance failure — but it is the thing that actually stops readers. 7. **4.1.2 Name, Role, Value (A).** Strong on the platform; no custom widgets in this article. **Overall:** among the more accessible sources in this batch, with structure as its main strength and undefined specialist vocabulary as its main barrier. **Pipeline action required:** this doc has no cover image and `deepread_check` enforces one, so a cover must be set before the doc passes. ## 🌍 DEIB Assessment - **Cultural breadth.** Narrow in an unremarked way. The entire history is US/European internet engineering — IETF RFCs, a Springer monograph, a European privacy conference. The principle is presented as universal engineering wisdom while its provenance is a specific institutional culture (early ARPANET/IETF) with specific assumptions about trust and cooperation among participants. That provenance is exactly what the criticism turns on, and naming it would strengthen the article. - **Inclusive language.** Neutral and unproblematic. Encyclopedic register; the one loaded phrase, "malevolent entities," is a direct quotation from RFC 1122. - **Neurodiversity support.** Good structurally — short sections, clear headings, chronological ordering, no rhetorical flourish to parse around. Undefined jargon works against readers who process unfamiliar terminology slowly, since nothing is glossed inline. - **Representation.** Six named contributors to the debate (Postel, Braden, Rose, Wilde, Thomson, Rochet, Pereira), all appearing as researchers. No demographic dimension is visible in the text and none is relevant to the content; worth noting only that the cited canon is small, Western, and institutional, which is typical of RFC-based history and shapes whose objections got recorded. - **Psychological safety.** Not applicable in the interpersonal sense. The article criticizes ideas rather than people, attributes every criticism to a named source, and does not editorialize — which is the correct posture for a contested technical topic and is executed well here. ## ✅ Logical Validity **Strong reasoning:** - **Every claim is attributed and dated.** The article never asserts in its own voice that the principle is harmful; it reports who argued what, when, and where. That is exactly right for a tertiary source on a contested topic. - **Chronological structure carries an argument honestly.** Presenting 1980 → 1989 → 2001 → 2018 lets the reader see a position accumulating opposition without the article having to claim a verdict. - **The strongest evidence is placed last and characterized accurately.** Rochet & Pereira is described as showing "how to exploit," which is precisely what a demonstration paper does — no overstatement into "proved the principle wrong." - **Alternative formulations are given rather than harmonized.** Three phrasings of the principle appear, acknowledging that the canonical wording is itself unsettled. **Fallacies and weak points:** - **Structural imbalance amounting to suppressed evidence.** A "Criticism" section with no counterpart. Either no serious defense exists post-2001 — which would be a significant fact worth stating — or one exists and is omitted. As written, the reader cannot tell which, and the layout implies a consensus the article does not source. *Fix:* state explicitly whether a defense exists, or add one. - **Equivocation across the two halves, inherited from the literature.** The critiques target liberal acceptance almost exclusively, but the article discusses "the robustness principle" as a unit throughout. A reader can easily come away believing the whole principle is discredited when the send-half is untouched. *Fix:* separate the halves structurally. - **Appeal to authority by citation density.** The case rests substantially on RFC numbers and IETF affiliation. That is legitimate shorthand, but two of the three critiques are argument rather than evidence, and the article's uniform citation style flattens that distinction. *Fix:* characterize each source's type. - **Unglossed technical term used to establish a claim** — the contravariance restatement is offered as an equivalent formulation with no argument that it *is* equivalent, and most readers cannot check it. **Tone of voice:** Neutral, compressed, encyclopedic. No hedging, no advocacy, no rhetorical flourish. Its point of view is expressed entirely through structure — what gets a section and what does not — which is the characteristic way Wikipedia articles editorialize while appearing not to. ## 🛡️ DARVO Analysis **Not applicable to this source.** DARVO describes a defensive rhetorical pattern deployed by a party accused of harm, and this is a neutral tertiary reference work with no accused party, no author defending a position, and no interpersonal conflict. Each element, checked for completeness: - **Deny** — absent. The article denies nothing; it reports criticism at face value and does not minimize it. - **Attack** — absent. Ideas are criticized through cited sources; no person is attacked, and Postel is treated with straightforward historical respect. - **Reverse Victim and Offender** — absent. No victim/offender framing exists anywhere in the text. Worth recording rather than skipping, because the *underlying debate* is one where DARVO-adjacent moves are plausible — a defense of the principle that recast its critics as the real threat to interoperability would fit the pattern — and no such move appears here. ## 🎯 Conclusion **Bottom line.** A short, well-cited article documenting a canonical 1980 design principle and the twenty-five-year case against half of it. "Be conservative in what you send" stands. "Be liberal in what you accept" has drawn sustained criticism — deferred and expensive failure (Rose, 2001), entrenchment of flaws as de facto standards (Thomson, 2015–2018), and a demonstrated deanonymization attack against Tor (Rochet & Pereira, 2018). The article never says the principle has lost; its structure says it, and the absence of any defense section is the most informative thing about it. **Next steps.** 1. Write the Permanent note — the two-halves asymmetry is the strongest uncaptured claim across this whole three-document cluster. 2. Read back against Winer: he cites the send-half, then independently recommends a validator, which is Rose's remedy. Neither document notices they are on the same side of an argument the other half of the citation loses. 3. Apply to her own input boundaries — Webmention and Micropub parsing, and the Social Webmention Importer especially. 4. **Pipeline: set a cover image on this doc** before the completion gate will pass it. ## 🧱 Refactor Appendix ### Literature Split Pad **Proposed Literature Note:** `Robustness Principle (Postel's Law) — reference` - Bib capsule: "Robustness principle." Wikipedia, retrieved 2026-09-04. Tertiary; six references spanning RFC 761 (1980) to Thomson (2019). - Adler Q1 — what the principle says, and what has happened to it since. - Adler Q2 — statement and three formulations; RFC 1122's expansion; three escalating critiques; adjacent principles. - Key arguments (≤3): (1) the two halves are separable and have opposite records; (2) liberal acceptance defers failure and entrenches flaws as requirements; (3) the entrenchment risk is demonstrated, not merely argued, in at least one adversarial system. #### Claim atoms (H3 candidates) ### Liberal acceptance promotes a flaw into a requirement > [!quote] ID:rw_01m1pmwhxzzntqfafmqz9fxwsq > A flaw can become entrenched as a de facto standard. Any implementation of the protocol is required to replicate the aberrant behavior, or it is not interoperable. Where: the Thomson paragraph under Criticism. Why it matters: the sharpest form of the case against tolerance — it explains how a defect becomes unremovable without anyone deciding it should be, and it generalizes to any ecosystem with compatibility pressure. <!-- atomicity: 1 idea ✓ --> ### Tolerated non-conformance defers failure to its most expensive moment > [!quote] ID:rw_01m1pmwhxzzntqfafmqz9fxwsq > Rose therefore recommended "explicit consistency checks in a protocol ... even if they impose implementation overhead". Where: the Rose paragraph. Why it matters: reframes strictness as a cost-timing decision rather than a rigidity preference, and is the direct ancestor of "ship a validator." <!-- atomicity: 1 idea ✓ --> ### A cooperative-era assumption becomes an adversarial-era liability > [!quote] ID:rw_01m1pmwhxzzntqfafmqz9fxwsq > RFC 1122 (1989) expanded on Postel's principle by recommending that programmers "assume that the network is filled with malevolent entities that will send in packets designed to have the worst possible effect". Where: the Interpretation section. Why it matters: RFC 1122 pairs liberal acceptance with an explicitly hostile threat model, and the tension between those two instructions is where the whole later argument lives. <!-- atomicity: 1 idea ✓ --> #### Permanent Note candidates 1. **"The Two Halves of Postel's Law Have Opposite Track Records"** — the cluster's strongest and most original candidate. Genuinely uncaptured in the vault; explains why an approving citation of "Postel's law" is now imprecise. **Recommend creating on the next synthesis pass.** 2. **"Tolerating Non-Conformance Promotes a Bug Into a Requirement"** — atom 1. Generalizes well past protocols: it is the same mechanism as WordPress's compatibility-first constraint, and would link to [[3. Resources/Permanent Notes/WordPress's Compatibility-First Culture Is Now Its Binding Security Constraint]]. 3. **"Strictness Is a Choice About When to Pay, Not Whether"** — atom 2. Check against [[3. Resources/Permanent Notes/Constraints Validated At Definition Time Propagate Not Recur]], which may already cover it. **Recommendation:** candidate 1 is the one to write, and it is the payoff of reading all three documents together rather than any one of them. ### Fleeting Queue - Does a post-2001 defense of liberal acceptance exist anywhere? The article's silence is suggestive but not evidence. - HTML5's specified error handling as a third path between strict and tolerant — possibly dissolves the dichotomy. - Tolerant parsing of LLM tool-call output is the same decision being made again, right now, mostly by default. - Postel's law was written for a cooperative research network. Does any principle survive the trust environment it was designed in? <!-- deep-read:sections end --> 📄 **Full text:** [[Full Document Contents/Articles/Robustness principle - Wikipedia.md|Robustness principle - Wikipedia by Wikipedia contributors]] ## Highlights - In 2001, [Marshall Rose](https://en.wikipedia.org/wiki/Marshall_Rose) characterized several deployment problems when applying Postel's principle in the design of a new application protocol.[[4]](https://en.wikipedia.org/wiki/Robustness_principle#cite_note-4) For example, a defective implementation that sends non-conforming messages might be used only with implementations that tolerate those deviations from the specification until, possibly several years later, it is connected with a less tolerant application that rejects its messages. In such a situation, identifying the problem is often difficult, and deploying a solution can be costly. Rose therefore recommended "explicit consistency checks in a protocol ... even if they impose implementation overhead". ([View Highlight](https://read.readwise.io/read/01m1pp97aeeb6jfz3x5qnnvm0v)) - Note: Rose (RFC 3117) is the direct ancestor of Winer's "ship a validator" — and neither Winer document notices they're on the same side. Strictness is a choice about WHEN to pay, not whether. Liberal acceptance defers failure to the most expensive possible moment. - Tags: atom/literature/h1 - A flaw can become entrenched as a de facto standard. Any implementation of the protocol is required to replicate the aberrant behavior, or it is not interoperable. This is both a consequence of applying the robustness principle, and a product of a natural reluctance to avoid fatal error conditions. Ensuring interoperability in this environment is often referred to as aiming to be "bug for bug compatible". ([View Highlight](https://read.readwise.io/read/01m1pp8yhsn86ttmskr7yeq0dq)) - Note: The sharpest form of the case against liberal acceptance: tolerance promotes a defect into a requirement, with nobody deciding it should be. Same mechanism as WordPress's compatibility-first constraint. This is the strongest uncaptured claim across the whole three-doc cluster. - Tags: atom/literature/h1, atom/zettel/z1