Summary

  • In 1977, NAME/FINGER let a remote host ask for a site’s current users or for information about one named person.
  • The wire request was small; the answer could reveal names, locations, idle time, last logout, or a message the user had left.

A blank line was enough to ask a question

The most revealing request in the 1977 NAME/FINGER note contains almost nothing: a carriage return and line feed. A client could connect to a remote service, send that empty command, and receive a report about people using the system at that moment. The system might identify users by name, show the jobs they were running, say how long their terminals had been idle, and locate those terminals in a room or building. A named query could reach beyond the login session: it might return a last logout time and a short note the user had left for whoever asked.

The protocol standardized reach, not a person’s story

That arrangement predates the profile page, but it was not a web page in miniature. It joined a network query to information that each host already knew how to assemble. Ken Harrenstien’s RFC 742 says the protocol mostly specifies one command line and imposes no required output format. The service at each site could decide how to turn local account and terminal details into a human-readable answer. Reach was shared; presentation remained local.

By 1990, openness had become an administrative choice

The note also records a small chain of reuse. Les Earnest’s FINGER program at SAIL inspired the NAME program on MIT’s ITS system. Earl Killian at MIT and Brian Harvey at SAIL implemented the original protocol, and a similar server had recently appeared at SRI. A local convenience had become portable because its users could ask another machine the same kind of question. RFC 742 names three participating sites, not a census of the network, so it cannot establish how widely the service spread.

Its sample output makes the social stakes unusually concrete. One listing includes console locations and current jobs. Another reports that a person is not logged in and prints a plan message: where the person expects to be, when they are reachable, and how to contact them. The protocol did not require every site to expose every field. But the examples show that an “online status” query could combine system telemetry with information deliberately written by a person.

The first specification was also tied to the network machinery of its moment. RFC 742 describes reaching socket 117 in octal, or port 79 in decimal, using ICP and two 8-bit connections. By 1984, RFC 924 catalogued Finger as an elective protocol and noted that changes were needed for TCP. Its short description still centered on a person’s current or most recent activity.

In June 1990, IAB and IETF meeting minutes kept RFC 742 as a grandfathered Proposed Standard for the time being, while assigning an action to obtain a better document and re-examine it. RFC 1194 followed in November. It says the work was meant to clarify exchanges without breaking existing implementations, many of which derived from Berkeley’s BSD Unix. It also describes user information as sensitive and gives operators choices about refusals, exposed files, executable programs and audit trails.

This was the protocol’s lasting boundary: it made a person queryable across a network, but did not make the person’s answer uniform or universally public. The administrator chose what the server revealed; users could supply a plan, but their control depended on how that local service was built. The 1990 revision did not erase that tension. It made the tension visible enough to administer.

Primary records