Tensions in Practice: Installed compatibility in tension with specification discipline¶
Toy command interface · a tolerated legacy spelling
The published command is mode=fast, but a receiver has also accepted the legacy spelling FAST. Sender B now relies on that extra acceptance. Keeping the rule preserves compatibility while extending what the implementation must support. Removing it aligns acceptance with the written format but breaks B’s unchanged requests. A receiver policy can become a dependency before the specification ever records it.
Keep installed senders working
Continue accepting the legacy form that a deployed sender actually emits.
Restore a clear acceptance contract
Avoid maintaining undocumented forms and their future interpretation obligations indefinitely.
Why these aims pull against each other
The written specification has not changed, but the accepted input set has. Tightening the receiver therefore removes a real communication path rather than merely cleaning up unused text.
Choose an arrangement to see what changes and what remains difficult.
Finite illustrative comparisons. Labels carry the meaning; color does not establish a preference or measured effect.
What this choice protects
What it costs
When it fits
Compare the arrangements
Keep legacy acceptance
Continue accepting mode=fast and the explicitly mapped legacy form FAST.
| Sent form | In spec? | Result | |
|---|---|---|---|
| Sender A | mode=fast | Yes | Accept |
| Sender B | FAST | No | AcceptLegacy rule |
- What it protects
- Both current senders remain usable without immediate migration.
- What it costs
- The receiver must maintain the extra rule, and callers may continue treating it as part of the effective interface.
- When it fits
- Fits a controlled compatibility period or a context where the known legacy support cost is preferable to breaking installed clients.
Illustration note: This is one explicit legacy mapping, not a recommendation to accept arbitrary malformed or ambiguous input.
Enforce the published form
Remove acceptance of FAST while leaving the formal command unchanged.
| Sent form | In spec? | Result | |
|---|---|---|---|
| Sender A | mode=fast | Yes | Accept |
| Sender B | FAST | No | RejectNeeds update |
- What it protects
- The receiver’s accepted set matches the selected written contract and no longer includes that legacy branch.
- What it costs
- Sender B fails until migrated; a flag change alone does not rewrite installed clients.
- When it fits
- Fits a justified tightening with understood dependencies and an acceptable migration or interruption plan.
Illustration note: The table deliberately holds B unchanged to show the break. A completed migration would be another state, not evidence that tightening had no cost.
What this illustration does—and does not—establish
Asymmetric Interface Tolerance: Reversibility versus Path-Dependence (temporal) supplies path dependence; Asymmetric Interface Tolerance: Independent Policies versus Coupled Equilibrium (coupling) explains why sender behavior reflects earlier receiver policy. The fixed senders make the lost acceptance path visible.
- The two forms and their mapping are invented; no actual protocol or parser behavior is asserted.
- Published conformance does not by itself establish safety, correctness or future compatibility.
- No particular migration schedule or deprecation period is recommended.
Source entries
Asymmetric Interface Tolerance
Asymmetric Interface Tolerance: Reversibility versus Path-Dependence (temporal) supplies the conflict examined here.
Reversibility versus Path-Dependence (temporal)
once an interface runs for years under liberal-receiver policy, the installed sender base depends on the liberality and cannot be made strict by fiat.
Independent Policies versus Coupled Equilibrium (coupling)
The failure mode is tuning one side as if the other were fixed: tightening receivers to fight drift while senders, conditioned by years of liberality, keep emitting nonconformant output that now breaks.
Charity as Robustness versus Charity as Hazard (sign/direction)
accepting malformed input to be helpful, and thereby both ossifying the de-facto spec and admitting adversarial inputs a strict parser would reject.