Action and feedback
Postel's Law and input boundaries
Help people enter valid information while keeping the system's accepted meanings explicit.
The idea in plain language
What it means.
The robustness principle comes from network protocol engineering. Applied carelessly, accepting unexpected input can conceal bugs or create incompatible interpretations. In forms, tolerate harmless presentation differences only when normalization is unambiguous. Validate the resulting value against an explicit contract and communicate failures clearly.
Evidence and interpretation
What supports it.
Historical protocol guidance in RFC 1122, qualified by the IAB's RFC 9413 discussion of robust protocol maintenance. Friendly forms and consistent UI states are design applications, not permission to relax trust boundaries.
From principle to interface
Where you could use it.
Proposed applications, not tested outcomes. The expected effects are hypotheses to check with realistic tasks and users.
Application 1
Accept a formatted reference number
Allow spaces in a reference number where the documented format treats spaces as insignificant, then validate its length and permitted characters on the server.
Expected effect to test
People can paste a readable value without changing its defined meaning.
Keep in view
Do not apply this normalization to passwords, signatures or identifiers whose exact bytes matter.
Application 2
Resolve an ambiguous date
When 03/04/2027 could mean two dates, show the expected format or ask the person to choose the intended date, then echo the resolved date in words.
Expected effect to test
The person and the system agree on the stored meaning.
Keep in view
Never silently guess a consequential date. API unknown-field handling must follow the versioned schema and extension policy.
Turn the idea into a check
Use it deliberately.
- Separate parsing, documented normalization and validation.
- Validate untrusted input on the server and use the appropriate output encoding and parameterized data access.
- Define success, pending and failure states consistently, and preserve safe input for correction.
Where the rule gets complicated
Keep the limits attached.
- Permissive parsing is not a security strategy.
- Input validation alone does not prevent every injection or authorization flaw.
- RFC 9413 warns that lax interpretation and hidden variation can undermine interoperability and security; strictness should follow explicit specifications.
A named principle does not settle an accessibility requirement, prove a conversion lift or replace testing the particular interface.
Application and implementation boundaries
What the application check shows.
The local example accepted only documented ASCII-space normalization for a six-digit reference, rejected invalid or ambiguous dates, preserved exact-value spaces and rendered markup-like input as text.
Methods: Local application example. A completed check covers the stated sample; it is not a safety certification.
- Target
- Original IonBin synthetic interface example; no external product or human-participant study.
- Version or capture
- 2026-10-19 local fixture
- Integrity scope
- SHA-256 f85d1056afd667225a1e0364edfb8f25b4693ffa7b2b8c7d7af5b92338b85ee4 identifies the exact HTML fixture only.
Test conditions
- 155.0.8059.82 Chromium; fresh context with all network requests blocked.
- Synthetic inputs, memory-only state, reduced-motion preference, 1280px and 320px viewports.
Individual checks and observations
Inert text
passLocal application example: Exercise the original local application fixture and inspect the resulting controls or DOM state.
Observed: Markup-like synthetic input stayed literal text; no image element or handler was created.
Accept ASCII spaces in a reference
passLocal application example: Exercise the original local application fixture and inspect the resulting controls or DOM state.
Observed: "12 34 56" was accepted after ASCII-space normalization by the six-ASCII-digit contract.
Reject a short reference
passLocal application example: Exercise the original local application fixture and inspect the resulting controls or DOM state.
Observed: "12345" was rejected by the six-ASCII-digit contract.
Reject a long reference
passLocal application example: Exercise the original local application fixture and inspect the resulting controls or DOM state.
Observed: "1234567" was rejected by the six-ASCII-digit contract.
Reject full-width digits
passLocal application example: Exercise the original local application fixture and inspect the resulting controls or DOM state.
Observed: "１２３４５６" was rejected by the six-ASCII-digit contract.
Reject a tab in the reference
passLocal application example: Exercise the original local application fixture and inspect the resulting controls or DOM state.
Observed: "12\t3456" was rejected by the six-ASCII-digit contract.
Reject markup as a reference
passLocal application example: Exercise the original local application fixture and inspect the resulting controls or DOM state.
Observed: "<script>" was rejected by the six-ASCII-digit contract.
Accept an ISO-format date
passLocal application example: Exercise the original local application fixture and inspect the resulting controls or DOM state.
Observed: 2027-03-04 was accepted.
Reject an ambiguous date
passLocal application example: Exercise the original local application fixture and inspect the resulting controls or DOM state.
Observed: 03/04/2027 was rejected as ambiguous or invalid.
Reject an impossible date
passLocal application example: Exercise the original local application fixture and inspect the resulting controls or DOM state.
Observed: 2027-02-30 was rejected as ambiguous or invalid.
Exact value
passLocal application example: Exercise the original local application fixture and inspect the resulting controls or DOM state.
Observed: The exact-value example retained leading/trailing spaces; reference normalization was not reused.
Security findings and boundaries
Review of the local example’s stated interaction boundaries; no backend, authentication, production permissions or external service was exercised.
Practical advice · caution
Normalization is not an injection defense
These synthetic checks do not test a backend. Real systems need server validation, context-appropriate encoding, parameterized access and independent authorization.
Practical caveats
- Define normalization field by field. Do not trim passwords, signed values or identifiers whose exact bytes carry meaning.
What remains untested
- This checks an authored application example, not the truth, effect size or generality of the named principle.
- No users, assistive-technology participants, physical devices or production task outcomes were evaluated.
Security limits
- The example has no real authorization or persistence layer; its UI behavior cannot establish the security of a deployed workflow.
Evaluation sources
- RFC 1122, section 1.2.2: Robustness Principle
Historical protocol context.
- RFC 9413: Maintaining Robust Protocols
IAB qualifications, active maintenance and security concerns.
- OWASP: Input Validation Cheat Sheet
Validation boundaries and related controls; guidance, not a security evaluation of a product.
Go to the source
Research and further reading.
- RFC 1122, section 1.2.2: Robustness Principle
Historical protocol context.
- RFC 9413: Maintaining Robust Protocols
IAB qualifications, active maintenance and security concerns.
- OWASP: Input Validation Cheat Sheet
Validation boundaries and related controls; guidance, not a security evaluation of a product.
Related questions
More on action and feedback.
Research finding
Fitts's Law and target distance
Give controls enough room to hit and put related actions within a sensible reach.
Engineering principle
Doherty Threshold and responsiveness
Respond promptly and show what is happening. A single timing number cannot describe every interaction.