Summary

  • RFC 1547 required conflicting enabled and disabled modes to remain compatible, with implementations supporting both and local users choosing which state fit the link.
  • Liveness, compression and MTU rules turned “off,” “no” and “use the default” into valid outcomes rather than implementation defects.
  • Later PPP specifications made the principle explicit: an implementation lacking an optional feature still had to interoperate with one that included it.

The requirements arrived after the work they guided

RFC 1547 entered the RFC series in December 1993, but its first page points backward. The requirements document was dated June 1989. Its historical note says those requirements guided RFC 1134 and the PPP specifications that followed; publication came later so the design record would be complete and might assist future standards work.

That chronology prevents an easy mistake. RFC 1547 was not a late commentary imposing a theory on an already finished protocol. Nor was it the packet-level specification of PPP. It was the earlier list of problems a standard point-to-point protocol was supposed to solve, finally preserved as an Informational RFC. RFC 1134, RFC 1171, RFC 1331, RFC 1548 and RFC 1661 show the subsequent specification lineage. None of those documents, by itself, proves how widely a feature was implemented or deployed.

The requirements memo also declined to prescribe one design. Its examples illustrated acceptable answers without foreclosing alternatives. That distinction matters because the memo's most durable contribution was a test for a design, not a single mechanism: could unlike operators meet at a common operating point even when they made different local choices?

The disabled mode belonged inside interoperability

Point-to-point links presented conflicting needs. A liveness exchange could be essential on one circuit and wasteful on another. Extra error correction could rescue an unusually noisy path while duplicating work already done by transport protocols elsewhere. Compression could save scarce bandwidth, yet two systems might implement different algorithms or one might prefer none.

RFC 1547 did not solve these conflicts by declaring one camp correct. It required the enabled and disabled modes of the disputed feature to be compatible. Implementations were to support both states. The user, explicitly not necessarily a human user, could choose dynamically which state suited the connection.

The UDP checksum supplied the memo's analogy. UDP had a representation for the checksum-disabled case, and the receiver could accept it. The point was not that PPP should copy UDP's wire format. It was that absence needed a legible, interoperable meaning. A peer that declined an optional behavior was still speaking the protocol.

This is stricter than saying a feature is configurable. Two products can each expose an on/off switch and still fail together if one side interprets “off” as a malformed peer. Compatibility requires the shared mode to survive the disagreement.

A heartbeat could be useful and still cost too much

The liveness requirement makes the trade-off concrete. RFC 1547 wanted a mechanism for determining whether the link was operational and made it enabled by default. The link began in a down state and could be considered up only after bidirectional packet exchange had been verified.

Yet the same requirement demanded a way to disable the mechanism. On a public data network, keepalive traffic could incur usage charges. A feature that improved fault detection on a private circuit could create a recurring bill on a metered service. Neither operator was irrational; the physical and commercial surroundings were different.

The default therefore expressed a common expectation, not an eternal command. An operator could turn liveness traffic off without leaving the protocol's compatibility set. The cost decision remained local while the meaning of the resulting mode remained shared.

The evidence boundary is equally important. A successful bidirectional exchange showed the point-to-point link at that moment. It did not prove an application was healthy, an account was authorized or future packets would succeed. RFC 1547's suggested identity check was for detecting misconfiguration and was explicitly not rigorous authentication. The memo said security issues were not discussed. Retrospective accounts should not manufacture a security guarantee the source refused to make.

Refusing compression was a complete answer

Compression exposed the negotiation rule with unusual clarity. RFC 1547 did not require a standard compression algorithm. Systems could use compression only when both ends agreed and possessed a common algorithm. The negotiation had to be simple and guaranteed to terminate.

Most importantly, refusal took precedence. One peer's wish to compress could not force the other into a capability, cost or risk it had not accepted. “No compression” was not an abandoned negotiation; it was a legitimate terminal result that preserved the base link.

That rule prevented optional enhancement from becoming a hidden admission test. If the compressed mode were the only usable mode once offered, the better-equipped endpoint would paradoxically make the pair less interoperable. By keeping the uncompressed floor valid, innovation could proceed without turning non-adoption into exclusion.

The source does not tell us which compression algorithms operators chose, how often requests were refused or what savings resulted. It defines the control surface: implementations supplied capabilities, peers negotiated consent, and either side could preserve the common mode by declining.

