> ## Documentation Index
> Fetch the complete documentation index at: https://meta.niceshare.site/llms.txt
> Use this file to discover all available pages before exploring further.

# Postel's Law

> Postel's Law (robustness principle) asks implementations to send strict, accept loose for interoperability. Learn RFC roots and modern limits.

<Info>
  **Category**: Laws<br />
  **Type**: Network / systems interoperability principle<br />
  **Origin**: Jon Postel; TCP specifications (e.g., **RFC 793**, **1981**)<br />
  **Also known as**: Robustness principle
</Info>

<Note>
  **Quick Answer** — **Postel’s Law** is the robustness principle: **be conservative in what you send, liberal in what you accept** (wording varies slightly by document). It helped early Internet protocols interoperate across imperfect implementations. Today it remains a design heuristic—and a contested one—because tolerance can cement bugs and enlarge attack surfaces if not paired with security review.
</Note>

## What is Postel's Law?

**Postel’s Law** names a guideline for protocol implementations: **emit bytes that strictly follow the spec**, but **parse inputs generously** when meaning can still be recovered. The aim is interoperability when specs were evolving and peers differed. It sits alongside [Conway’s Law](/laws/conways-law) (systems mirror communication structure—different axis) and contrasts with [Brooks’s Law](/laws/brookss-law) (adding people adds coordination cost—orthogonal, but both shape shipping constraints). Unlike [Murphy’s Law](/laws/murphys-law), Postel is **prescriptive**, not fatalistic.

> Strict speakers and forgiving listeners carried the early net—until ambiguity became exploit surface.

### Postel's Law in 3 Depths

* **Beginner**: Expect older clients to send odd whitespace; strict servers still reject illegal frames, but may trim benign variation.
* **Practitioner**: Encode canonical outputs; on input, validate with **allow-lists**, log anomalies, and version behaviors explicitly.
* **Advanced**: Treat tolerance as a **security budget**—modern analyses warn bug-for-bug compatibility can ossify flaws across the ecosystem.

## Origin

**Jon Postel** articulated the robustness principle as an implementation strategy for early TCP/IP work. The widely cited formulation appears with **RFC 793** (*Transmission Control Protocol*, **September 1981**), instructing TCP implementations to be robust: conservative in sending behavior and liberal in accepting incoming segments consistent with the specification’s intent. The exact phrasing evolved across documents, but the **pairing of strict generation with tolerant consumption** became foundational engineering folklore for protocols, parsers, and APIs.

## Key Points

Use Postel to maximize compatibility—then measure where tolerance hurts safety.

<Steps>
  <Step title="Interoperability first">
    Heterogeneous vendors and partial deployments required forgiving receivers to keep the network useful.
  </Step>

  <Step title="Canonicalize outputs">
    “Conservative sending” pushes complexity to well-tested encoders rather than scattered clients.
  </Step>

  <Step title="Liberal acceptance needs bounds">
    Without schemas, fuzzing, and monitoring, permissive parsers become vulnerability farms.
  </Step>

  <Step title="Ecosystem effects dominate">
    Once many peers depend on a quirk, fixing it requires coordinated change—**bug-for-bug** pressure.
  </Step>
</Steps>

## Applications

Map the principle to modern API and platform design.

<CardGroup cols={2}>
  <Card title="Protocols & parsers" icon="network-wired">
    Emit strict JSON or protobuf; accept with validation layers that **reject** ambiguous or oversized inputs early.
  </Card>

  <Card title="Web front ends" icon="desktop">
    Normalize user input on save; still **escape** on render—liberal UX is not SQL injection forgiveness.
  </Card>

  <Card title="Collaboration norms" icon="users">
    Be precise in commitments you emit; allow good-faith variation in how teammates phrase updates—within agreed standards.
  </Card>

  <Card title="Backward compatibility" icon="clock-rotate-left">
    Version APIs explicitly; deprecate tolerant paths on a published timeline instead of silent forever-quirks.
  </Card>
</CardGroup>

## Case Study

The principle’s institutional anchor is textual: **RFC 793** (1981) encodes TCP’s robustness guidance for implementations that had to coexist across vendors—an externally citable standard with a **dated RFC number and year** rather than a lab metric. Later engineering discourse (including **ACM Queue / Communications of the ACM** treatments in the **2000s–2020s**) revisits whether permissive acceptance entrenched interoperability bugs—an indicator that the debate shifted from *whether networks connected* to *what security invariants must hold* when tolerance is default.

## Boundaries and Failure Modes

**Boundary 1: Security breaks naive liberality**\
Attackers craft ambiguous inputs precisely where parsers guess intent.

**Boundary 2: Standards matured**\
Modern protocols often prefer explicit failure over silent repair.

**Common misuse**: Infinite tolerance without telemetry—quirks become undeletable legacy.

## Common Misconceptions

Separate generosity from abdication.

<AccordionGroup>
  <Accordion title="Misconception: Accept everything kindly">
    **Reality**: Liberal parsing still rejects illegal states; kindness is bounded by safety and spec intent.
  </Accordion>

  <Accordion title="Misconception: Postel forbids strict validation">
    **Reality**: Conservative sending pairs with disciplined validation—often layered (syntax vs semantics).
  </Accordion>

  <Accordion title="Misconception: It is obsolete">
    **Reality**: The tradeoff evolved; the pattern still appears wherever ecosystems must interoperate.
  </Accordion>
</AccordionGroup>

## Related Concepts

Use these when balancing compatibility and correctness.

<CardGroup cols={3}>
  <Card title="Conway's Law" icon="sitemap" href="/laws/conways-law">
    System shapes follow communication shapes—coordination sets what “compatible” means.
  </Card>

  <Card title="Brooks's Law" icon="users" href="/laws/brookss-law">
    Adding people adds communication overhead—shipping fixes for legacy quirks costs time.
  </Card>

  <Card title="Murphy's Law" icon="triangle-exclamation" href="/laws/murphys-law">
    If something can go wrong, it will—design validation accordingly.
  </Card>
</CardGroup>

## One-Line Takeaway

<Tip>
  Canonicalize what you emit; validate what you accept—with explicit limits and metrics, not infinite guesswork.
</Tip>