Summary

  • RFC 832 began with declarations in the NIC host table, then attempted live Telnet, FTP and SMTP connections and recorded blank, refused, unreachable, dead and accepted results separately.
  • Negative results were retried and the survey was repeated weekly. A host's state therefore belonged to an observer, a route, a method and a time window rather than becoming a permanent label.
  • RFC 844 later reached only 127 of the 187 Telnet acceptors reported from another vantage. Running evidence was stronger than a registry claim, but it did not become universal reachability, full conformance or authority over the tested host.

A column headed “Claims”

The most important word in RFC 832 is not TCP. It is Claims.

The source list was the NIC hostname table dated 2 December 1982. Beside each name and address, that table could say that the machine supported TCP in general or specifically offered Telnet, FTP or SMTP. RFC 832 reproduced those declarations with compact marks: T for TCP, then lower-case t, f and s for the three services.

Smallberg added three result columns. A host could claim nothing and still accept a connection. It could claim a service and fail to answer. Declaration and observation remained visible side by side, so neither silently replaced the other.

That design matters because the transition plan itself contained a different kind of evidence. RFC 801's 1981 appendix collected implementation reports from sites and vendors: software was available, experimental, under development or planned. The memo warned that the information could become dated quickly. It also listed shortcuts that a TCP/IP implementation must not take, including omitting checksum verification, fragment reassembly, segment reordering, option processing or useful error reports.

A statement that a package existed could not prove those behaviors. Neither could a single open port. RFC 832 narrowed the question to something it could actually observe: from this test host, during this interval, did a connection to this named service reach a particular transport outcome?

Five kinds of negative evidence

The result vocabulary prevented one blank from swallowing several mechanisms. Refused meant the destination answered in a way that rejected the attempted connection. Unreachable meant the path produced an explicit reachability failure. Dead meant no useful response arrived under the survey method. A blank meant the service was not accepted without being forced into one of the stronger diagnoses. Accepted meant the connection attempt crossed the survey's threshold.

FTP had one extra mark. Accepted+ recorded that anonymous access worked with password guest. That small addition reveals the boundary of ordinary accepted: the survey otherwise did not claim a successful login, useful command, completed transfer or correct application behavior. TCP connection acceptance was transport evidence, not a certificate for the whole service.

The first run took place on 7 December, in two windows totaling more than eight hours. Hosts recorded as dead, refused or unreachable were retried on 8 December. Retrying was not cosmetic. It distinguished a durable observation from a transient outage, delayed route or unlucky moment without pretending that a second attempt eliminated every ambiguity.

The totals were still striking. Of 315 listed hosts, 83 accepted Telnet, 70 accepted FTP and 63 accepted SMTP from the test vantage. The figures did not mean that the remaining hosts had failed a universal requirement. Some machines were special-purpose; some were down; some did not intend to expose those services. They measured the surface selected by the survey.

A result that expired every Tuesday

RFC 833 repeated the exercise on 14 December. It also disclosed that duplicate host entries had been removed a little differently, slightly changing the row totals. That note is a piece of evidence engineering. A changed denominator was not hidden as network growth or decline. The method had a version.

The surveys continued through December, January and February. RFC 847 later assembled twelve of them. Accepted Telnet connections moved from 83 on 7 December to 190 on 22 February; FTP from 70 to 181; SMTP from 63 to 178. The rise is consistent with a transition gaining operational reality around the January cutover.

But the line was not monotonic. Telnet acceptances went from 103 to 102 to 95 over the next three December observations. FTP and SMTP also fell in some weeks. A live network is not an institutional progress chart. Host-table revisions, outages, routes, testing hours, duplicate treatment and service policy all changed what the observer could see.

RFC 846, the last survey in the series, still used the same modest grammar. It named the 18 February host table, the 22 February test window, the ISI-VAXA vantage and a next-day retry period. It did not announce that the Internet had become compliant. It published another coordinate.

The second observer changed the answer

RFC 844 supplied the most valuable challenge to the series because it changed the point of observation.

RFC 843 had reported 187 hosts accepting Telnet from ISI-VAXA on 8 and 9 February. A separate experiment selected those hosts and tried them from a BBN terminal concentrator on the Class C network 192.1.2.0/24. This path demanded more than a listening TCP endpoint. Gateways had to route back to the Class C address; hosts needed the relevant address handling; ICMP behavior could affect the path.

Only 127 of the 187 were marked OK, or 67.9 percent. That did not retroactively prove that RFC 843 was false or that the other 60 did not implement TCP. It proved that “accepted Telnet” did not travel as a property detached from its observer. The later memo also said the attempts were manual, only three passes were made, and a few machines might have been missed because they were down.

The two surveys therefore measured different propositions. One asked whether a service accepted a connection from ISI during its window. The other asked whether the same nominal service could be reached from a Class C site through a route and host implementation that handled the additional conditions. Changing vantage exposed hidden dependencies.

Even the summary needed provenance

RFC 847 made the weekly series legible by placing accept counts, host totals and percentages in one table. It also estimated that 37 special-purpose hosts, 11 percent of the population, should not be expected to offer the three tested services. The reasonable ceiling, it suggested, was 89 percent rather than 100.

That is a useful refusal to confuse membership with service exposure. A host could participate in the Internet without offering Telnet, FTP and SMTP to the survey machine.

The summary also demonstrates why derived records need their sources. Its first FTP row prints 70 acceptances out of 315 as 26 percent, although that quotient is about 22 percent. It prints 382 as one RFC 842 denominator where adjacent service totals show 328, 389 for an RFC 843 FTP total where the population is otherwise 329, and February 1982 for a survey conducted in 1983.

Those visible anomalies do not erase the series. They identify the correct audit response: retain numerator, denominator, method, source memo and calculation. A clean percentage without provenance can be less trustworthy than a messy table that lets the reader find the mistake.

Measurement did not become command

The survey operator controlled the probe, result vocabulary and publication. The remote sites controlled their software, service exposure and repairs. An accepted result did not authorize the observer to act on the host. A failed result did not make the host invalid, transfer ownership or establish negligence.

This is the durable institutional boundary. Running code can discipline a declaration because another participant can test behavior. Yet a test earns authority only over the proposition it actually measures. A socket can show that a connection was accepted. It cannot certify every TCP requirement, authenticate the operator, prove useful service, or describe reachability from every network.

RFC 832's achievement was not a perfect census. It was a public chain from claim to experiment to result to retry to superseding experiment. The table said TCP. The network was allowed to answer in more than one way.

Sources and evidence limits

These RFCs document plans, dated host-table declarations, connection experiments and their summaries. They do not establish current deployment, complete protocol conformance, operator identity, service authorization or transaction success. Negative outcomes remain bounded by the recorded vantage, route, method and time.