Defaults were floors with named exits

The maximum transmission unit followed the same architecture. RFC 1547 required a default for every supported link type and said it should be at least 1500 octets. Implementations could adopt another value through explicit negotiation or private agreement. Without that agreement, the default remained the enforceable common value.

This was not hostility to local optimization. It was a way to make optimization accountable. A larger or smaller value did not become real because one operator configured it; both ends needed a shared result. The default protected the pair from silent assumptions when no such result existed.

The memo drew an equally careful line around error correction. Transparency, framing, basic error detection and a basic MTU belonged to the common link service. Link-layer error correction, flow control and sequencing did not have to be universal because transport protocols already provided related functions. A particularly noisy link could still add error correction by private agreement, provided it did not violate the other requirements.

Other deliberate nonrequirements included backward compatibility with every older point-to-point protocol, multipoint operation, half-duplex or simplex links, and 7-bit asynchronous paths. The exclusions kept the common contract small. They did not pronounce the omitted functions useless.

Symmetry kept permanent rank out of the link

RFC 1547 also resisted fixed roles. It did not want the protocol divided permanently into master and slave, gateway and host, or caller and answerer semantics. If an exchange required differentiated roles, the systems could select them dynamically for that connection.

This symmetry complements the safe disabled mode. A permanent superior endpoint could define the other's refusal as error. Peers instead began from a common grammar and established only the temporary distinctions needed for the link. Network-address negotiation, like compression negotiation, was expected to remain simple and to terminate.

The memo also required room for extensions. Future options could be negotiated without rewriting the base contract. Extension was safe only because the older common mode did not disappear when the new option appeared.

PPP later made absence part of the option contract

RFC 1548 and its successor RFC 1661 turned the requirements into more mature PPP language. Standard defaults handled common configurations. Improvements implemented at one end could be communicated automatically to the other, while operators retained a way to configure exceptions. Each end described its capabilities and requirements through an extensible option mechanism.

Their definition of an optional feature is revealing: an implementation without the option still had to interoperate with an implementation that included it. Optional did not mean that every product supported the feature. It meant the protocol had specified a safe relationship between presence and absence.

The later documents retained a 1500-octet default receive unit and permitted alternatives between consenting implementations. The specific PPP control exchanges deserve their own history and are not retold here. RFC 1547's distinctive subject is the requirements-level decision that refusal and default behavior belonged inside the definition of success.

Four observations, not one green light

An operational inference follows from these sources. Capability, local enablement, mutual agreement and effective operation are four different facts.

A product manual may prove that an endpoint supports compression. A local configuration may prove that an operator enabled it. A completed negotiation may prove that both peers agreed to a particular mode. Packet observation or counters may show that the agreed mode actually carried traffic. None of those receipts automatically substitutes for the others.

The same separation applies to liveness and MTU. A default in an RFC does not prove the live setting. A configured keepalive does not prove the peer sees it. A link-up indication does not prove an application result. A private agreement does not prove either endpoint deployed it. Reliable records preserve the transition from available capability to chosen policy to peer consent to observed effect.

This four-part model is an inference, not language stated verbatim in RFC 1547. It is nevertheless the practical consequence of a standard that treats off, refusal and fallback as meaningful states.

A minimum contract can protect later local decisions

Heng Lu's Minimum Initial Specification, Localized Future Decision and Voluntary Adoption doctrine provides a contemporary vocabulary for the architecture. The minimum specification defines the strict grammar necessary for a deterministic compatibility set. Later decisions remain local. Publication does not turn adoption into reality; running systems and voluntary coordination do.

Read through that lens, RFC 1547 did not weaken the standard by permitting features to be off. It strengthened the common floor so local choices could differ without splitting the link. Compression, extra error correction and liveness policy could evolve at the edges because refusal still led somewhere valid.

The lens must not be mistaken for historical proof. RFC 1547's authors did not use Heng Lu's later terminology, and the RFC does not establish their subjective allegiance to it. The comparison is valuable because it identifies the same structural move: specify enough to preserve common operation, then leave reversible improvements to consent.

What the 1993 publication proves is narrower and more useful than a victory story. A point-to-point standard was judged not only by what happened when both ends said yes, but by what remained possible when one end said no. The feature could be absent. The protocol could not treat the peer as absent with it.

Sources