Summary

  • RFC 1127 recorded how the IETF Host Requirements Working Group ranked interoperability above architectural purity and converted settled issues into firm requirements or recommendations.
  • When equally strong positions supported opposite rules, RFC 1122 and RFC 1123 left the feature MAY or OPTIONAL; other contested features were allowed only inside explicit limits.
  • A MUST described compliant software. It did not select an installation’s configuration, prove the running value, show peer interoperability or establish an application result.

The perspective document was not another standard

RFC 1127 begins by limiting its own authority. It is informational, does not define a protocol and is not a standard at any maturity level. Its subject is the process behind two standards documents: RFC 1122, covering communication layers, and RFC 1123, covering applications and support.

That distinction lets the source do something a requirement table cannot. It shows where the working group had consensus, where it compromised, where it could not decide, and where it admitted that another experiment or working group was needed. The RFC Editor record and IETF Datatracker record preserve the publication identity; the body preserves the reasoning debt.

The effort was substantial: roughly twenty core experts, major contributions from roughly twenty more, seven formal meetings over twenty months, about three megabytes of electronic mail and around twenty drafts. Those numbers do not certify that every conclusion was correct. They establish that the capitalized words emerged from an extended reconciliation of incompatible implementations and priorities, not from a single editor inventing a checklist.

Interoperability outranked elegance

The working group named five goals: interoperability, extensibility, functionality, efficiency and architectural purity. It put interoperability first and architectural purity last. That was not permission to abandon architecture. It was a decision about which cost would be borne when a clean model collided with machines already attached to the Internet.

Many provisions repeated what earlier protocol documents already said or implied. RFC 1127 reports the cynical nickname “Read The Manual” provisions. They were retained because at least one implementation had made the wrong choice and caused interoperability, performance or robustness problems. A redundant sentence could therefore have new institutional value: it converted a known failure pattern into an explicit testable duty.

The companion standards warn that a summary alone is dangerous. Their requirement lists depend on the underlying protocol documents, corrections, explanations and implementation context. A host built for one sheltered LAN might work there and still fail on a diverse Internet path. The contract aimed at arbitrary host interoperation, not merely a successful laboratory pairing.

Consensus strength became normative strength

RFC 1122 gave the capital words precise roles. MUST or REQUIRED meant an absolute requirement. SHOULD or RECOMMENDED allowed departure only when the implications were understood and the case carefully weighed. MAY or OPTIONAL meant that one implementation could include the feature and another could omit it.

It also separated two conformance levels. Missing a MUST made an implementation non-compliant for the protocol it implemented. Meeting every MUST and SHOULD was “unconditionally compliant”; meeting the MUST duties but not every SHOULD duty was “conditionally compliant.” These labels describe a relationship between code and a specification. They are not certificates for a configured machine or a peer pair.

RFC 1127 reveals how disagreements shaped those words. Settled questions produced definite requirements or recommendations. In open questions, some participants argued for MUST or SHOULD while others argued just as strongly for MUST NOT or SHOULD NOT. The working group documented the views, took no stand and used MAY or OPTIONAL. Optionality here was not proof that all choices were equally safe. It marked the boundary of available consensus.

A third class used bounded permission. Host forwarding, trailer encapsulation, delayed acknowledgements, TCP keep-alives, optional UDP checksum suppression and several Telnet behaviors were not simply approved or banned. The standards allowed them under conditions, often with a safe default or a switch. The compromise narrowed the blast radius without pretending the controversy had vanished.

Implementable did not mean configured

The most important scope sentence in RFC 1127 is easy to pass over: the Host Requirements work tried to deal with software implementation, not the way the software was configured and applied. Administrative and configuration questions were omitted where they belonged to another authority.

RFC 1122 makes the consequence concrete. A fully self-configuring protocol suite was an ideal the community was “not even close” to reaching. Values sometimes depended on host size, traffic distribution or nearby topology. Some best values were unsettled. Self-tuning algorithms did not exist. Administrators had local requirements.

Worse, correct systems sometimes needed an override to coexist with obsolete or incorrect binary-only peers. The document describes administrators deliberately mis-configuring a correct system for compatibility, while insisting that the default should still implement the official protocol. Compatibility debt was real; making it the default would perpetuate it.

A configurable parameter therefore established an ability, not a state. The vendor had to provide an override and document its effects. The standard might choose the default. The site still chose whether to replace it. A compliance statement cannot tell an investigator which value was running at 14:03, which peer caused an exception or whether the option was ever exercised.

Open work was not hidden inside a vague MUST

RFC 1127 lists future work with unusual candor. Host initialization needed a unified approach. Dead-gateway detection lacked an adequate documented algorithm. Universal pinging had generated excessive traffic; one widely used system listened to a routing protocol outside the desired architecture. MTU probe code had not been tested and depended on gateway adoption. Performance algorithms needed a deeper account of how they interacted.

The group could have produced authoritative-sounding sentences for each gap. Instead it recorded the limits of knowledge and assigned future inquiry. That made the standards less complete on paper and more honest as an operational contract.

The same honesty appears in RFC 1123’s warning that protocol software must be maintained as specifications evolve. A conformance result belongs to a version and a time. It does not travel forever with a product name.

The evidence ladder begins after publication

The later RFC 2119 generalized the familiar capitalized vocabulary across Internet specifications. Its RFC Editor record gives that vocabulary its later BCP history. It did not convert normative language into an enforcement mechanism.

For a real host, evidence must keep moving. First identify the exact specification and implemented protocol set. Then establish code and build conformance. Record the shipped default, the installation override, the active runtime value and the event that changed it. Observe the peer’s capabilities and the exchange. Finally, record the application result.

“RFC 1122 compliant” may be a useful claim. Without the rest of the chain, it is a description of intended software properties. The Host Requirements project made those properties firmer; RFC 1127 made their boundary visible.

Sources