Summary

  • RFC 1602 expected a public licence form that an implementer could execute; RFC 1915 accepted a rights-holder’s more general assurance so PPP compression and encryption work could advance.
  • The variance was itself public, reviewed and appealable, but it could authorize a standards-process exception rather than prove the terms, timing or equality of any later bilateral licence.
  • RFC 1962 and RFC 1968 show that the control protocols reached publication; they do not prove patent validity, universal licensing, implementation, interoperability, deployment or end-to-end security.

The packet formats were finished, but the process had stopped

The Point-to-Point Protocol working group had developed two control protocols. One negotiated compression on a PPP link; the other negotiated encryption. Their technical purpose was narrow: let peers select whether and how those transformations would operate rather than assume one algorithm for every link.

Then Motorola told the IETF that the work might infringe two United States patents, numbered 5,245,614 and 5,130,993. RFC 1915 says the specifications had reached the IESG for standardization when the claims halted their progress. The blockage was not a missing field in the packet. It was an unresolved condition around who could lawfully implement the design and on what terms.

That distinction matters. A protocol can be fully legible as engineering and still be commercially incomplete for an implementer. Reading every bit does not reveal the price of permission. Passing an interoperability test does not identify the rights a company believes it must obtain. The standards archive and the licence ledger are different evidence systems.

RFC 1602 had asked for an executable object

The standards procedure then in force went beyond a statement of goodwill. Its model agreement gave the Internet Society a cost-free licence for standards work and contemplated licences for members of the Internet community on reasonable terms. It also described a clause that would automatically make a licence at least as favourable as one granted elsewhere.

Most importantly, the form itself was supposed to remain publicly accessible on the Internet. An interested implementer could inspect it, execute it and send it to the rights holder. The common record would not settle every business decision, but it would expose the instrument from which those decisions began.

This was a form of technical governance by reducing ambiguity. A public document could be versioned, compared and preserved. Its parties, scope and execution rule could be checked before an implementation became expensive. If the form changed, that change could be observed. If two organisations received different terms, the most-favourable mechanism supplied a contractual way to connect the cases.

RFC 1915 records that this object was not obtained. Motorola preferred a general statement saying that licences would be available to any party under reasonable terms and conditions demonstrably free of unfair discrimination. The statement was public. It named the patents and a contact. But an assurance that a contract will be offered is not the contract.

One adjective concealed several future measurements

“Reasonable” has no price printed inside it. “Nondiscriminatory” cannot be tested from one offer. A requester would still need to contact the rights holder, wait, receive terms, compare scope, decide whether the conditions fit its product and execute an agreement. Another requester might enter the same sequence later with no public table showing whether timing or treatment matched.

RFC 1915 did not ignore this risk. It stated it directly: a rights holder could treat each request differently, advancing some and delaying others. Such behaviour would conflict with the IETF tradition of openness and equal access. The variance therefore did not declare the missing evidence unimportant. It chose to proceed despite it.

That choice moved uncertainty. Under the RFC 1602 model, more of the licence mechanics would have lived in one common artefact. Under the accepted assurance, more of them would emerge only inside bilateral exchanges. The protocol remained public; the path from public specification to licensed implementation became less observable.

The technical detour had failed its own legitimacy test

The working group considered revising the protocols to avoid the claimed patents. RFC 1915 says such changes were technically possible. It also says some participants thought the alternative markedly less desirable and intended to implement the original compression protocol regardless of what the working group or IESG selected. Others accepted the change mainly because they saw no viable alternative.

That was not rough consensus around a better design. It was pressure toward a technically disliked substitute, accompanied by a credible implementation split. The standards process faced two different failure modes: keep the original work frozen by the rights procedure, or standardize an alternative that important implementers might ignore.

The variance was not a claim that patents should defeat engineering, nor a claim that engineering should erase patents. It was a bounded answer to deadlock. The IESG accepted the assurance and permitted the original CCP and ECP work to advance.

The exception had a procedure of its own

RFC 1871 had created the variance mechanism only months earlier. It allowed an escape when written procedures did not work or offered no guidance, but it did not give the IESG an invisible waiver switch. The process had to be public and allow concerned parties to comment.

The responsible group identified the problem. The IESG proposed a solution. An extended Last Call exposed it to review. The IESG had to weigh likely Internet-community benefits against the costs of noncompliance, consider technical merit, alternatives, precedent and collateral effects, and make the exception as narrow as possible. The IAB remained available for appeal.

RFC 1915 itself became the receipt. It described the failed requirement, the alternative, the accepted statement, the claimed benefit and the perceived risk. That record proves how the process authorized advancement. It does not prove what happened in every licensing negotiation after publication.

Publication closed one ledger, not all of them

The Compression Control Protocol appeared as RFC 1962 in June 1996. The Encryption Control Protocol followed as RFC 1968 in the same month. Their texts defined negotiation, reset behaviour and options. They also preserved room for proprietary mechanisms identified through an organisational identifier and for publicly defined algorithms that might carry licensing restrictions.

The protocols could converge differently. Compression could fail to find a common method and leave the link operating without compression. Encryption negotiation might find no mutually agreeable option and lead an endpoint to take the link down. The standards did not turn the existence of a control protocol into a guarantee that one algorithm was available to both peers.

Nor did ECP make a patent assurance into a security claim. RFC 1968 tied link protection to the chosen algorithm and the handling of secrets, and kept complete security at the end-to-end layer between hosts. A published encryption-control grammar is not proof of confidentiality, key custody, lawful implementation or application safety.

The next process revision changed the evidence bargain

RFC 2026 replaced RFC 1602 in October 1996. It still sought written assurance that anyone could obtain rights on openly specified, reasonable and nondiscriminatory terms. But it no longer made the outcome of that attempt a normal condition of standards-track advancement, and it did not reproduce RFC 1602’s online executable-form mechanism.

It also declined to have the IESG explicitly certify that the promised terms were reasonable and nondiscriminatory in practice. Later implementation and operational evidence could support an inference at higher maturity stages, and that inference remained open to challenge during Last Call.

The sequence shows policy evolution, not a proven causal chain. The cited record does not establish that RFC 1915 alone produced RFC 2026. What it does reveal is a durable institutional boundary: a technical standards body can publish claims, seek assurances, expose an exception and decide how its own process advances. It cannot adjudicate patent validity, sign for an implementer or observe every private licence from inside an RFC.

Sources and limits

These sources document process text, claimed rights, the published assurance and later protocol and process documents. They do not establish patent validity, essentiality, infringement, licence price, every negotiation, equal treatment in practice, current licensing availability, a named implementation, deployment share or operational outcome.